I think we all agree that the _spf.domain.com is a
technically cleaner
solution that provides quite a number of benefits. But, the decision
to not use _spf has much more to do with the landscape of DNS
today and
the ability to deploy SPF.
It is an issue that works differently if you are above or bellow critical
mass.
If you are bellow critical mass then lowering the learning curve is
important.
If you are close to or above critical mass then the issue becomes the impact
on the legacy infrastructure. Making use of the only extension field that
works in DNS is a pretty serious issue.
You misunderstood Meng: Nobody really cares that upon careful reading
of the RFCs, underscore DNS names are legal as long as they are not
host names. In this case, the nobodies are some DNS service
providers,
and some DNS software authors.
Paul Vixie invented the underscore convention, and wrote BIND. Underscores
are required for SRV and have been implemented for about six years or so.
I'm sad DNS
doesn't have a built-in decentralized extension mechanism. (Why not
have: "foo IN EXT type=com.pobox.spf, text="+mx +ptr -all", and allow
queries to restrict the range of EXT records based on prefix matching
of the type so as to limit the amount of returned data?) But, alas,
DNS was designed in an era where every byte was expensive,
and software
update across the whole infrastructure was a reasonable idea.
And as a consequence the Internet has made very little forward progress in
20 years. Pretty much every Internet protocol has stopped developing within
a few years of first being proposed.
We have a chance to fix that here. The root cause of the spam problem is
that the Internet protocols have no upgrade mechanism and the IETF has no
real interest in the needs of 99.95% of the Internet user base.
Remember that we also want to be able to use the TXT record to do
other stuff ourselves...
Yes, TXT records need an extension mechanism. Assuming that
any other
project that decides to publish information via TXT records comes to
the same conclusions that SPF does, they'll want to put their TXT
record directly in the domain. SPF has started the convention of
starting such records with "v=".
And we end up with responses over 500 bytes, game over.
Note that some of your examples, notably Receiver Info, can done by
extending SPF. SPF was designed so that the information it asserts
about mail from the domain can be extended. I can easily imagine
"v=spf +mx +domainkey -all", someone just needs write RFC for the
'domainkey' mechanism.
How do I encode the public key for the sender domain without causing every
SPF query to blow past the 500 byte limit?
You do not want to get all the data that every auth scheme possible can
throw out.
Phill
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡