On Tue, Jan 11, 2005 at 08:05:18PM +0100,
Julian Mehnle <bulk(_at_)mehnle(_dot_)net> wrote
a message of 44 lines which said:
Before Wayne was declared the official editor of the official SPFv1
spec, the spec he worked on may indeed have been supposed to
document current implementations.
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. 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).
And although I sure would like to maintain as far as possible a
backwards compatibility to existing implementations, there might
very well be some details that cannot sensibly remain 100% identical
to current practice.
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 think keeping the new SPF RR type in the SPFv1 spec is sensible.
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.