North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Yahoo Mail problems ? (queue issues in general)

  • From: Mike Tancsa
  • Date: Wed May 05 14:12:41 2004 
At 01:26 PM 05/05/2004, [email protected] wrote:
On Wed, 05 May 2004 10:59:55 EDT, Mike Tancsa <[email protected]> said:

> Anyone else seeing Yahoo mail queue up today ? Some of their servers
> respond in about 10secs with the HELO banner, most others take more than
> 2m. Because of the recent increase in SPAM, I was looking to reduce the
> wait time for the initial HELO to 2m from 5m. However, the RFC calls for 5m
> on the HELO and another 5m for the MAIL command.

Do you have a handle on whether the delay is between the first SYN packet and
finally completing the 3-packet handshake, or is it between that and when the
220 banner actually arrives? Or are both phases an issue?
Both, depending on which A record I get

Also mixed in are things like

421 mta174.mail.scd.yahoo.com Resources temporarily unavailable. Please try again later.


Here is an example of one which took quite a long time to respond to the S and then the HELO banner never came up

14:03:10.653498 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 198626121 0> (DF) [tos 0x10] (ttl 64, id 21505, len 60)
14:03:13.649303 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 198626421 0> (DF) [tos 0x10] (ttl 64, id 21521, len 60)
14:03:16.849310 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 74: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 198626741 0> (DF) [tos 0x10] (ttl 64, id 21531, len 60)
14:03:20.049332 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460> (DF) [tos 0x10] (ttl 64, id 21536, len 44)
14:03:23.249367 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460> (DF) [tos 0x10] (ttl 64, id 21543, len 44)
14:03:26.449416 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460> (DF) [tos 0x10] (ttl 64, id 21547, len 44)
14:03:32.649436 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 > 64.156.215.5.25: S [tcp sum ok] 944590797:944590797(0) win 57344 <mss 1460> (DF) [tos 0x10] (ttl 64, id 21576, len 44)
14:03:32.728687 0:90:27:5d:4e:ee 0:1:29:2c:b6:30 0800 60: 64.156.215.5.25 > 205.211.164.51.2013: S [tcp sum ok] 4275443659:4275443659(0) ack 944590798 win 65535 <mss 1460> (ttl 55, id 11594, len 44)
14:03:32.728717 0:1:29:2c:b6:30 0:90:27:5d:4e:ee 0800 60: 205.211.164.51.2013 > 64.156.215.5.25: . [tcp sum ok] 1:1(0) ack 1 win 58400 (DF) [tos 0x10] (ttl 64, id 21579, len 40)

So in the above case, the process just blocks (with sendmail, it does eat a lot of RAM) waiting to hit the HELO timeout.


> Having a process block like that for up to 10m seems a bit excessive to
> deliver one email (and its probably a bounce to boot!).  What are others
> doing?  This problem seems to becoming more and more acute.

What I do is the *first* attemt to deliver the mail has a highly-non-compliant
Yes, this is sort of what I have as well. 9 seconds on the initial connect in my case. That gets the lion's share through. The subsequent deliverys are much more patient. In this day and age, you would think

define(`confTO_HELO', `1m')
define(`confTO_MAIL', `2m')

would be safe....


---Mike