So, like, the other day John Capo mumbled:
Don't forget that SPF needs to become an RFC. This is a difficult
task at best. I don't think that the RFC folk will have any interest
in overloading the HTTP protocol to fetch SPF records.
Personally I agree with Eric Raymond that TXT records at the top
level are not the proper place for SPF data. A distinct RR type
would be best but that's a major battle. Hijacking an unused,
existing, already supported, RR type might be the way to go.
Just thinking out loud here...
So why not two-stage the development process in order to "get it right?"
Phase in the initial TXT records, but write the draft stating that it
will (er, should?) be migrate to new SPF RR records. Over time, it
can be migrated to real RR records then.
People _do_ up-rev their BIND on a fairly regular basis. Just look
at the whirl-wind that Verislime produced with the wildcard fiasco
and the almost immediate hack-n-adopt that fell out. People _are_
willing to adopt new DNS implementations. Sure, the actual RFC
process to get the a new SPF RR approved will be painful and time
consuming. So use the almost-right-SPF-in-TXT records as the
existence proof and ironing-it-out stage.
If TXT records are to be the mechanism then I think they should be
in a subdomain like _spf and not at the top level.
Let's try this one on for size. One reason people don't like
the "_spf" sub-domain is because of the leading undescore.
Why not just state "spf" instead? I mean, if years ago someone
had proposed that all those new-fangled WWW pages be placed
not at the top-level domain but instead at "_www" instead,
there would have been hell to pay! The simple "www."-prefix
came and stuck just fine, while others prefer to still just
use the original TLD name anyway. (And some do both.)
Yes, there is the potential name-space collison. But there was
back in the initial "www." days too. People coped. Sub-domains
get introduced for various reasons all the time. A "cvs." prefix
came in and just gets used all over the place as well. It happens.
Isn't it possible to just stake-out some new territory?
I am sure there are enough people interested in rapid, wide deployment
of SPF that we could contribute at least secondaries for the fallback
domain. Creating a semi-public, need some validation to keep spammers
out, SPF publishing mechanism would require considerably less effort
than implementing HTTP overloading in every MTA in use on the planet.
So, I was pondering how the proposed HTTP mechanism might
be abused too. Anyone thought through that one yet?
What if two different publishers of web content on virtual
hosts ended up "competing" for the content of that file on
the one real server? Would it be possible for a spammer
published "accept all" records to some website?
Pondering,
jdl
-------
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.6.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡