According to this page, SPF is the 8th deadly sin. I think its failings have really been blown out of proportion and I'm here to address them.



Please feel free to send me feedback: tensai at zmonkey dot org. As always, I reserve the right to be wrong. Oooh, but if I'm correct I reserve the right to rub it in your face.

SPF breaks pre-delivery forwarding


SMTP-based Internet mail is, by design, a "store and forward" architecture. Mail is transported from machine to machine, stored and then forwarded on, until it finally reaches its destination.

Maybe it did when UUCP was popular. Check your email headers. Mail usually only makes one hop over the internet. Internally we use a whole slew of SMTP server to bounce mail around and load balance, of course, but we don't have a problem with spam at that layer.



Besides which, spammers have taken advantage of the "store and forward" delivery methods to send more spam. The idea is to send spam to a possibly non-existant recipient and set the sender to another possibly non-existant recipient. When the first recipient's mail server rejects the message, the victim MTA tries to return it to the second recipient. Most often that one fails too and your MTA gets left with a whole mess. Spamcop (curse their hearts) has now started blacklisting sites who use delayed delivery mechanisms just for that reason.



Store and forward may have been useful at one point, but we don't really need it. Even if we did, we can't use it because of the rampant abuse.

SPF is at loggerheads with RFC 1123

Here-in lies the best argument against SPF. I don't claim that it doesn't break forwarding. It does. There, I've said it.



Perhaps SRS is the answer. I'm not really too keen on it either. Just seems a little messed up.



Maybe forwarding is broken to begin with. Maybe sending mail from an outside domain isn't a good idea at all. Why not push the forwards back to the origin mail server. The forwarding MTA could return a "422 <forward@example.com>" message and the source MTA could continue from there.



I admit this portion of SPF isn't sufficiently resolved to my liking.

SPF is at loggerheads with RFC 974 and RFC 2821

I don't see the utility in using a fallback MX. Check my domain. There's only one, but I've never had a problem with it either. For example, just last week I added SPF checking to Exim but I forgot to add startup scripts for spfd. So when the power went out on Sunday, spfd didn't start back up. That left Exim giving out 451 errors for every message.



Well I finally noticed it on Tuesday and fixed the problem. About 15 minutes or so all my delayed email started arriving. That's because the remote servers had just queued up the email for later, or until they finally gave up which luckily didn't happen.



What would have happened had I had a backup MX? Pretty much the same. The backup would have accepted all my mail from the remote servers and then tried to deliver it to me. If my server had never come back up, the backup MX would have given up too. I don't really see the benefit in that. Plus you have to duplicate your anti-spam setup. And it causes problems with IP blacklists as well. Not to mention all the problems with delayed bounces of spam.



But if you really do want that behavior, that's fine. Tell your MTA to ignore SPF checks from your backup MX. It's a piece of cake with the Exim ACLs and I assume it's possible with others.

SPF hijacks existing DNS mechanisms

A zone can have as many TXT records as it wants. As long as no other TXT record needs to start with v=spf1, it should be fine. How many people actually define TXT records anyway?



Perhaps it would be better to define an SPF record. The drawback there is that everybody's DNS server would require an upgrade. Seems to me that leveraging an existing technology is easier.

SPF gives ISPs a "lock-in" weapon against their customers

News flash: you're already locked in. Your email is going to be delivered to you ISP's mail servers no matter what you do. If you really have such a big problem with your ISP's server, it's probably time to get a new ISP.

SPF is useless for several entire classes of people

Huh? What classes of people? Those without email? I don't follow this one. Somebody like to explain it?

SPF is useless for SMTP Relay clients with dynamically-assigned IP addresses
Whilst it is impractical and a bad idea (because it allows mail to be intercepted or to be lost) ...

If it's impractical and a bad idea, why do we have to worry about it?

SPF is useless for roaming SMTP Relay clients

Just publish an open-ended SPF record and be done with it. I think in the long run, setting up a permanent mail relay with SMTP AUTH will be more effective. Consider all the ISPs who have begun blocking outbound port 25. How will your mobile client send email in that case? And like it or not, those cases are becoming quite prevalent. I, for one, will fight against any such implementation but not everyone shares my line of reasoning.

SPF relies upon DNS for security, but DNS isn't a security service

Mail relies on DNS. HTTP relies on DNS. Just about everything relies on DNS. Nobody seems to be racing forward with DNSSEC despite all the chicken-little worries about DNS being so insecure. If DNS is a critical failing of SPF, we've got some other serious issues.

SPF is vulnerable to race conditions during database changes

So are MX changes. And A, and CNAME, and everything else to do with DNS. I've worked with incompetant DNS admins who can screw up just about any change. And I've worked with excellent admins and it's usually not a problem. But this isn't something new introduced with SPF.

SPF creates new categories of third class citizenship

As opposed to what? We have to do something about spam, that much is clear. SMTP has failings, one of those being that sender addresses are rediculously easy to forge. I suppose another alternative would be to switch to another protocol, like X.500 or MAPI. *shudder*. Do you think in those circumstances there will be segregated mail systems?



Or we can let spam run rampant and people will stop using SMTP completely. Internal email will be it. How's that for cutting off the "third class"?

SPF doesn't actually address unsolicited bulk mail at all

That's why SPF doesn't stand for Spam Prevention Force. All it ever has claimed to do is verify the sender. Once mail can be verified we can start locking down domains that send out crap.

SPF hands Verisign its next unwelcome "innovation" on a platter

Since they seem to be so good at coming up with these great "innovations", that's certainly a prospect we would be best to avoid. Letting them keep the reigns to the .com and .net after they've shown they are a poor steward is the real problem. Verisign's lawsuit against ICANN failed, so the possibility of bringing back Site Finder or any other service is pretty low (although never too low for the likes of Verisign).



But should we ignore the benefits of SPF just because Verisign might someday do something rude? That's pretty absurd. When Verisign pulls its next stunt, how about we just kick them in the groin.