After much procrastination, I finally got around to making another improvement in my mail server setup: I’ve implemented greylisting.

“Greylisting” takes advantage of the reliable characteristics of a properly implemented mail transfer agent (MTA) and the and the unreliable nature of spam mail delivery, which typically uses zombie computers to send spam. In a nutshell, you authorize a node on the Internet to deliver mail to your mail server by maintaining a greylist. (A “whitelist” is a list of known good nodes, and a “blacklist” is a list of known bad nodes. A “greylist” tracks those which are not known to be either good nor bad.) When a node on the Internet that’s unknown to you sends you mail, you gently refuse to accept it with a 400-level (or “4xx”) response, which indicates a “temporary failure”, while adding information about the delivery attempt to a temporary list. Legitimate mail servers should attempt to redeliver the message, at which time, you will match them up to the entry in your temporary list to see that they previously tried to deliver this message to you. At this point, you’ll add that node to your “greylist” and accept the message as normal, as well as any future messages from this node.

How does this cut down on spam? Spammers employ “zombie computers”–computers they have gained control over through malware and viruses–and use them to send spam on their behalf. At the moment, these zombie computers typically do not perform reliable delivery of spam: if the destination server rejects the message, it doesn’t care. So, on the first connection from any single zombie computer, your greylist-enabled mail server will respond with a temporary failure and refuse to accept the spammer’s email. The zombie computer won’t care and won’t attempt to redeliver the message: effectively, you’ve avoided receiving that spam.

Can spammers get around this? Of course, they’ll adapt and develop more robust spam delivery systems in due time. But, until then, this is certainly a good way of cutting down on the amount of spam your mail server will have to process.

I can hear you asking, “If this is such a good technique, why doesn’t everyone just implement it? What’s the catch?” Well, the catch is, some legitimate mail can also be blocked through greylisting. How, if legitimate mailers use robust delivery systems that will redeliver mail after a temporary failure? Well, that’s exactly the problem: some legitimate mail is sent using systems that won’t attempt to redeliver mail after a temporary failure. Most commonly, these are bulk mailers (which, eerily, is essentially what a spammer is doing, anyway)–newsletters by online retailers, direct email marketing campaigns, etc. If these folks are using systems that don’t perform reliable redelivery, their messages will also get silently dropped. Of course, these folks will also have to adjust and adapt, just as their spammer counterparts will.

So, if you’re sending mail to me (or anyone whose mail is handled by my server) and it seems the mail isn’t getting through, perhaps you’re running into an issue with my greylisting implementation. Get in touch with me another way (leave a comment on this blog, call me if you have my number, etc.) and I’ll work with you to add you to my whitelist, so your mail will get through.

What do you think of greylisting? Is it a reasonable measure to take against bulk mailing spammers? Is the possibility of not receiving mail from some senders a real problem? What anti-spam measures have you implemented? How well is it working out for you?

Tags:
email,
spam,
greylisting

Happy Friday the 13th, everyone! Stay away from black cats and ladders, if you’re superstitious like that.

In case you missed it, Yahoo! released their Yahoo! Browser-Based Authentication (BBAuth) to the world to use. For web properties that integrate it, it provides a Single Sign-On (SSO) facility so you can log into other sites–like this blog–using your existing Yahoo! username, instead of creating a new account here.

I’ve gone ahead and spent the hour to integrate it into my blog comments system, so now you can authenticate using your Yahoo! ID and leave comments here.

One caveat for early integrators: Yahoo! BBAuth expects the “sig” signature to be all lowercase. If your MD5 function returns the hash as an uppercase hexadecimal value, Yahoo! BBAuth will complain in a non-obvious way. I discovered this through a bit of trial and error–mostly error, and head-scratching. I eventually squashed my MD5 hash to lowercase and everything worked great.

Here’s just another attempt on my part to lower the bar to make it easier for everyone to leave comments. :-)

Tags:
Yahoo!,
web,
authentication,
BBAuth