Oh, teh irony!!1
Last updated: Tue, 12 Dec 2006 11:01:00 GMT
And I'm not talking about Allanniss Morrissette, either.
Blogger just bounced this mail back to me:
Blogger could not process your message at this time. Error code: 6.199D78C Original message: From: car@jessies.org Date: Tue, 12 Dec 2006 11:31:04 +1300 Subject: Microsoft in violation of established protocol shocker. I use greylisting to filter out spam. I like it. It's cheap and very effective. Greylisting relies on a specific set of behaviours from good SMTP senders, because it effectively bars messages from SMTP senders that are not well behaved -- namely, pump and dump merchants. Greylisting relies on good MTAs heeding a temporary error and retrying; the receiving server will recognise subsequent attempts to send the same message, from the same sending server, as a sign that the sending server is a good guy. It's no good against 419 scammers, because they all have real email addresses, messages sent via real MTAs. But it cuts through your spam like a knife, before you've even gone to the expense of receiving a message. Unfortunately, RFCs 821 and 2821 are a little bit fuzzy in places. They state that SMTP senders MUST retry if a message fails temporarily, they state that a sender SHOULD delay the retry for 30 minutes, they suggest two connection attempts in the first hour and then one every two or three hours, for four to five days. They state that a temporary error (so-called "4xy errors") indicates that the message will be received successfully if another attempt is made with no changes to the properties of the sender or receiver. This is the sticky bit. What constitutes a "property of the sender"? Arguably, one might suggest that the IP address of the sender is a property, but RFC2821, as RFC821 before it, makes some attempt to be transport agnostic. So, if you've got a pool of MTAs, all pulling messages from the same spool, you can see that your greylisting server isn't necessarily going to tie together multiple attempts from all those different IP addresses. The RFCs' vagueness, for the sake of agnosticism, doesn't help. There are ways around this. You can construct your greylisting system such that it considers IP addresses within the same /24 block to be sufficiently close. You can maintain a whitelist of known "good but misbehaved" servers. Gmail, for instance. Both work well enough, but regular maintenance is essential. I applied for a job, recently, with an American company over here in NZ. I'd been waiting for a while, expecting to receive further details, but no sign. So, I checked my mail logs. Their MTA had attempted once, been told to retry, attempted a second time five minutes later and then given up, bouncing the message to the sender. Hmm. Unfortunately, such behaviour doesn't contravene RFC2821, it merely ignores suggested retry strategies, which they're pretty much allowed to do. Luckily, the sender read the informative error message and followed the instructions therein -- mail postmaster. As per RFC, mail to postmaster is always accepted, and passed straight on to me. The best yet, though, by far, is Hotmail's behaviour. Hotmail bounces mail straight back to sender after the first temporary error, and so that their users don't get their brains all heated up, they don't even include the error message. There's no indication whatsoever of the nature of the error. Nice. Well done, Hotmail: SMTP senders MUST retry, SMTP senders SHOULD delay the first retry by 30 minutes, it is suggested that SMTP senders retry for four to five days. There's probably something in there about passing information back to message originators in the case of errors, too, but I've got better things to do than read RFC2821 again. Whatever way you cut it, bouncing the message back to sender, blind and uniformed, on receipt of a temporary error, is pretty damned weak. Not a great shock, though, eh?
Error code 6.199D78C, was it? That's a nasty one.
You have to laugh.