The cult of SPF lives

Years ago, prior to the public discussions of Domain Keys, there was SPF as the solution to all our email authentication problems. SPF was going to let people do all sorts of things with email. The proponents even privately asserted that it would solve the spam problem. In essence, SPF was a cult. BoF sessions at meetings had the flavor of a big tent style revival. Those of us who didn’t support SPF were shunned and belittled. How could we not support such a brilliant protocol? Did we want spam to continue being a problem? All our objections no matter how rooted in reality were dismissed out of hand. SPF was an evangelical, cult-like movement.
I am somewhat sad to announce that the cult of SPF still lives. The most recent example is the number of people that have taken me to task for a recent post I wrote pointing out that SPF records aren’t actually that important for email delivery. My example was that a client of mine had incorrect SPF records (with a -all even) but was still getting inbox delivery at Hotmail. We repaired the records, re-registered them with Hotmail and Hotmail not only isn’t checking them but also sent mail to me admitting they don’t check SPF for incoming email.
My statement was that SPF wasn’t really important to getting email delivered. This seems to have upset a number of people. Someone on twitter pointed out that a valid SPF record gave you a positive score with SpamAssassin. What they didn’t mention was that a valid SPF record gives you an entire -0.001 with SpamAssassin.
Today I get a comment from Tom (which seems more like an ad for his company than an actual comment) that says

When the received timestamp on a message can make the difference as to whether or not you get a multi-million dollar contract or not, do you want to take the risk of having to explain to management that you didn’t take the 5 minutes to register a single DNS entry that may have made a difference?

Tom, I don’t think you understand what SPF is. SPF has nothing to do with timestamps. Having a record or not having a record doesn’t change anything about the time of a message. If a sender doesn’t have a SPF record the time of lookup for that SPF record is going to be the same as if they did.

In fact, in the quick and dirty test I just did here looking at two major ISPs: Yahoo, which doesn’t publish SPF and Hotmail which does publish SPF. Both records are coming back in less than 100 msec. If tens of milliseconds are the difference between getting the contract and not, you have bigger problems than the presence or absence of a SPF record.
So, yes, the cult of SPF still lives, and still makes no sense. SPF still doesn’t do anything to authenticate email. It doesn’t do anything to make any of us safer. Most of the major players in the SPF movement have moved on to other projects. Even Hotmail, that evangelized SenderID (spf v.2), has mostly abandoned it. But, still, the true-believers come out of the woodwork with anecdata about how SPF is vital and important.
Except it’s not actually vital nor important. And it’s long past time for the cult of SPF to die.

Related Posts

SPF records: not really all that important

I’ve been working through some Hotmail issues with a client over the last few months. One of the things that has become clear to me is how little Hotmail actually does with SPF records. In fact, Hotmail completely ignored my client’s SPF record and continued to deliver email into the inbox.
This isn’t just a sender that had a “well, we think most of our email will come from these IPs but aren’t telling you to throw away email that doesn’t” record. In fact, this client specifically said “if email doesn’t come from this /28 range of email addresses, then it is unauthorized and should be thrown away.” The email was being sent from an IP outside of the range listed in the SPF record.
As part of the process involved in fixing the delivery problems, I had the client update their SPF record and then I enrolled their domain in the SenderID program at Hotmail. This didn’t have any effect, though. Hotmail is still not checking SPF for this client. When I asked Hotmail what was going on they said, “We do not do lookups on every sender’s mail.”
So, there you have it folks. The last bastion of SPF/SenderID has abandoned the technology. Even a totally invalid SPF record doesn’t matter, mail can still reach the inbox at Hotmail.

Read More

How to disable a domain

Sometimes you might want to make it clear that a domain isn’t valid for email.
Perhaps it’s a domain or subdomain that’s just used for infrastructure, perhaps it’s a brand-specific domain you’re only using for a website. Or perhaps you’re a target for phishing and you’ve acquired some lookalike domains, either pre-emptively or after enforcement action against a phisher, and you want to make clear that the domain isn’t legitimate for email.
There are several things to check before disabling email.
1. Are you receiving email at the domain? Is anyone else?
Check the MX records for the domain, using “host -t mx example.com” from a unix commandline, or using an online DNS tool such as xnnd.com.
If they’re pointing at a mailserver you control, check to see where that mail goes. Has anything been sent there recently?
If they’re pointing at a mailserver that isn’t yours, try and find out why.
If there are no MX records, but there is an A record for the domain then mail will be delivered there instead. Check whether that machine receives email for the domain and, if so, what it does with it.
Try sending mail to postmaster@ the domain, for instance postmaster@example.com. If you don’t get a bounce within a few minutes then that mail may be being delivered somewhere.
2. Are you sending email from the domain? Is anyone else?
You’re more likely to know whether you’re sending mail using the domain, but there’s a special case that many people forget. If there’s a server that has as it’s hostname the domain you’re trying to shut down then any system software running no that server – monitoring software, security alerts, output from cron and so on – is probably using that hostname to send mail. If so, fix that before you go any further.
3. Will you need mail sent to that domain for retrieving passwords?
If there are any services that might have been set up using an email address at the domain then you might need a working email address there to retrieve lost passwords. Having to set email back up for the domain in the future to recover a password is time consuming and annoying.
The domain registration for the domain itself is a common case, but if there’s any dns or web hosting being used for the domain, check the contact information being used there.
4. How will people contact you about the domain?
Even if you’re not using the domain for email it’s quite possible that someone may need to contact you about the domain, and odds are good they’ll want to use email. Make sure that the domain registration includes valid contact information that identifies you as the owner and allows people to contact you easily.
If you’re hosting web content using the domain, make sure there’s some way to contact you listed there. If you’re not, consider putting a minimal webpage there explaining the ownership, with a link to your main corporate website.
5. Disabling email
The easiest way to disable email for a domain is to add three DNS records for the domain. In bind format, they look like:

Read More

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More