swisspig.net - To hell with the pig... I'm going to Switzerland.

Spam Filtering (Tuesday, December 20, 2005)

So I've done a bit more with hardening swisspig.net against the evil deluge of spam. In an effort to be more compatible with some of the major players out there (and to make sure no one can send e-mails that wrongly claim to be from swisspig.net), I decided it was time to implement Sender Policy Framework (or SPF). As I mentioned the other day, I updated by DNS record to publish an SPF entry to protect against people forging my domain, but since then, I've upgraded Exim to 4.60, and I've configured it to check the SPF entry for incoming mails.

Originally, I wanted to use the built-in experimental SPF feature, however, I was unable to get libspf2-1.25 to pass its own self-check, so I abandoned that, and following the steps at a mirror of the Linux Document Project HOWTO on Spam Filtering. The section on adding SPF checks to Exim was unable to figure out how to use spfd, and instead forks the spfquery command for each message. I, being slightly more ambitious, followed the instructions on the OpenSPF site, and got spfd up and running with no problem, and fully integrated with Exim. I also wrote a little script to live in /etc/init.d and /etc/rc*.d that manages the SPF daemon.

I also added a check to drop messages with an SPF status of neutral or softfail, as those basically mean the From: line is bogus. Anyone who publishes an SPF entry is going to positively affirm any legitimate sender, so I think I'm safe with this. I'm logging senders just in case, but I'm not too worried. As a backup, someone can always use my contact page to reach me.

After a fair bit of testing, I'm happy with the way SPF is implemented for swisspig.net, but I should point out that SPF is certainly not a perfect solution, for a variety of reasons, which are eloquently enumerated at advogato.org. The author has a fair point about forwarding — expecting someone else to re-configure their server to implement SRS is not exactly reasonable, and I also agree that SRS is not really a very pleasant approach. In a nutshell, the problem is that (for example) when someone sends an e-mail from their hotmail.com account to my university account, the message is automatically forwarded to an account at swisspig.net. In this case, SPF fails, because the incoming connection is from the university, but the From: line is hotmail.com, which of course does not list the university as an appropriate origin. There's a similar problem with my acm.org forwarder. So I worked around this problem by specifying that messages coming in from my forwarded accounts should skip the SPF check. I justify that approach by (fool-heartedly) assuming that since the ACM and the university are receiving the mail that they will be checking for spam on their ends, before the message is forwarded on to me.

So anyway, SPF deals with two issues: people forging swisspig.net on their From: line, and people forging other domains that implement SPF. Unfortunately, my most recent spam message had a forged yahoo.com from line, and Yahoo! has decided not to publish an SPF record, and instead go with Domain Keys. Unfortunately, Domain Keys are absurdly complicated — or perhaps merely poorly documented. And as there is no stable implementation for Exim yet... well, we'll just have to wait.

But there's more than one way to skin a cat. Just out of morbid curiosity, I decided to check out the real-time black hole facility in Exim. Once upon a time, before I had my own domain, I was very interested in the MAPS list hosted on mail-abuse.com, however I was not so pleased to discover that they were acquired by Trend Micro and no longer provide a free service. But a few quick searches later, and I found what I was looking for. The Multi-RBL check was able to go through a whole slew of DNS based RBL lists and tell me that the IP address my yahoo.com spam came from was, in fact, a known spammer IP address. That was found on the spamhaus list, which is a combination of several lists that keep track of open relays, known spammers, and other stuff. I also decided on the SpamCop Blocking List, as I've been forwarding all of my spam to them for several years. So I added those to my Exim configuration, though it's configured to just log the results, rather than take any hard action, for now.

—Brian (12/20/2005 11:23 PM)
(0 comments)

Comments

No comments.

Name
URL
Comment
(no html)
 

Disclaimer: Opinions on this site are those of Brian Ziman and do not necessarily
reflect the views of any other organizations or businesses mentioned.