[prev in list] [next in list] [prev in thread] [next in thread]
List: pfsense-discussion
Subject: Re: [pfSense-discussion] Strange 2.0-RC3 behaviour with Lotus Domino
From: Odhiambo Washington <odhiambo () gmail ! com>
Date: 2011-08-26 9:36:30
Message-ID: CAAdA2WM2BHx2q+v-bk3Cs5NEyTh5vVKPQYpEnWOp=bPpeuB1Ug () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Odette,
If you could churn out a tutorial based on pfSense 2.0 for both site-to-site
and road warrior, I believe it will be a great resource for us.
On Fri, Aug 26, 2011 at 12:30, Odette Nsaka <odette.nsaka@libero.it> wrote:
> **
> Which kind of OVPN: site to site or road warrior? With PF 1.2.2 or 2.0?
> --
> Odette Nsaka <odette.nsaka@libero.it>
>
> Il giorno ven, 26/08/2011 alle 10.29 +0530, A Mohan Rao ha scritto:
>
> Could u pls guide me how i configure open vpn..
>
> On 8/26/11, Odette Nsaka <odette.nsaka@libero.it> wrote:
> > It's a lot of time I'm using PF and I really appreciate it. Guys
> > you are doing a very good job.
> >
> > I'm successfully using PF 2.0-RC3, even on Alix (embedded) and
> > installed on PC, with ipsec vpn, OVPN, carp for failover, WiFi, WAN in
> > load
> > balancing on 2 different ADSL lines, etc. Everything is working really
> > fine.
> >
> > But a few days ago I encountered a problem that I cannot understand and
> > resolve: I've been upgrading a couple of PF installed on pc (configured
> > in failover with CARP, 5 nics) from release 1.2.3 to 2.0-RC3.
> >
> > In version 1.2.3 and all the previous updates have everything been
> > working fine.
> >
> > After the upgrade to 2.0-RC3 I had just one problem, but because of
> > this I had to revert to 1.2.3.
> >
> > Here is the problem.
> >
> > After the upgrade to version 2.0-RC3 every protocol has been filtered
> > by PF as expected. But the SMTP traffic from the e-mail provider mta
> > (postfix) to the internal MailReley server had a strange behaviour. On
> > the internal mail relay I saw the connection estabilished from the
> > provider mta, but at the moment of receiving the the mail body the
> > connection hanged up and reset at timeout. Just small e-mails, sent as
> > a test by the provider, have been successfully delivered.
> >
> > Reverting to 1.2.3 everything works fine again.
> >
> > An inspection to the traffic, made through a mirror port on the switch
> > (verified sniffing directly on PF)
> > shows the different behaviours reported below.
> >
> > Here are the data captured with 2.0-RC3, related to an attempt of the
> > MTA to send an e-mail messages to the internal mail relay.
> >
> >
> > 226970 684.515289 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > smtp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=68980421 TSER=0
> > WS=7
> > 226971 684.515768 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> > 57715 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0
> > TSER=0
> > 226973 684.526527 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=68980427 TSER=0
> > 226977 684.529562 MyMailRelayIp -> ProviderMtaIp SMTP S: 220
> > mail.mycompany.com ESMTP Service (Lotus Domino Release 8.5.1FP2)
> > ready at Wed, 27 Jul 2011 12:52:04 +0200
> > 226978 684.537048 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > smtp [ACK] Seq=1 Ack=110 Win=5888 Len=0 TSV=68980443 TSER=625882
> > 226979 684.537070 ProviderMtaIp -> MyMailRelayIp SMTP C: EHLO
> > fedora.provider.org
> > 226980 684.537868 MyMailRelayIp -> ProviderMtaIp SMTP S:
> > 250-mail.mycompany.com Hello fedora.provider.org
> > ([ProviderMtaIp]), pleased to meet you | 250-TLS | 250-ETRN |
> > 250-STARTTLS | 250-DSN | 250-SIZE 18432000 | 250 PIPELINING
> > 226992 684.551654 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> > FROM:<user@domain> SIZE=86045 | RCPT TO:<user@domain> | DATA
> > 226996 684.552697 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> > message, end with "." on a line by itself
> > 227503 686.321903 MyMailRelayIp -> ProviderMtaIp SMTP [TCP
> > Retransmission] S: 250 user@domain Sender OK | 250 user@domain
> > Recipient OK | 354 Enter message, end with "." on a line by
> > itself
> > 227505 686.329892 ProviderMtaIp -> MyMailRelayIp TCP [TCP
> > Previous segment lost] 57715 > smtp [ACK] Seq=3001 Ack=404
> > Win=8064 Len=0 TSV=68982235 TSER=625901 SLE=274 SRE=404
> > 343904 1013.873824 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> > 57715 [FIN, ACK] Seq=404 Ack=105 Win=64136 Len=0 TSV=629175
> > TSER=68980454
> > 343909 1013.883338 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> > smtp [RST] Seq=105 Win=0 Len=0
> >
> >
> > As I can see the traffic between the provider's MTA and the mai relay
> > starts and, initially it goes on, but packet ID 226996 get lost, then
> > retransmitted (227503) and acknowledged by ProviderMtaIp but with a
> > grater Seq. number. It looks like the mail data packets have been lost.
> > Then, after about 5 min. the connection reaches the time out, mail
> > relay sends a FIN request and the ProviderMtaIp resets the connection.
> >
> > On PF's logs there's nothing about dropped packets related to the
> > connection.
> >
> >
> >
> > Here's, what happens reverting to 1.2.3 (everything works fine).
> >
> > ...
> > 19377 46.958958 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> > FROM:<user@domain> SIZE=56892 | RCPT TO:<user@domain> | DATA
> > 19378 46.960259 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> > message, end with "." on a line by itself
> > 19386 46.971715 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19387 46.974048 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19388 46.974082 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19389 46.974425 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=420 Ack=2617 Win=64240 Len=0 TSV=706364 TSER=77029773
> > 19393 46.987139 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19394 46.987663 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=420 Ack=5113 Win=63248 Len=0 TSV=706365 TSER=77029773
> > 19395 46.987686 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> > 19394#1] smtp > 33359 [ACK] Seq=420 Ack=5113 Win=63248 Len=0
> > TSV=706365 TSER=77029773
> > 19396 46.989640 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19397 46.989661 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19398 46.990342 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=420 Ack=7609 Win=64240 Len=0 TSV=706365 TSER=77029787
> > 19407 46.999000 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19408 46.999026 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > ...
> > 19492 47.067918 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19493 47.068921 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19494 47.069291 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=420 Ack=54809 Win=64240 Len=0 TSV=706365 TSER=77029856
> > 19495 47.070644 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> > fragment, 1248 bytes
> > 19507 47.078352 ProviderMtaIp -> MyMailRelayIp IMF from: "user"
> > <user@domain>, subject xxx Masked Subject xxx, (text/plain)
> > (text/html)
> > 19508 47.078846 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=420 Ack=57023 Win=63530 Len=0 TSV=706365 TSER=77029856
> > 19509 47.078867 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> > 19508#1] smtp > 33359 [ACK] Seq=420 Ack=57023 Win=63530 Len=0
> > TSV=706365 TSER=77029856
> > 19517 47.084957 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> > Message accepted for delivery
> > 19518 47.085306 MyMailRelayIp -> ProviderMtaIp SMTP S: 221
> > mail.mycompany.com SMTP Service closing transmission channel
> > 19519 47.085405 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [FIN, ACK] Seq=519 Ack=57023 Win=63530 Len=0 TSV=706365
> > TSER=77029856
> > 19527 47.096111 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> > [FIN, ACK] Seq=57023 Ack=519 Win=8064 Len=0 TSV=77029898
> > TSER=706365
> > 19528 47.096609 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> > [ACK] Seq=520 Ack=57024 Win=63530 Len=0 TSV=706366 TSER=77029898
> > 19529 47.098002 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> > [ACK] Seq=57024 Ack=520 Win=8064 Len=0 TSV=77029900 TSER=706365
> >
> >
> >
> >
> > I've also tried to play around with the MTU value, with no effect.
> >
> > Mail Relay is Lotus Domino Release 8.5.1FP2 and the mta is
> > Fedora, kernel 2.6.18-1, server postfix 2.2.8-1.2
> > During the tests the provider also tried Debian, kernel 2.6.26-2, server
> > postfix 2.5.5-1.1
> >
> > The provider's mta lies in internet (WAN side of the PF), while the the
> > mail relay is in one of the DMZs of the PF, with public IP, no nat.
> > Even WAN and DMZ are over CARP for fault tolerance.
> >
> > The provider have been delivering the e-mails to all other customers,
> > with no problem, and asserts that all his servers are strictly compliant
> > the RFCs
> > The router connecting to Internet is set up with MTU=1476.
> >
> > Please, does someone have an idea of what is going on, or did already
> > see a similar behaviour?
> > Every suggestion will be appreciated.
> >
> > Thank you in advance.
> >
> > Odette Nsaka
> >
> >
> >
> >
>
>
>
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I can't hear you -- I'm using the scrambler.
Please consider the environment before printing this email.
[Attachment #5 (text/html)]
Odette,<br><br>If you could churn out a tutorial based on pfSense 2.0 for both \
site-to-site and road warrior, I believe it will be a great resource for \
us.<br><br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 12:30, Odette Nsaka \
<span dir="ltr"><<a \
href="mailto:odette.nsaka@libero.it">odette.nsaka@libero.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><u></u>
<div>
Which kind of OVPN: site to site or road warrior? With PF 1.2.2 or 2.0?<br>
<table cellpadding="0" cellspacing="0" width="100%">
<tbody><tr>
<td>
-- <br><div class="im">
Odette Nsaka <<a href="mailto:odette.nsaka@libero.it" \
target="_blank">odette.nsaka@libero.it</a>><br> <br>
</div></td>
</tr>
</tbody></table>
Il giorno ven, 26/08/2011 alle 10.29 +0530, A Mohan Rao ha scritto:
<div><div></div><div class="h5"><blockquote type="CITE">
<pre>Could u pls guide me how i configure open vpn..
On 8/26/11, Odette Nsaka <<a href="mailto:odette.nsaka@libero.it" \
target="_blank">odette.nsaka@libero.it</a>> wrote: > It's a lot of time \
I'm using PF and I really appreciate it. Guys > you are doing a very good job.
>
> I'm successfully using PF 2.0-RC3, even on Alix (embedded) and
> installed on PC, with ipsec vpn, OVPN, carp for failover, WiFi, WAN in
> load
> balancing on 2 different ADSL lines, etc. Everything is working really
> fine.
>
> But a few days ago I encountered a problem that I cannot understand and
> resolve: I've been upgrading a couple of PF installed on pc (configured
> in failover with CARP, 5 nics) from release 1.2.3 to 2.0-RC3.
>
> In version 1.2.3 and all the previous updates have everything been
> working fine.
>
> After the upgrade to 2.0-RC3 I had just one problem, but because of
> this I had to revert to 1.2.3.
>
> Here is the problem.
>
> After the upgrade to version 2.0-RC3 every protocol has been filtered
> by PF as expected. But the SMTP traffic from the e-mail provider mta
> (postfix) to the internal MailReley server had a strange behaviour. On
> the internal mail relay I saw the connection estabilished from the
> provider mta, but at the moment of receiving the the mail body the
> connection hanged up and reset at timeout. Just small e-mails, sent as
> a test by the provider, have been successfully delivered.
>
> Reverting to 1.2.3 everything works fine again.
>
> An inspection to the traffic, made through a mirror port on the switch
> (verified sniffing directly on PF)
> shows the different behaviours reported below.
>
> Here are the data captured with 2.0-RC3, related to an attempt of the
> MTA to send an e-mail messages to the internal mail relay.
>
>
> 226970 684.515289 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=68980421 TSER=0
> WS=7
> 226971 684.515768 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> 57715 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0 TSV=0
> TSER=0
> 226973 684.526527 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=68980427 TSER=0
> 226977 684.529562 MyMailRelayIp -> ProviderMtaIp SMTP S: 220
> <a href="http://mail.mycompany.com" \
target="_blank">mail.mycompany.com</a> ESMTP Service (Lotus Domino Release 8.5.1FP2) \
> ready at Wed, 27 Jul 2011 12:52:04 +0200 > 226978 684.537048 \
ProviderMtaIp -> MyMailRelayIp TCP 57715 > > smtp [ACK] Seq=1 \
Ack=110 Win=5888 Len=0 TSV=68980443 TSER=625882 > 226979 684.537070 \
ProviderMtaIp -> MyMailRelayIp SMTP C: EHLO > <a \
href="http://fedora.provider.org" target="_blank">fedora.provider.org</a> > \
226980 684.537868 MyMailRelayIp -> ProviderMtaIp SMTP S: > <a \
href="http://250-mail.mycompany.com" target="_blank">250-mail.mycompany.com</a> Hello \
<a href="http://fedora.provider.org" target="_blank">fedora.provider.org</a> > \
([ProviderMtaIp]), pleased to meet you | 250-TLS | 250-ETRN | > \
250-STARTTLS | 250-DSN | 250-SIZE 18432000 | 250 PIPELINING > 226992 \
684.551654 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL > \
FROM:<user@domain> SIZE=86045 | RCPT TO:<user@domain> | DATA > \
226996 684.552697 MyMailRelayIp -> ProviderMtaIp SMTP S: 250 > \
user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter > \
message, end with "." on a line by itself > 227503 686.321903 \
MyMailRelayIp -> ProviderMtaIp SMTP [TCP > Retransmission] S: 250 \
user@domain Sender OK | 250 user@domain > Recipient OK | 354 Enter \
message, end with "." on a line by > itself
> 227505 686.329892 ProviderMtaIp -> MyMailRelayIp TCP [TCP
> Previous segment lost] 57715 > smtp [ACK] Seq=3001 Ack=404
> Win=8064 Len=0 TSV=68982235 TSER=625901 SLE=274 SRE=404
> 343904 1013.873824 MyMailRelayIp -> ProviderMtaIp TCP smtp >
> 57715 [FIN, ACK] Seq=404 Ack=105 Win=64136 Len=0 TSV=629175
> TSER=68980454
> 343909 1013.883338 ProviderMtaIp -> MyMailRelayIp TCP 57715 >
> smtp [RST] Seq=105 Win=0 Len=0
>
>
> As I can see the traffic between the provider's MTA and the mai relay
> starts and, initially it goes on, but packet ID 226996 get lost, then
> retransmitted (227503) and acknowledged by ProviderMtaIp but with a
> grater Seq. number. It looks like the mail data packets have been lost.
> Then, after about 5 min. the connection reaches the time out, mail
> relay sends a FIN request and the ProviderMtaIp resets the connection.
>
> On PF's logs there's nothing about dropped packets related to the
> connection.
>
>
>
> Here's, what happens reverting to 1.2.3 (everything works fine).
>
> ...
> 19377 46.958958 ProviderMtaIp -> MyMailRelayIp SMTP C: MAIL
> FROM:<user@domain> SIZE=56892 | RCPT TO:<user@domain> | DATA
> 19378 46.960259 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> user@domain Sender OK | 250 user@domain Recipient OK | 354 Enter
> message, end with "." on a line by itself
> 19386 46.971715 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19387 46.974048 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19388 46.974082 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19389 46.974425 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=2617 Win=64240 Len=0 TSV=706364 TSER=77029773
> 19393 46.987139 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19394 46.987663 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=5113 Win=63248 Len=0 TSV=706365 TSER=77029773
> 19395 46.987686 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> 19394#1] smtp > 33359 [ACK] Seq=420 Ack=5113 Win=63248 Len=0
> TSV=706365 TSER=77029773
> 19396 46.989640 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19397 46.989661 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19398 46.990342 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=7609 Win=64240 Len=0 TSV=706365 TSER=77029787
> 19407 46.999000 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19408 46.999026 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> ...
> 19492 47.067918 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19493 47.068921 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19494 47.069291 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=54809 Win=64240 Len=0 TSV=706365 TSER=77029856
> 19495 47.070644 ProviderMtaIp -> MyMailRelayIp SMTP C: DATA
> fragment, 1248 bytes
> 19507 47.078352 ProviderMtaIp -> MyMailRelayIp IMF from: \
"user" > <user@domain>, subject xxx Masked Subject xxx, \
(text/plain) > (text/html)
> 19508 47.078846 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=420 Ack=57023 Win=63530 Len=0 TSV=706365 TSER=77029856
> 19509 47.078867 MyMailRelayIp -> ProviderMtaIp TCP [TCP Dup ACK
> 19508#1] smtp > 33359 [ACK] Seq=420 Ack=57023 Win=63530 Len=0
> TSV=706365 TSER=77029856
> 19517 47.084957 MyMailRelayIp -> ProviderMtaIp SMTP S: 250
> Message accepted for delivery
> 19518 47.085306 MyMailRelayIp -> ProviderMtaIp SMTP S: 221
> <a href="http://mail.mycompany.com" \
target="_blank">mail.mycompany.com</a> SMTP Service closing transmission channel > \
19519 47.085405 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359 > \
[FIN, ACK] Seq=519 Ack=57023 Win=63530 Len=0 TSV=706365 > TSER=77029856
> 19527 47.096111 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> [FIN, ACK] Seq=57023 Ack=519 Win=8064 Len=0 TSV=77029898
> TSER=706365
> 19528 47.096609 MyMailRelayIp -> ProviderMtaIp TCP smtp > 33359
> [ACK] Seq=520 Ack=57024 Win=63530 Len=0 TSV=706366 TSER=77029898
> 19529 47.098002 ProviderMtaIp -> MyMailRelayIp TCP 33359 > smtp
> [ACK] Seq=57024 Ack=520 Win=8064 Len=0 TSV=77029900 TSER=706365
>
>
>
>
> I've also tried to play around with the MTU value, with no effect.
>
> Mail Relay is Lotus Domino Release 8.5.1FP2 and the mta is
> Fedora, kernel 2.6.18-1, server postfix 2.2.8-1.2
> During the tests the provider also tried Debian, kernel 2.6.26-2, server
> postfix 2.5.5-1.1
>
> The provider's mta lies in internet (WAN side of the PF), while the the
> mail relay is in one of the DMZs of the PF, with public IP, no nat.
> Even WAN and DMZ are over CARP for fault tolerance.
>
> The provider have been delivering the e-mails to all other customers,
> with no problem, and asserts that all his servers are strictly compliant
> the RFCs
> The router connecting to Internet is set up with MTU=1476.
>
> Please, does someone have an idea of what is going on, or did already
> see a similar behaviour?
> Every suggestion will be appreciated.
>
> Thank you in advance.
>
> Odette Nsaka
>
>
>
>
</pre>
</blockquote>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Odhiambo \
WASHINGTON,<br>Nairobi,KE<br>+254733744121/+254722743223<br>_ _ _ _ _ _ _ _ _ _ _ _ _ \
_ _ _ _ _ _ _ _ _ _ _ <br>I can't hear you -- I'm using the scrambler.<br>
<span style="font-size:10.0pt;color:#007F00"><img \
src="cid:image001.png@01CBFF85.F00DA370" height="33" width="35"></span><span \
style="font-size:10.0pt;color:#007F00" lang="EN-US">Please consider the environment \
before printing this email. </span><br>
<br>
--0015174bdb521a8a2304ab654a72--
["image001.png" (image/png)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic