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
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
This would have been great about three years ago. Unfortunately spammers started using a victim’s MAPI settings about two years ago. In addition, big mail sites are punished by this. Why should my mail server have to do twice the work because you think this is a good idea to stop spam? My bandwidth, disk space and processor is finite too. This also breaks the quick delivery times many have come to expect from email. I don’t know how many times I’ve had to explain to everyone from customers to tecnically-inclined-boss-types why their email takes 5, 15, 30, 60 minutes to reach someone due to anything from load on our end to greylist-dainbramaged sites.
jhavard: I’m thinking about adding SPF to the greylisting implementation–automatically whitelist hosts that pass the SPF check. This could reduce the impact on legitimate senders.
Also, greylisting makes it “twice the work” for only the first message. After a sender is successfully greylisted, mail delivers as it used to–until the greylist entry expires, if your implementation expires greylist entries.
SPF works only when a small fraction of the population uses it. In addition, it does not help in those situations when the malware-infected machine is using MAPI settings to send through a legit mail server and your latest incarnation fails when that otherwise legit system has SPF records.
My Real Job pretty much is me versus all the spammers of the world hammering the mail systems at work. There is no magic bullet. Anything you can do to stop spam will work for a few weeks at best. Spam evolves quickly to counteract any new measure. They’re even using tech words to throw off bayesian filters, which are typically used by tech-types more than anything. The only permanent solution to spam is to unplug the mail server from the network and I’m not even sure if that would work…
All I know is, while my spam folder used to see ~1,000 spams an hour, now I’m seeing 10-20. I’m happy.
I used to receive tons of door-to-door salesman every single week. However, ever since I destroyed the highway leading to my house and replaced it with a long curvy muddy road that’s rarely passable the first attempt, I get maybe one a year!