Fighting spam is a big task; it’s big in costs, big in technology, and big in administration. What makes it harder is that some major players do not properly handle the SMTP protocol in a way that aligns with the various standards and RFC:s.
Message Labs (www.messagelabs.com) is a well known player on the spam prevention scene. Many companies use their services; some for inbound filtering, some for inbound and outbound filtering. I have recently noticed a problem in how Message Labs and other companies’ mail servers handle SMTP 4xx response codes. This may very well be a well-known problem, but it’s still a sad state of affairs.
It seems like some people capable of coding aren’t necessarily capable of reading. Looking at how greylisting is done by many servers, the SMTP 450 response code is used to force a “temporary failure”, in an attempt to get rid of spam attacks; where speed of delivery is the primary concern. Spammers typically do not want to hang around and wait for a “successful delivery” if it takes more than one attempt to accomplish this. Enter greylisting. Now, just because the 450 response is the most widely used, doesn’t mean it’s the only 4xx response that needs to be handled as a temporary failure!
Yet, when Message Labs receives a 452 response code, they do not treat it like they treat a 450 response. So instead of waiting for “a while”, they retry, and retry, and retry, until they have reached their maximum number of attempts and simply go tits up (in other words, “message delivery failed”). The problem here is, of course, that greylisting demands that you wait for say, 10-15-30 minutes before trying again, otherwise it’s an obvious attempt at forcing the anti-spam barrier.
How hard can it be to read the specs?
I wonder if this is the same people that, in their code, remove files and don’t check the result of the I/O operation, and then further down the code, assume that the file MUST have been deleted OK, because exceptions never occur, right?!
Can you say FAULT TOLERANT?!