Re: Re: draft-ietf-marid-protocol-03 - scope questions and comments

Koen,

I think that SPF publishers should probably keep multiple records for 
versions 1 and 2.0 for now.  But, your question raises several interesting 
points for me that perhaps others might address.  Please forgive me and 
accept my apologies in advance if these ideas seem naive or have been 
covered elsewhere.
Because a requesting party simply requests a TXT record against a zone for 
a domain, SPF publishers cannot determine what the inquirer is really 
looking for.  I have posed some questions below that might work to inspire 
thinking about how one might address or handle this as well as some other 
challenges I can envision SPF might face by its broader future acceptance 
and feature growth.
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.
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.
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.

Finally, should we examine an approach for more robust SPF implementations 
that takes a whole different direction to conserve DNS resources for really 
large data requirements the SPF standard may evolve to require?
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)?
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.
Thus far, I am aware of people proposing to place entire public keys and 
even more into DNS records.  While many of these ideas and approaches to 
security and extending the SPF standard have merit and may well be needed, 
I think that the underlying transport to deliver data should fit the nature 
of the data attempting to be delivered or one may end up developing 
structures that may slow things down and might cause harm.  I think that 
some call this problem, mission creep.  Perhaps SPF records might consider 
support for a pointing extension enhancement to SPF to reduce the problem 
of burden to DNS from expanded data requirements in this way:
IN TXT "spf1 ip4:1.2.3.4 - all"
IN TXT "spfx.x/need:some_need some_protocol=_spf.domain.tld/path/file.ext"

Where in the above, some_protocol might be an html server that can deliver 
via default port 80 whatever is needed in succeeding SPF versions via an 
http file.ext request from the URL supplied in the TXT record as defined by 
the then existing SPF protocol version standard.  Perhaps some_need in the 
example above could even be the version of spf where the http requested URL 
contains the entire SPF TXT content for that version.  By example:
IN TXT "spfx.x/need:spfx.x http=_spf.domain.tld/path/spf2.0.txt"

Keep in mind that the above is still dependant on the security of DNS as 
the gating factor.  This was the case in spf1, but I don't think that 
implementing the above causes as significant additional load for DNS as 
SPF's need to transmit larger volumes of data matures and expands.  With 
the above, DNS serves only to direct a requesting party to a resource for a 
longer answer, very much what I think DNS was designed to do well.  By 
this, I mean, a DNS server is typically asked via its RRs to answer 
questions like where to I want to go today for something (e.g., where do I 
go to deliver email?, where do I go to get a web page?, etc).  I think that 
using DNS to ask where do I go to get more complex SPF information is not 
entirely inappropriate for consideration.
Perhaps, what was originally simple, now becomes more complex by necessity 
to meet new challenges, but the underlying delivery mechanism really was 
really best suited to cover the original simple case and not those cases of 
the new challenges that conditions demand solutions address.  I think that 
RR records have been traditionally short, because they ideally needed to 
fit into a single UDP packet to be most easily sent about the 
Internet.  Simple spf1 implementations let this happen, but as things get 
more complex and data transmission needs increase, HTTP protocol arguably 
delivers large volumes of data in a well accepted and adopted protocol 
designed to reliably meet those kinds of needs.
At least one somebody once said that no computer would ever need more than 
640Kb of RAM and it became so for a while (of course, the somebody I am 
thinking of also made up for that faux pau in a variety of ways since, so 
one should probably forgive him that one).  Planning ahead for a possible 
expanded need within SPF that is larger than any anticipated need cannot be 
a very bad thing, especially as we witness SPFs original needs and scope 
already expanding rather quickly within only just over a year since its 
original conception.
As people develop and contribute to the SPF standard, perhaps this too 
needs consideration in the design thinking.  I suggest the above in the 
spirit of "do no harm by your actions" thinking, rather than to add 
complexity for no good reason.  If I am wrong, again, I apologize to list 
members, but hopefully some of this is useful for productive discussion.
Again, please forgive me if some of this is already covered somewhere in 
the specification.  I simply don't remember seeing these issues directly 
addressed.  Perhaps SPF.POBOX.COM could offer a best practices section for 
SPF development and adopters to cover implementation questions like these.
Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/


At 12:06 PM 9/26/2004, you wrote:
> > Koen Martens wrote:
> >
> > > If we're calling the RR 'SPF' we might even want to keep the
> > > version in there, giving "v=spf1 ip4:1.2.3.4 -all",
> >
> > > basically: the same as we have now but then in SPF RR instead
> > > of TXT.. Does this make any sense?
> >
> > Yes, IIRC Mark said essentially the same on the former MARID
> > list, less confusion if the legacy TXT format and the SPF RR
> > use exactly the same format for exactly the same domain.
> >
> > It would be spf2.0/mfrom or similar scopes instead of v=spf1,
> > or did you intentionally use "v=spf1" (and if so, why ;-) ?
>
> Yes, it should be spf2.0/mfrom. But how the heck are we going to do the 
> transition? Should we all publish v=spf1 and v=spf2.0/* at the same time 
> for a while??
> 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/