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.
Spam filters, like SpamAssassin, can be configured to factor the SPF X-header in their spam scores. |
Many many people have been warning about the current explosion and destructiveness of spam for years. Thanks to spam and the non-existent security model of the most popular desktop computing platform, the Internet is a scary, dangerous, polluted place. E-mail has been rendered nearly useless. Billions of dollars are wasted, and trust is destroyed, because of the actions of a few thousand spammers, bless their black little hearts.
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.
Continued on page 2: Putting Things Together
Warnings
This is all still experimental, though many large networks are using it successfully. Your MTA will probably need to be patched to support SPF. Don’t do this on a production system until you’ve worked out the kinks on a test system.
Writing The SPF DNS Entry
This part is easy, just use this is nice wizard. A tinydns entry looks like this:
'forgemenot.net:v=spf1 a mx ptr -all:3600 '*.mail1.psmtp.com:v=spf1 a -all:3600 'mail.forgemenot.net:v=spf1 a -all:3600 'forgemenot.net.mail1.psmtp.com:v=spf1 a -all:3600 'forgemenot.net.mail2.psmtp.com:v=spf1 a -all:3600
The wizard also spits out usable BIND entries. Click the “Explain” button to learn what everything means.
SASL/SMTP Auth
It doesn’t make much sense to implement SPF without also requiring users to authenticate to your SMTP server. Most folks use Cyrus SASL. Here are some pointers for the different MTAs:
- Postfix SMTP AUTH (and TLS) HOWTO
- Sendmail-SMTP-AUTH-TLS-Howto
- Exim SMTP authentication
- SMTP authentication for Qmail
Enabling SPF Over Forwarding
SPF is fairly simple to implement if you’re not using forwarding. But if you are, it breaks all to heck. Suppose you are forwarding through a smarthost, or maybe you host several domains that are forwarded through a single domain. Any time you forward mail from one domain to another, you’ll need to use SRS, Sender Rewriting Scheme. Again this requires patching your MTA. Visit the SRS home page for downloads and documentation.
Testing SPF
Visit the tools page. There are links to several test pages.
Registering Your SPFed Domain
A nice final step is to register your domain at the SPFtools registration page. This lets the fine folks who are developing and supporting SPF know how many admins are deploying it.
SPF/SRS promises to be an effective anti-spam tool. It’s lightweight and low-maintenance, so you won’t have to babysit it, or make choices between security and performance.
