In <62812b24e0ea460a176bd65c13a8001d(_at_)cs(_dot_)utk(_dot_)edu> Keith Moore
While I'm very interested in learning about things that SPF
implementations usually do that aren't (adequately) document, or
things that are documented that most SPF implementations don't do,
there are still a few things that are being changed around the edges.
Basically, the more incompatible the suggested change, the more
evidence will be required that it is a *really* important and
If I may make a suggestion -
I have generally found that when documenting an existing protocol it's
important to pick one of two goais:
1) document the protocol as it is used in practice, or as it was used
as of a particular date
2) document how the protocol SHOULD work
I am really trying to aim toward your first goal.
SPF, as a protocol, isn't so entrenched that nothing can really be
changed, but it is far too deployed to make any significant changes.
As an example of things that have changed in this round of SPF
spec-writing is the definition of the Received-SPF: header. It had
numerous things that did not conform to what RFC2822 said that headers
should look like. With a few, somewhat rare exceptions, the actual
SPF implementations produce headers that can be defined with
RFC2822-compatible ABNF, so I have updated the ABNF in the SPF spec to
match both existing practices, and RFC2822.
The Received-SPF header isn't a critical part of the SPF specification
anyway, so I think that compatiblity with RFC2822 is a bigger gain
than the slight breakage that changing the ABNF causes.
There are other changes like going from "MAY" to "SHOULD", or vice
so if you're going to document how the protocol is/was used in
practice, resist the temptation to define new features.
Actually, new features are nowhere on the list of things I'm trying to
do. Just the opposite. I have identified quite a few features in
older versions of the specs that have never been implemented by
anyone, and I have removed them. The -01 version, which should be
release Real Soon Now, will remove another of these features.
As a side benefit of removing the unused features, I have been able to
keep the number of pages used to describe the spec constant for quite
a while now. There are always things you could add to try and make
things clearer, or more fully explain some detail, *BUT* ever time I
do, I try very hard to find something else in the spec that isn't as
important and delete it.
another nice thing about documenting how the protocol is/was used is
that you can avoid a lot of controversy on whether or not the protocol
is a good idea.
Yes, very much agreed. During 2003, the SPF spec was hotly debated
and a pretty good spec was written up, things were pretty much
finalized, quite afew implementations were written and a ton of SPF
records were published. Then came the IETF MARID WG, and everyone
thought it would be A-OK to change the heck out of the semantics and
there was a repeat of all the debates from 2003 about how things work
and which were the right choices.
Basically everything from that MARID working group is being thrown
out, except for the much needed wordsmithing on the spec.
the only controversies
should be about whether you're documenting the protocol accurately,
and perhaps about whether you're doing due diligence in pointing out
any hazards (e.g. security or operational considerations) associated
with the legacy protocol.
This is my goal, and I would greatly appreciate comments about what
things still need to be done better.
think that there's a limit to how effective any proposal in this space
can be, and it's probably not worth the trouble to try to make SPF be
the ultimate email authentication scheme. and I'd say the same thing
about the other authentication proposals I've seen)
SPF was never designed to be the Final and Ultimate Solution to the
Spam Problem. Many people in the SPF community also support other
authentication proposals as complimentary. I think that if a clean,
easy solution to the email authentication problem existed, it would
have been thought of long ago.