fred avolio's musings

In June 2003’s NetSec Letter #27, “Spam Control,” I described various methods of controlling spam, including my set-up. I gave an update in my blog entry “My Current Spam Barrier.” Since then I have made some changes, which I describe here.

First, I want to briefly (for detail see the above URLs) remind you of what I’ve done, and tell you why I made a change. While I receive e-mail through the mail servers for Avolio Consulting (avolio.com), I have an ISP for connectivity to the Internet from my home and office. I decided mail would flow like this:

Internet → avolio server → ISP → mailbox@ISP

I did this because the ISP provided a web interface for when I was away from my e-mail client, and because the ISP has a full-time staff of people doing backups and otherwise maintaining the e-mail servers… I guess.

An added benefit was that the ISP filtered mail through a spam-catcher. It was very effective. Any spam that got through to that mailbox was stopped. And it was extremely rare that any nonspam was misfiled. So reliable was it that I just stopped checking the Spam folder.

So, why did I change? The ISP implemented what seemed to me to be a malfunctioning sender verification system. Daily, I found e-mail delayed in my avolio.com queue waiting to deliver to my ISP mailbox due to a sender verification problem. Sometimes it was spam (so, it was doing its job). Often — usually — it was legitimate e-mail. Further, it was e-mail from addresses that had previously worked. Finally, one day came the straw the broke this camel’s back, with 3 messages from a friend delayed. I stopped forwarding e-mail to my ISP mailbox. And started to get a bunch of spam.

You see, the things I had put in place were fairly effective. But, not effective enough. The ISP’s spam filter was picking up the slack for what I missed with PostFix and Spamassassin. I needed to add something more.

The something I added is greylisting. It is described in Evan Harris’ whitepaper “ The Next Step in the Spam Control War: Greylisting.” Simply put, it looks at the IP address of the host attempting the delivery, the envelope sender address, and the envelope recipient address. “If we have never seen this triplet before, then [we] refuse this delivery and any others that may come within a certain period of time with a temporary failure.” This works because “Any well behaved message transfer agent (MTA) should attempt retries” if given a soft error message (a 400-level error, such as one meaning “service unavailable, try later”). This delay only occurs the first time an attempt is made. So, it only affects the first ever attempted delivery from a particular IP address from a particular sender, to a particular user’s mailbox. All other attempts breeze through.

I won’t go into more detail than this; read the paper. I am currently implementing this in PostFix using the a greylisting extension. And, it is great. I’ve dramatically reduced the incoming spam. I’ve also cut down the number of spam messages I used to catch in my spam “hold” box (see my previous blog, mentioned above) from roughly 100 a day (remember, these were quarantined for me to quickly check out and toss) to under 10 a day, and sometimes none. I’ve also gotten no complaints from users about missing mailing list e-mails, nor from senders complaining about e-mail bouncing. A review of the mail logs indicate that legitimate (non-spam) e-mail that is greylisted is retried by the sending system in an hour, and some systems retry in 10 minutes.

Will it work forever? No. But it works very well for now.