Jump to content

[Resolved] Spamcop thinks my email address is bouncing?


techie
 Share

Recommended Posts

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

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

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

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

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.

Edited by techie
Link to comment
Share on other sites

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.

Edited by Telarin
Link to comment
Share on other sites

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.

Edited by techie
Link to comment
Share on other sites

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

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.

Edited by techie
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...