It seems to me that many of the hacks envisaged in the
protocol definition
could easily be implemented as DNS server extensions.
The sheer elegance of the current SPF protocol is precisely
the fact that no
"DNS server extensions" are required. It all fits smoothly
into current DNS.
If you think getting the current protocol draft adopted is
hard, try getting
people, all over the world, to change their DNS server!
The hacks appear to be targetted at addressing the problems faced by five,
six, perhaps twenty large ISPs. Most ISPs have one or maybe two outgoing
mail servers.
OK put code in BIND to grovel the mx records and generate
the appropriate
SPF records.
Such code already exists; query the MX records, and BIND will
tell you their
names + IP addresses. :) All kidding aside, this is what
makes the current
SPF protocol so easy to adopt, that it readily integrates
into existing DNS
But that assumes that your incomming mail server is also your outgoing. That
is not the case for huge numbers of users. Our configuration at VeriSign has
never used the same server for both.
-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡