Data Circle

If you’re running SpamAssassin on your servers you might want to check out this critical bug: FH_DATE_PAST_20XX scores on all mails dated 2010 or later. Broadly speaking, all emails with a Date: field of 2010 will trigger a SpamAssassin rule, which means that the mail will be more likely (but not definitely) to be marked as spam. Running sa-update as root fixed the problem on my system, as this updates the SpamAssassin rules. The fix is only temporary, as it will flag up mails from 2020 onwards, but hopefully the developers will have implemented a more permanent fix by then.

I get a ridiculous amount of spam (500+ emails/day), most of which is caught by Spamassasin. However, this takes its toll on my poor virtual machine, which has most of its 250MB of RAM eaten up by MySQL as it is. As a result, I’ve started to be more aggressive with the rules I apply to incoming mail, which include:

1. Reject anything from an invalid hostname.
2. Reject emails where the sender address is a non-existant domain.
3. Reject where the recipient address is a non-existant domain.
4. Reject where the domain is hosted on this server but the email address is invalid (e.g. iveabigone@roguestudents.com).
5. Check against Spamhaus RBL.
6. Greylist.

Naturally, open relaying is disabled too. I’ve also updated the DNS for all of my domains so that they only have one MX record, as secondary servers are prone to abuse and can’t usually check whether an individual address is deliverable until they pass the message on to the primary server. Greylisting has proved to be particularly effective—personally I’m not a big fan of this solution as it introduces unnecessary delays, but the trade off between mail arriving a bit later and the amount of time I have to spend dealing with spam means that enabling it is now a no-brainer.

I could increase the level of checks by rejecting mail from servers without a reverse DNS record or which don’t identify themselves correctly in HELO/EHLO, but unfortunately that impacts too much on legitimate mail from people who can’t configure servers properly.

Since implementing these checks, my spam has fallen from 500 messages per day to about 10 per day, a reduction of 98%, even though my mail server is still receiving the same number of incoming connections. Furthermore, I’m no longer seeing “out of memory” error messages on my virtual machines, which is a great relief as this usually meant downtime until I noticed the problem, followed by a reboot.

Yes, I know I could just set my MX records to Google and let Gmail do all the work for me, but I don’t like the idea of a company in the US who I have absolutely no control over holding all of my emails and performing data mining on them.