workstation having slow sessions with email server

[stfaprc]

There is one workstation running Thunderbird (secure auth is turned off) on our LAN that is having problems with connecting to the email server running sendmail(8.14) on a RH Linux box. It takes a while for the Thunderbird to make the connection and return the new emails or respond that no new emails are present.

I did a tethereal capture but don't really understand all that is happening. Also, where is the challenge and response for the user's email name and password?

tethereal | grep "192.168.1.10"
Capturing on eth0
6.272820 00:90:db:7a:90:c1 -> Broadcast ARP Who has 192.168.1.5? Tell 192.168.1.10
6.273054 192.168.1.10 -> 192.168.1.5 TCP 2325 > pop3 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
6.273310 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
6.273451 192.168.1.10 -> 192.168.1.5 TCP 2325 > pop3 [ACK] Seq=1 Ack=1 Win=65535 Len=0
6.277546 192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=134775 TSER=0 WS=0
9.269878 192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=135075 TSER=0 WS=0
15.270021 192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=135675 TSER=0 WS=0
27.270403 192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=136875 TSER=0 WS=0
36.358021 192.168.1.5 -> 192.168.1.10 POP Response: +OK POP3 email.000.com v2001.78rh server ready
36.365250 192.168.1.10 -> 192.168.1.5 POP Request: CAPA
36.365672 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [ACK] Seq=50 Ack=7 Win=5840 Len=0
36.365831 192.168.1.5 -> 192.168.1.10 POP Response: +OK Capability list follows:
36.386232 192.168.1.10 -> 192.168.1.5 POP Request: AUTH LOGIN
36.386766 192.168.1.5 -> 192.168.1.10 POP Continuation
36.394788 192.168.1.10 -> 192.168.1.5 POP Request: c2NodWx0ZV9wZXRlcg==
36.395174 192.168.1.5 -> 192.168.1.10 POP Continuation
36.415662 192.168.1.10 -> 192.168.1.5 POP Request: cHRyflByZ18z
36.450519 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [ACK] Seq=171 Ack=55 Win=5840 Len=0
36.482591 192.168.1.5 -> 192.168.1.10 POP Response: +OK Mailbox open, 55 messages
36.489240 192.168.1.10 -> 192.168.1.5 POP Request: STAT
36.489628 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [ACK] Seq=202 Ack=61 Win=5840 Len=0
36.489755 192.168.1.5 -> 192.168.1.10 POP Response: +OK 55 1021854
36.504983 192.168.1.10 -> 192.168.1.5 POP Request: LIST
36.505492 192.168.1.5 -> 192.168.1.10 POP Response: +OK Mailbox scan listing follows
36.520622 192.168.1.10 -> 192.168.1.5 POP Request: UIDL
36.521252 192.168.1.5 -> 192.168.1.10 POP Response: +OK Unique-ID listing follows
36.542496 192.168.1.10 -> 192.168.1.5 POP Request: RETR 55
36.543351 192.168.1.5 -> 192.168.1.10 POP Response: +OK 1246 octets
36.717530 192.168.1.10 -> 192.168.1.5 POP Request: QUIT
36.725294 192.168.1.5 -> 192.168.1.10 POP Response: +OK Sayonara
36.726134 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [FIN, ACK] Seq=3195 Ack=88 Win=5840 Len=0
36.726284 192.168.1.10 -> 192.168.1.5 TCP 2325 > pop3 [ACK] Seq=88 Ack=3196 Win=64255 Len=0
36.780841 192.168.1.10 -> 192.168.1.5 TCP 2325 > pop3 [FIN, ACK] Seq=88 Ack=3196 Win=64255 Len=0
36.780993 192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [ACK] Seq=3196 Ack=89 Win=5840 Len=0

 

[LawnBoy]

The delay seems to be here:

6.277546  192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=134775 TSER=0 WS=0
  9.269878  192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=135075 TSER=0 WS=0
 15.270021  192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=135675 TSER=0 WS=0
 27.270403  192.168.1.5 -> 192.168.1.10 TCP 32880 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=136875 TSER=0 WS=0
 36.358021  192.168.1.5 -> 192.168.1.10 POP Response: +OK POP3 email.000.com v2001.78rh server ready

The server (.5) appears to be trying a handshake that is being ignored by the client. After 4 attempts (with increasing time delays between each) it gives up and uses some other handshake and the conversation resumes. What that handshake is I couldn't say.

The auth is here:

36.386232 192.168.1.10 -> 192.168.1.5  POP Request: AUTH LOGIN
 36.386766  192.168.1.5 -> 192.168.1.10 POP Continuation
 36.394788 192.168.1.10 -> 192.168.1.5  POP Request: c2NodWx0ZV9wZXRlcg==
 36.395174  192.168.1.5 -> 192.168.1.10 POP Continuation
 36.415662 192.168.1.10 -> 192.168.1.5  POP Request: cHRyflByZ18z
 36.450519  192.168.1.5 -> 192.168.1.10 TCP pop3 > 2325 [ACK] Seq=171 Ack=55 Win=5840 Len=0
 36.482591  192.168.1.5 -> 192.168.1.10 POP Response: +OK Mailbox open, 55 messages

--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[stfaprc]

odd, odd, odd.
here is the capture from another pc on the LAN. as can be seen, the ACK is quick and the user and password are viewable.
This user gets the email with "msOutlook 2000-SP3"
Both are using XP-Pro.

397.387713 192.168.1.31 -> 192.168.1.5 TCP 2090 > pop3 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1456
397.387947 192.168.1.5 -> 192.168.1.31 TCP pop3 > 2090 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
397.388090 192.168.1.31 -> 192.168.1.5 TCP 2090 > pop3 [ACK] Seq=1 Ack=1 Win=65535 Len=0
397.434720 192.168.1.5 -> 192.168.1.31 TCP 41860 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=7284236 TSER=0 WS=0
397.434939 192.168.1.31 -> 192.168.1.5 TCP auth > 41860 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
398.900662 192.168.1.5 -> 192.168.1.31 POP Response: +OK POP3 email.000.com v2001.78rh server ready
398.901583 192.168.1.31 -> 192.168.1.5 POP Request: USER cflat
398.902020 192.168.1.5 -> 192.168.1.31 TCP pop3 > 2090 [ACK] Seq=50 Ack=14 Win=5840 Len=0
398.902362 192.168.1.5 -> 192.168.1.31 POP Response: +OK User name accepted, password please
398.902796 192.168.1.31 -> 192.168.1.5 POP Request: PASS G123S
398.943103 192.168.1.5 -> 192.168.1.31 TCP pop3 > 2090 [ACK] Seq=91 Ack=28 Win=5840 Len=0
399.367055 192.168.1.5 -> 192.168.1.31 POP Response: +OK Mailbox open, 1 messages
399.367948 192.168.1.31 -> 192.168.1.5 POP Request: STAT
399.368097 192.168.1.5 -> 192.168.1.31 TCP pop3 > 2090 [ACK] Seq=121 Ack=34 Win=5840 Len=0
399.384476 192.168.1.5 -> 192.168.1.31 POP Response: +OK 1 17485
399.385162 192.168.1.31 -> 192.168.1.5 POP Request: UIDL
399.385644 192.168.1.5 -> 192.168.1.31 POP Response: +OK Unique-ID listing follows
399.387774 192.168.1.31 -> 192.168.1.5 POP Request: RETR 1
399.390210 192.168.1.5 -> 192.168.1.31 POP Response: +OK 17485 octets
399.390287 192.168.1.5 -> 192.168.1.31 POP Continuation
399.390859 192.168.1.31 -> 192.168.1.5 TCP 2090 > pop3 [ACK] Seq=48 Ack=3100 Win=65535 Len=0
399.390997 192.168.1.5 -> 192.168.1.31 POP Continuation
399.392455 192.168.1.5 -> 192.168.1.31 POP Continuation
399.392527 192.168.1.5 -> 192.168.1.31 POP Continuation
399.393008 192.168.1.31 -> 192.168.1.5 TCP 2090 > pop3 [ACK] Seq=48 Ack=5740 Win=65535 Len=0
399.393137 192.168.1.5 -> 192.168.1.31 POP Continuation
399.393581 192.168.1.31 -> 192.168.1.5 TCP 2090 > pop3 [ACK] Seq=48 Ack=8380 Win=65535 Len=0

 

[LawnBoy]

397.434720  192.168.1.5 -> 192.168.1.31 TCP 41860 > auth [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=7284236 TSER=0 WS=0
397.434939 192.168.1.31 -> 192.168.1.5  TCP auth > 41860 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
398.900662  192.168.1.5 -> 192.168.1.31 POP Response: +OK POP3 email.000.com v2001.78rh server ready

The difference is in the second line here. The client responded to the server with an ACK. In the first capture you posted the client does not.

It looks like the server is trying a plain text login first, then falling back to SSL or some other encryption. The client at .10 is not responding to the plain text prompt, causing the server to timeout and try the fallback; which the client responds to.

Be careful posting plaintext passwords in a public forum. I know that your server is on a private network but you never know who's paying attention...

--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[stfaprc]

the logins and password posted have been munged

So, the question to solve is why does .10 not respond to the plain text request from the server when the email client is setup to 'Never' use secure login. Also, the server is not setup with SSL on the sendmail so how is the ACK eventually happening? And where is the login and password for .10 ?

 

[LawnBoy]

What I know about Thunderbird or sendmail wouldn't fill a shotglass, so I'm probably not going to be much help to you moving forward.
Good luck.


--
The stagehand's axiom: "Never lift what you can drag, never drag what you can roll, never roll what you can leave.

 

[elgrandeperro]

Do you have RFC1413 (ident) turned off, the value in sendmail.cf:
O Timeout.ident=0 ?

I believe the AUTH are these packets, and they can cause 15-30 second delays on timeouts.

 

[thedaver]

My suggestion is that the specific client's configuration has the particular/offending authentication option turned on (differently from the other clients). Go check the "advanced" and "credentials" related sections of the client to make sure the login capabilities being tried are the same.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[stfaprc]

elgrandeperro : yes, O Timeout.ident=0 due to a client of ours being unable to send us email unless we turned off the identity asking (their email server would not respond to the request , causing connection timeouts).

thedaver: does Thunderbird have multiple places where "Auth" can be turned on? It is just so odd that the user & password are not being sent in plain.