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

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.

Re:Internet does not work that way

[Linux_ho]

Also don't forget that DNS caches, so SPF data for popular domains would be cached all over the Internet. Your local DNS server would only make one query to the authoritative server every ttl period.

Re:Internet does not work that way

[Cyber Bear]

Yes, I have heard of Verisigns dirty tactics. What don't understand is how the root servers can return the DNS, when I change ours constantly, and I don't allow domain transfers to root servers... I allow transfers to specific dns server, so do root servers get a transfer by default? I assumed that if a domain name exists, the dns request is passed onto the authorative dns server... is this incorrect?"

Yes, that is incorrect. The root DNS servers hold the DNS glue records for each registered domain. DNS glue records are the NS records created from the DNS server information you specified when you registered the domain. So, you may be changing A, PTR, and CNAME records all you want, but the DNS glue records for your domain don't change unless you make a change with your domain registrar.

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

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.

ASRG SPF pointers; not shot to ribbons

[TimFreeman]

The parent says

SPF was shot to ribbons on the IETF ASRG list...

but offers no pointers to allegedly valid objections. Here are some pointers into the ASRG discussion. I didn't see any compelling criticisms of SPF there. The criticism that SPF "is not a serious technical effort" is odd, given that an implementation exists.

Law of Beta strikes again

[Wechsler]

The registry was only actually completed today; the parser wasn't fully operational before that (it was just online for testing).

Unfortunately some of you caught the parser while it was buggy... it *should* be fine now.

It's also correct that some of the records were produced before the standard was finalised. All these bugs should now be out of the system (I'm going to regret saying that)...