Ok, first off, I would like to apologize for not getting this out
sooner. I'd offer an excuse, but it really wouldn't make any
difference... *sigh*
Secondly, I would like to apologize for this long email. I think it
is very important, so please read it all very carefully.
I would like to make a goal of finishing up the SPF-classic spec. I
think we are very close.
The most significant change in this version is the removal of zone
cuts. I've long said that they were the feature I could easiest see
removed, and I guess it is the feature I could see coming back the
easiest. For me, the biggest factor is that zone cuts simply are not
implemented by very many systems.
I intended to make only one more revision to this document before I
submit it to the IETF. I will then ask for a last review by the
various IETF working groups (DNS-ext, SMTP, and 822) and here on
spf-discuss. Unless there are major problems that haven't been caught
in the previous reviews, I will then ask the IETF to advance this SPF
specification as a Proposed Standard. (I do not think it is
appropriate for this to be an Experimental RFC since the experimental
nature of SPF ended in Dec 2003.)
*** THIS IS YOUR LAST CHANCE TO POLISH UP THE SPF SPEC. ***
That last revision will likely be made sometime next week before next
Thursday's SPF council meeting. If you disagree with any of my
decisions, please write up a message that concisely explains what you
want to see done (include a patch!), and why it must be done. Post it
to the spf-discuss mailing list with a subject line that included "For
SPF council review:". I will make sure these items will get on the
agenda and are voted up or down.
The drafts are in a slightly different place now. See:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre4.html
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre4.txt
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre4.xml
A diff and a wdiff between this version and the previous version can
be found at:
http://www.schlitt.net/spf/spf_classic/changes_from_draft-schlitt-spf-classic-00.xml.diff.txt
http://www.schlitt.net/spf/spf_classic/changes_from_draft-schlitt-spf-classic-00.xml.wdiff.txt
Based on several reviewer's comments (Julian, Frank, and indirectly,
Andy), the most controversial item left appears to be what to do when
a non-existent domain is encountered. Part of the problem is that
this subject has been controversial for a very long time and various
previous SPF specifications have said to do different things.
Moreover, different SPF implementations have done different things and
different versions of the same SPF implementation have done different
things.
Currently, in spf-classic-01pre4, non-existent and malformed domains
used to fetch SPF records are specified cause a result of "none"
(Sections 4.3), except in the case of the include: mechanism, in which
case it specified to cause a result of PermError (Section 5.2).
In draft-mengwong-spf-01, a domain that does not exist must return
"unknown" (now called PermError) in section 2.2.2, and for the
include:, it also says to return "unknown".
In draft-mengwong-spf-00, a domain that does not exist can return
either "none" or "fail" (section 2.2.2), and for the include:, it must
return "unknown" (now called PermError) in section 4.2.
I think that the current spf-classic-01pre4 makes the best choice of
the available, incompatible and inconsistent, options. While this is
one area that I'm most open to changes, I think it is important not to
just give an off-the-top-of-my-head answer. Please investigate
previous discussions on this subject, previous SPF specs, and
available SPF implementations.
With the last set of changes, the draft was pushed up one page to 49
pages. This is way too long, RFC2822 is only 51 pages. I have
started rejecting suggested changes simply because people did not also
suggest enough other, less important things, to remove from the draft.
The major differences between this schlitt-spf-classic-00 spec and
schlitt-spf-classic-01pre4 spec are:
* The zone cut specification, as described in
draft-mengwong-spf-01.txt, has been removed. This part of the SPF
is not widely implemented, it was one of the most recent additions
to the SPF spec, and it raised strong objections in the IETF DNS-ext
working group. I have long said that this was the thing I would be
most willing to remove, and I guess I would still be willing to
bring it back if someone can give convincing reasons why it is
required.
* Most of the changes have been editorial in nature, rather than any
changes to the actual semantics of the protocol. This wordsmithing
includes not just spelling and grammatical fixes, but also
clarifications about the intent and meaning of various parts of the
spec.
* Sections have been re-ordered in so that they conform to the
instructions2authors.txt document. All required sections and
arrangements are included, and only the "Security Considerations"
section is not in the suggested order. Since the Security
Considerations is such an important part of the spec, it has been
moved before the Acknowledgement section.
This makes the diffs much larger than the actual changes content
would create.
* It is now RECOMMENDED that SPF clients check the HELO identity,
instead of just saying that they MAY.
* The "Processing Limits" has been merged into the "Security
Considerations" section, eliminating duplicate information.
* The "Security Considerations" section has been reorganized and broken
up into subsections.
* A "Privacy Exposure" subsection to the "Security Considerations"
section has been added.
* An IANA section on the Received-SPF header has been added. (Thanks
Frank!)
-wayne