techie Posted November 20, 2007 Share Posted November 20, 2007 Twice in the last couple of days, I have received a notification when logging in to the reporting webpage that my email has been bouncing. I have not received any other reports of bounces, and my incoming email volume is normal. The bounce message was "too many hops", but mail is not looping anywhere within my system, nor is it looping between my system and my secondary MX, which is under my direct control. This leads me to assume that it must be looping within Spamcop, since the mail is not handled anywhere else. Unfortunately, Spamcop doesn't show anything more than the subject line of the bounce message, which doesn't help me track down the problem, assuming that the problem even exists outside of Spamcop. Link to comment Share on other sites More sharing options...
SpamCopAdmin Posted November 20, 2007 Share Posted November 20, 2007 Twice in the last couple of days, I have received a notification when logging in to the reporting webpage that my email has been bouncing.If you want to send me your login email address, I would be happy to review the bounces logged on your account. I can tell you what's going on. Please email me directly at: service[at]admin.spamcop.net - Don D'Minion - SpamCop Admin - Link to comment Share on other sites More sharing options...
techie Posted November 20, 2007 Author Share Posted November 20, 2007 It just happened again, and this is the only clue so far. Nov 20 05:26:24 tantivy sm-mta[48665]: lAKDQ3au048665: sc-smtp3-bulkmx.soma.ironport.com [204.15.82.124] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA And I found another one from yesterday.. (out of a total of 6, for 4 different sites) Nov 19 04:17:07 tantivy sm-mta[30014]: lAJCCCaB030014: sc-smtp1-bulkmx.soma.ironport.com [204.15.82.123] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA Checking further, I find 113 of these errors from ironport over the last 30 days, out of 185 total errors of this type. Most of the rest are from beryl.spiritone.com (31), and spam1.pem.inap.sea.dotster.net (27), both of which appear to have never actually sent me email., and there are about 10-11 from other random hosts over the last 30 days. The only thing I can think of is that Ironport's timer settings are interacting with the Sendmail Greet_Pause feature that we run, with a 15 second delay from initial tcp connection to the 220 greeting, which means Ironport should adjust their timers to a more reasonable value. RFC-2821 suggests that SMTP clients wait a minimum of 5 minutes for the 220 greeting. Link to comment Share on other sites More sharing options...
SpamCopAdmin Posted November 20, 2007 Share Posted November 20, 2007 with a 15 second delay from initial tcp connection to the 220 greeting, which means Ironport should adjust their timers to a more reasonable value.SpamCop is sending a LOT of email every day. We can't wait 15 seconds for a connection. If we can't connect immediately, the server logs a bounce on the user's account, suspends the account, discards the email it was trying to send, and moves on to the next message. I don't see that changing. - Don D'Minion - SpamCop Admin - Link to comment Share on other sites More sharing options...
techie Posted November 20, 2007 Author Share Posted November 20, 2007 SpamCop is sending a LOT of email every day. We can't wait 15 seconds for a connection. If we can't connect immediately, the server logs a bounce on the user's account, suspends the account, discards the email it was trying to send, and moves on to the next message. I don't see that changing. - Don D'Minion - SpamCop Admin - From RFC 2821: --- 4.5.3.2 Timeouts An SMTP client MUST provide a timeout mechanism. It MUST use per- command timeouts rather than somehow trying to time the entire mail transaction. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code. To implement this, a timer is set Klensin Standards Track [Page 56] RFC 2821 Simple Mail Transfer Protocol April 2001 for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message. Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows: Initial 220 Message: 5 minutes An SMTP client process needs to distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many SMTP servers accept a TCP connection but delay delivery of the 220 message until their system load permits more mail to be processed. --- Everybody else seems to be able to wait 15 seconds, what makes Spamcop so special? Do you get a kick out of ignoring the recommended practices as specified in the RFC's that everybody else follows? From my perspective, greet_pause with the 15 second delay is highly effective at stopping drive-by spam, and has caught a lot more spam entering my system than Spamcop ever has. Link to comment Share on other sites More sharing options...
Telarin Posted November 20, 2007 Share Posted November 20, 2007 There really is no reason why spamcop can't "wait". I think the misleading thing here is the use of the word "wait". Spamcop wouldn't really be "waiting" at all. It would simply make an asynchronous call and immediately continue execution of the current thread without waiting to find out whether the called failed or succeeded. The IP stack would handle any actual waiting, and other threads would continue to execute while this occurred. There would be no "lost" CPU cycles. When the call either failed or went through, it would simply call back the appropriate procedure to handle the result. Instead, apparently spamcop is using synchronous calls. With synchronous calls, you call your send procedure, and then actually have to wait for it to complete before it returns and continues execution of the rest of your program. Synchronous, or blocking calls are rarely used other than in single-threaded, low-volume applications. They are rarely appropriate for use in server or multi-user applications. Since Spamcop runs accross multiple server, handling the volume of traffic it does, I have serious doubts that the software is a single-threaded application that couldn't be upgraded to asynchronous calls for the sending of SMTP messages and possibly even DNS resolution which is another thing that tends to fail if it runs long. As an added bonus, upgrading the code to be multi-threaded and use asynchronous calls would make it run MUCH more efficiently on multiple CPU systems, or systems running multiple core CPUs as the threads could be spread out between the CPUs. Link to comment Share on other sites More sharing options...
techie Posted November 24, 2007 Author Share Posted November 24, 2007 Well, mail from spamcop is still bouncing, and will continue to bounce until spamcop/ironport and akamai get DNS back in sync. The problem is that ironport added a new server, which has reverse DNS working properly, but for some reason akamai, which handles the forward DNS lookups, doesn't have the current zonefile, so there is no forward DNS for the new server as far as the world outside ironport is concerned. This hits one of my DNS sanity checks, which requires that forward and reverse DNS entries match. Ironport's servers have the correct zonefile, but akamai does not, and since the publicly listed servers are akamai, this presents a problem. I expect that this will either be fixed soon, or else I am expecting that ironport.com will drop off the net when the expire timer for the zonefile hits zero ~12.5 days after the last successful zone transfer. This of course assumes that akamai is getting the zonefile from the same place that ironport's servers are getting it from. The zonefile serial numbers currently differ between ns1.ironport.com and the akam.net servers, with the akam.net servers having stale data. The offending mail server is sc-smtp7-inbound.soma.ironport.com [204.15.82.101], and the admins have been notified, including a complete explanation, and debugging output from dig. Link to comment Share on other sites More sharing options...
Farelf Posted November 24, 2007 Share Posted November 24, 2007 Well, mail from spamcop is still bouncing, and will continue to bounce until spamcop/ironport and akamai get DNS back in sync. ...The offending mail server is sc-smtp7-inbound.soma.ironport.com [204.15.82.101], and the admins have been notified, including a complete explanation, and debugging output from dig.Ah, thanks - sounds like this is related to the "other" new server issue with sc-smtp9.soma.ironport.com [204.15.80.50] noted in http://forum.spamcop.net/forums/index.php?showtopic=8948 - last heard, SC admin (Don) was growling at anyone who would listen in the engineering side. Link to comment Share on other sites More sharing options...
SpamCopAdmin Posted November 24, 2007 Share Posted November 24, 2007 - last heard, SC admin (Don) was growling at anyone who would listen in the engineering side. Yes. And I just now sent out a fresh growler to pretty much everybody and their dog. I'll do it again on Monday when everybody comes back to work. - Don D'Growler - Link to comment Share on other sites More sharing options...
techie Posted November 25, 2007 Author Share Posted November 25, 2007 Ah, thanks - sounds like this is related to the "other" new server issue with sc-smtp9.soma.ironport.com [204.15.80.50] noted in http://forum.spamcop.net/forums/index.php?showtopic=8948 - last heard, SC admin (Don) was growling at anyone who would listen in the engineering side. A quick check shows that sc-smtp[7-10]-inbound.ironport.com are all missing from akamai. Thanks to Don for growling.. I'll leave this in his hands. Link to comment Share on other sites More sharing options...
techie Posted November 26, 2007 Author Share Posted November 26, 2007 Update: sc-smtp[7-10]-inbound.soma.ironport.com are now visible via akamai. Link to comment Share on other sites More sharing options...
Farelf Posted November 26, 2007 Share Posted November 26, 2007 Update: sc-smtp[7-10]-inbound.soma.ironport.com are now visible via akamai.Thanks for your work on this one - marking it resolved, trusting it is so. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.