Eric Allman just emailed me his thoughts on the draft-02.9.txt.
He doesn't like the complexity of the a, mx, ptr, etc directives;
he feels that the only directives that should be there are
ip4 and ip6.
That is my opinion as well. If is is not essential and is not simple it is
probably better to remove it.
This takes us back to the first version of SPF, which drew heavily on
DMP's reversed-IP layout, and to the first version of RMX, which is
basically what Eric is talking about: only ip netblocks.
If there is going to be complexity I would rather employ it supporting a
greater range of protocols and a greater range of authentication options
than on a baroque approach to one authentication option.
John Levine criticized the first version of RMX, saying that major
domains like Yahoo would never be able to fit all their networks into
512 bytes. Indeed, pobox.com is hardly a huge ISP, and our MX servers
span seven or eight distinct networks.
The issue is one of complexity, do we put that complexity in every client
that looks up the information or do we put it into the tools to publish and
distribute this information.
It seems to me that many of the hacks envisaged in the protocol definition
could easily be implemented as DNS server extensions.
Alternatively it would be a relatively straightforward matter to add code to
a mail server installation (it need not be an extension to the server
itself, merely an installation option) which would cause it to send an
authenticated message to the DNS server each time it starts up, specifying
the IP addresses through which the server would publish.
There is a basic rule of protocol design that you should avoid putting
anything into a standards protocol that can be equally effectively
implemented as private configuration data.
We are not talking about an undue burden here. The maximum number of email
servers any one entity is going to manage is of the order of thousands. The
number of records is not a scaling issue.
When I spoke with Miles Libbey at Yahoo his objection to SPF
was exactly
that: his engineers didn't want to have to figure out which
networks the
MX servers were in, and have to keep them up to date. Since most
domains' designated mailers are already described by existing MX and A
records, I felt we should take advantage of that.
OK put code in BIND to grovel the mx records and generate the appropriate
SPF records.
I believe that the added complexity of implementing the a, mx, ptr
directives are worth it, because they make the DNS admin's job easier,
even though they make the MTA's job harder. There is a
Pareto curve to adoption.
It is not a Pareto curve, well not like the one I remember. Those are
roughly linear at the origin. Ours will be roughly flat. One of the things
that folk do not seem to get is that viral marketing and network effects are
also known as the chicken and egg problem. The big problem is getting early
adopters in.
I think that the complexity of the arrangement argues for looking at better
management tools rather than a complex protocol. It would even be possible
to separate SPF related configuration data out onto a separate DNS resolver
that only handled that data. Alternatively have the administration tool spit
out a DNS configuration file for the _spf zone.
Phill
Incidentally if you are familiar with Pareto's work you might know that he
was an Italian railway manager. He was also able to get the trains there to
run on time 80 years ahead of Mussolini. He did this by defining a train to
be on time if it could not have arrived any closer to the time it should
have arrived without making another train late. [joke for economists]
-------
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;±¤Ö¤Íµø?¡