On Sun, Sep 26, 2004 at 02:52:53PM -0600, Commerco WebMaster wrote:
Questions for consideration -
Should we look at employing an _spfX.domain.tld standard (where X = major
version - e.g., 1, 2, etc), as that will help an administrator to know what
version the inquirer is looking for in an SPF record? After a point,
maintaining too many versions of SPF records may become burdensome to
administrators and the DNS service itself. By knowing this a publisher
might be able to contact a v=spf1 user when v=spf4 is the norm, to let them
know that they are publishing a very old and perhaps even obsolete
version. I personally don't care much for this approach because it
intrinsically requires more maintenance, though it absolutely does serve to
determine which version a requesting party is really looking for, if that
is of value to a publisher.
The use of prefixes does not work nicely with wildcards (in my opinion that is,
others have a different opinion varying from 'it works ok' to 'you shouldnt use
wildcards anyway').
Should we maintain code and SPF TXT records that presume upward
compatibility in the specification, such that an spf1 aware application
will simply look at the spf part of the v= and presume that it can always
use spf1 syntax as was understood in spf1? While I like this approach, I
think it might lead to redundant data being send by DNS servers in TXT or
SPF RR records for different SPF versions if they are maintained together
(e.g., spf1 and spf2.0 concurrently maintained and delivered). If they are
not (in other words, when implementing spf2.0, spf1 records are dropped),
then perhaps this makes sense, though it would require existing
implementations of spf1 to become revised, which might be a problem.
The problem is I think that then at some point you publish v=spf1, v=spf2.0,
v=spf2.1, v=spf3, etc.. Because you don't want to drop support for older record
types as long as people are requesting it. At some point it becomes too much
for the dns protocol to handle...
Alternatively, should we maintain and code presuming that we check for SPF
TXT records based upon a need to handle an incrementing quantities of data
strategy? By this, I mean should code look at the spf1 record, get what it
needs there and presume that SPF2.0 records only contain incremental
features data? That way, the DNS output need not have redundant
information and thus not create a larger burden to DNS servers as even more
versions and features are added. As an example of what I mean - a
requesting party gets the SPF TXT records from DNS and it looks like this:
IN TXT "v=spf1 ip4:1.2.3.4 -all"
IN TXT "v=spf2.0/mfrom <whateverthepropersyntax> -all"
Rather than:
IN TXT "v=spf1 ip4:1.2.3.4 -all"
IN TXT "v=spf2.0/mfrom <whateverthepropersyntax> ip4:1.2.3.4 -all"
which repeats data, in this example for the ip4 information.
This sounds interesting I think, but you can only do this for the mfrom scope.
As soon as the scope is mfrom,helo for example, your spf1 semantics don't map
to your spf2.0 semantics anymore.
Now that we are seeing a growing number of variants for the record
structure (e.g., support for multiple implementation types, etc), would it
be prudent to consider implementing base functionality of spf1 for as
designed, in DNS responses (with future spf versions depending upon
something like an HTTP based XML or predefined text formatted response)?
Don't say xml on this list please, it will induce heart-problems with many
people here :)
What I mean by this is, after version 1 and perhaps 2.0, why not consider
looking at having future variants of SPF delivering data back via http
based services to reduce the DNS response time and load? That way, one's
imagination, rather than technology limits future SPF growth potential. It
seems to me that after a point, asking DNS to deliver too much data is
going to be a problem for some or all of today's DNS server implementations.
This has been discussed already for spf1, and was rejected because there is a
lot of overhead attached to making an http connection (setting up a tcp session
requires all these handshake packets, whereas a dns query is just a one-shot
udp exchange: one request, one reply packet). Perhaps we could think about some
kind of udp server that serves policy information, but this greatly complicates
the work to be done by spf publishers. The beauty at this point is that it's
relatively simple to publish spf records, which allows for rapid deployment (at
the sending side at least).
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/