SPF Design Frozen

Eric S. Smith writes "SPF, previously mentioned here, is a step closer to becoming a real, live RFC. We are encouraged to publish SPF records and thus to hasten the beginning of the end for annoying spam forgeries. SPF describes DNS TXT records that define the hosts authorized to send mail on behalf of users in your domain. Sites can then consult your SPF records and reject spam forged to look like it comes from you." (SPF stands for "Sender Permitted From.")

Comments

I like it, but....

[hawkbug]

This is a great idea. I'm all in favor of it. I would update my companies DNS to this new standard immediately. But, I envision these issues, correct me if I'm wrong:

1) Increased network traffic at all points - where one mail server gets the email, and the network of the domain being sent from or forged. Imagine how this might increase AOL's or hotmail's network traffic, while they gain nothing from it. Every mail server in the world could be trying to contact their dns servers to check if they allow the mail. I hope you like lag if you use AOL.

2) Spammers tend to use made up domains anyways. This is bad with this method for several reasons. The first being that you will have delayed email receiving times because your mail server will be trying to contact dns servers that don't exist. The timeout would have to be short for this to work.... then on the other hand, if the timeout is too short, and a busy mail server can't respond in time, the email is rejected, which is just as bad as a real email getting flagged as spam, aka a false positive.

While I agree in practice with this technology, I'd like to see how people can solve these issues before I would use it at my company.

Re:I like it, but....

[eakerin]

1) this shouldn't generate that much traffic, it's only one (or possibly more, depending on how you have it setup) query per domain, most likely the information will be cached as well (depening on the TTL set).

2) Most mailservers don't accept mail from domains that don't exist (eg, they already query the DNS servers of the domain in question) and since the timeout for a DNS response is rather short, it shouldn't affect mail receipt that much.

Actually the whole thing could be handled in 1 query, just look up the SPF record for the domain in question, if it comes up with NXDOMAIN, that domain didn't exist in the first place. if it didn't fail, but didn't find the SPF record, then we try TXT, if that dosn't show up, then we just allow the mail through.

if a mailserver has a problem accepting mail it also returns an error message, basically telling the remote server to try later, or another mailserver. so no mail is lost (unless the servers remain loaded down and un-responsive for about a day)

Oh, and I've already setup the record for my domain, and I'll be updating my MTA to query them soon!

Internet does not work that way

[bluGill]

Your points are both invalid.

1) Most mail servers already to a return DNS lookup on the IP of who the sender is. (The recived from lines in the headers) DNS takes so little bandwidth compared to normal activity (even compared to the payload of the email it is tiny, not consider all the web browsing, DNS is trivial)

2)DNS works by asking the root servers who owns a domain. The root servers respond either with the DNS for the domain, or with a no such domain. (Ever hear of Verisign's sitefinder? Verisign runs the root servers, and they started saying anything unowned belonged to them) Essentially no overhead is involved in this.

Adoption Rate

[jhunsake]

I know I'm going to put the SPF records in as soon as I get a chance, but these statistics aren't terribly optimistic so far:

http://www.infinitepenguins.net/SPF/register.php

This system serves to monitor the take-up of SPF. So far, 274 domains with SPF records are known.
As yet, only a count of registered domains is displayed; more analysis tools will appear once the number of domains increases.

Of these:
84 parse cleanly
0 parse with warnings
173 parse with errors
17 are yet to be checked by this system

How does this reduce spam in any shape or form?

[onomatomania]

Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.

But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.

Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)

Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.

So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.

So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.

Summary for mail & network admins

[CrystalFalcon]

If your MX record is also the IP(s) used for outgoing mail, as in my case, all you have to do is add this line to your DNS:

[domainname] IN TXT "v=spf1 +mx -all"

That's it. That's really it, at least for publishing your permissions. So simple I already did it for my domains.