SPF: Penguins Can Eat Phishes, Too
Implementing SPF, Part 2: With SPF, you can add a powerful tool to your anti-spam kit. Here's how to do it with a Linux server. Forwarding mail out of your domain? Don't forget SRS: SPF's complement.
Humans are such odd creatures. We're like the proverbial frog in the slowly-heating pot of water. Unlike the frog, we can look ahead to future, and see the boil a-coming. But do we take any action? Not til our little behinds are scalding. And sometimes not even then.
Never have so few been able to commit so much theft and vandalism with so little effort. Yet this makes little impression in the corporate suites. Which illustrates the beauty of the open source/free software development models: we don't have to wait on indifferent corporate masters when we can fix things ourselves.
Of course I'm using the collective "we", because I can't program my way out of a paper bag. But smart folks like Meng Weng Wong and Shevek can. Meng Weng Wong is the founder of pobox.com, and the inventor of SPF, Sender Policy Framework. Shevek is the primary designer of Sender Rewriting Scheme. Sender Policy Framework and Sender Rewriting Scheme work together like chocolate and peanut butter to foil domain forgery.
Why Domain Forgery Is Bad
Most spam uses forged return addresses. It's trivially easy to do, just like writing a fake return address on a paper letter. Maybe some folks don't mind their domains being misused in this manner. But a lot of us are downright peeved at having millions of spams bearing our domains on the return addresses. And I think even the most blasé Web surfer would like some assurance that their emails really come from where they claim. Like mail supposedly from banks, stores, lenders, and such. Identity theft is the main goal of spammers these days, not selling cheap V14gra.
SPF aims to make domain forgery impossible. The concept is simple. First create a DNS (define) text record that defines which servers are authorized to send mail from your domain. When a SPF-aware MTA (define) receives a message, it either verifies that the message came from a legitimate server, or that it is a forgery. Forgeries are dumped unceremoniously. Accepted messages are stamped with a SPF X-header that says the message passed the SPF check. Messages from domains that do not have SPF records are marked with a SPF X-header that notes the results of the check are unknown. Spam filters, like SpamAssassin, can be configured to factor the SPF X-header in their spam scores.
There are four parts to implementing SPF:
- Make the appropriate SPF entry in your DNS records
- Set up SASL/SMTP (define) authentication in your MTA (mail transfer agent)
- Open ports 25 and 587. Port 587 allows remote users to authenticate and access your server from locations that commonly block port 25, like hotels and Internet cafes. Also, many ISPs block port 25 for non-business users.
- Patch your MTA to support SPF. See spf.pobox.com/downloads.html for for patches and instructions
If you use forwarding servers, there is a fifth step: implement SRS. We'll get to that in a minute.