I just saw a lovely comment on the Slashdot thread about SPF records pointing at an article outlining Why you shouldn’t jump on the SPF Bandwagon. Normally I’ll ignore FUD sites like this, however this one has hit a nerve particularly because I’ve had to have arguments with people here at work about their misconceptions about SPF as well.

For the uninitiated, SPF is a DNS TXT record you can place in your domain’s zone to tell SPF-capable mailservers where mail for the domain is allowed to originate from. This is very useful for mail networks where you provide outgoing authenticated SMTP, or where you can declare where mail comes from.

In fact, you can specify three different levels of mail hosts: PASS, intended for hosts you can definitively say send mail for your domain; NEUTRAL, for hosts you don’t know about; and FAIL, hosts you don’t authorise email to come from. There’s another called SOFTFAIL, but that’s not relevant in this discussion.

As a mail site that receives mail, you can define at what level you want to block mail. You can either start accepting mail at PASS or NEUTRAL. For most sites, SPF is typically configured to allow anything from NEUTRAL upwards as to not generate false positives.

The author of the above article complains that they send mail from different locations including their ISP, and that SPF is broken because it blocks mail from these locations. What the author seems to have missed is that SPF is blocking mail because THEY told it to.

That’s right, that page long rant is based off the author’s assumption they understand the technology and have configured it correctly. Going by their comments, the correct configurations could have looked like:

• PASS for all the hosts they control, NEUTRAL for known ISPs they send mail from, FAIL for the rest of the internet

• PASS for all the hosts they control, NEUTRAL for the entire internet

• PASS for all the hosts they control, and for known ISPs they send mail from, NEUTRAL for the rest of the internet

Or, quite simply - if they can’t know in advance what networks they want to send mail from… DON’T USE SPF. It’s not broken, you’re not using it right.

Because this rant still hasn’t calmed me, let’s debunk each of the reasons provided why we shouldn’t use SPF:

“SPF is not compatible with today’s Internet… “SRS is not common. If you publish SPF records, you are going to be asking people to throw away genuine email which you did actually send.

If you check SPF records strictly for anything larger than a toy domain with a handful of users, then you’re likely to be rejecting genuine email which is sent to you or your users. Pure FUD right then and there. I’ve already shown you’re not defining where your mail is coming from properly, so maybe you should either set up authenticated SMTP so you can send from your own hosts even when working away from home, or maybe you should set up an appropriate policy and stop blaming the technology.

…and won’t be compatible with tomorrow’s either. There is little incentive for people to deploy SRS. It’s a cumbersome and convoluted workaround for a broken assumption.

Those who believe SPF to be an insanely stupid idea will strongly resist, and those who are simply uninterested in SPF have little reason to want to use it. Yet SPF requires these these uninterested third parties to upgrade too – it’s not just limited to those who are participating.

People are very slow to deploy new ideas on the Internet, and especially with respect to email, even when those ideas are good. Many people haven’t even managed to deploy Extended SMTP (ESMTP) yet, even.

There will be a porcine implementation of RFC1149 before SRS is ubiquitous. Lies, lies lies! This is the same argument as the above, use the technology correctly!

SPF is not an anti-spam technique. Some people claim that SPF directly combats spam. It doesn’t. SPF attempts to address forgery. In fact, a large amount of spam rates an SPF ‘pass’ result, because spammers have rapidly adopted SPF for themselves.

You still need a blacklist or other kind of trust database, to tell you which domains are trustworthy and which are not. But we already have lots of blacklists; it’s just that we list the IP address instead of the domain name, to tell you which hosts are trustworthy and which are not. We don’t need to break email and force everyone to upgrade to some bizarre new scheme just for that. Almost a fair call, however I for one would consider address forged email as… wait, what? SPAM! The more people who use SPF (especially large organisations), the less forged (bank, paypal, ebay, etc) mail we should see!

SPF offers a whitelist, not a blacklist. In the simple case without forwarding, SPF does manage to give a clear indication that a mail is valid. But that’s not really very useful in practice. What we need is a blacklist but SPF gives us only a whitelist. We can’t safely use that to reject mail – we can only reject mail if it’s clearly invalid, but SPF can only honestly say ‘valid’ or ‘unknown’.

Not in the least true, you can specify hosts that generate a FAIL result from SPF, and using the ‘EXISTS’ mechanism to do so lets you use a DNSBL to blacklist known mail hosts. This means that SPF can in fact include an RBL (though I wouldn’t do this in practice as you’ll likely double the number of RBL checks done to the mail).

So in short, Mr Woodhouse - perhaps if you decided to take the time to do your own research you might have had better success with SPF, but that’s no excuse to slam the technology with your pointeless FUD and then spread it to other people as gospel.