spf-discuss
[Top] [All Lists]

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

2004-09-28 14:29:21
Koen,

At 02:33 AM 9/28/2004, you wrote:
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,
.. snip ..
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').

Agree. Wildcards require more planning and work to implement. I am guessing that some different DNS server implementations might address wildcards differently or perhaps not support them at all.

> 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
..snip..
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...

Agree. Which is why establishing a good answer to your original question seems rather important.

> 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
..snip..
>
> 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.

Still, if the group considers the way versions are to roll, forward compatible semantic design might become more of a consideration. I am still not clear as to the best way to implement in an spf1 / spf2.0 world... even less so as spfx.x versions come down the road. My concern stems from avoiding being painted into a corner because of implementation choices.

> 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 :)
.. snip ..
Funny.

> 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).

I certainly agree that DNS was and is entirely the right choice for delivering spf1 data.

In my original message, I had hoped to show by example that spf1 should continue to be served in normal DNS UDP packets as always. My thought was that as the complexity of future versions necessitated, having possible alternate paths to data via a provision for pointers in the syntax might make sense to allow for getting data from other sources when it would be too much to expect DNS to deliver such a volume of data. Basically allowing the flexibility to extend via alternate paths if needed. A side benefit to doing this might also be to allow TXT records to migrate users into a formal SPF service down the road. e.g.,

IN TXT "spf1 ip4:1.2.3.4 - all"
IN TXT "spfx.x/need:service spf=1.2.3.123:nnn"

Perhaps this might be a transitional stepping stone to a more formal SPF service specification down the road when it gets its own RR.

This all still gets back to your excellent original question about how one should implement the next version(s)... Should it be concurrent, incremental or something else? As we understand, overburdening DNS with large UDP or many UDP packets is going to cause its own problems (e.g., fallback to TCP, etc). Deciding how future versions are to be implemented for existing and possible future environments seems an important issue to get resolved (or at least clear) and something I hope will be discussed further by others on this list.

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/

Best,

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