Stephane Bortzmeyer [bortzmeyer(_at_)nic(_dot_)fr] wrote:
Julian Mehnle <bulk(_at_)mehnle(_dot_)net> wrote
But now we are editing the official SPFv1 specification, which is
not required to confine itself to simply document existing
implementations.
I do not agree. The good thing about SPF (specially when you compare
with Sender-ID, DomainKeys or IIM) is that it works today, it has
several interoperable implementations and it has been tested in the
wild.
If we move from that, we lose a lot and we are not sure we improve
anything.
One important point of SPF is to work _well_ (surprise!). We are probably
able to fix SPF's present flaws (e.g. that, in the absence of the zone cut
defaulting, an SPF record would have to be specified for every single
domain/host name), which bears real value. If we are careful, we can be
sure to only make changes that improve the situation.
I vote for a different method: create, as soon as possible, a RFC
describing the *current* SPF. After that, try to create a SPF 2 with
new bells and whistles. At the present time, many people regard SPF as
no more mature than Sender-ID since none of them has a RFC (or another
formal specification).
Not keeping 100% backwards compatibility does not imply delaying the
standardization process.
Of course, since there was no proper specification, we cannot expect
that every existing implementation will follow the RFC. But we can
move as close as possible. If we insist on the "zone cut" search, for
instance, 0 % of exiting implementations will be conformant...
I don't think that's a big problem. All the implementations aren't used
widely yet, and most of them are still under development, so new versions
would be released (and used) soon anyway.
Look, if the gain from zone cut defaulting wasn't as significant as it is,
I wouldn't bother arguing about it...
I vote for removing the new RR type (or to move it to a different
Internet-Draft) and to remove the very recent (and bad) idea of "tree
walking" with the "zone cut" algorithm. I actually vote for keeping
SPF as it is in the RFC and *then* to modify it.
What "tree walking"? Have I missed anything?
And what exactly would your reasons be for removing the new RR type from
the spec? It doesn't even make existing implementations incompliant.