nanog mailing list archives
Re: Yahoo Mail problems ? (queue issues in general)
From: Mike Tancsa <mike () sentex net>
Date: Wed, 05 May 2004 14:11:39 -0400
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 like421 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
Current thread:
- Yahoo Mail problems ? (queue issues in general) Mike Tancsa (May 05)
- Re: Yahoo Mail problems ? (queue issues in general) Valdis . Kletnieks (May 05)
- Re: Yahoo Mail problems ? (queue issues in general) Mike Tancsa (May 05)
- Re: Yahoo Mail problems ? (queue issues in general) Valdis . Kletnieks (May 05)