At 01:26 PM 05/05/2004, Valdis.Kletnieks@vt.edu wrote:
On Wed, 05 May 2004 10:59:55 EDT, Mike Tancsa <mike@sentex.net> 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