In <6503D26C-DB8E-404D-8D8F-5087F64A9119(_at_)mail-abuse(_dot_)org> Douglas
Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )
RFC2026 says:
4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level. [...]
This wouldn't apply because there are no newer specifications for SPF,
nor is it obsolete.
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]
There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.
There have been *very* few semantic changes that were introduced in
the current spf-classic I-D. Almost everything was either part of one
of the earlier, pre-MARID specs, or part of one of the earlier,
pre-MARID implementations.
Of hand, I can think of only the following three "new" items in the
spf-classic I-D:
1) The introduction of a new DNS RR type. Personally, I would be
happy to get rid of this, but there are a lot of folks, especially
in the IETF who think this is very important.
2) The SPF result code "unknown" was renamed "PermError" and the
result code "Error" was renamed "TempError". This is truely a
holdover from MARID. I think the names are much better, but yeah,
it is a change.
3) The result of a redirect modifier that has, as its target, a domain
name that has no SPF records has been changed from returning a
result code of "None" to "PermError". Actually, I'm not certain
what the result code in the earlier draft should be because it was
a corner case that was not addressed.
There were quite a few places where we either removed things like
Receiver Policy, or changed things from "MUST" to either "SHOULD" or
"MAY". We did this when we found that existing implemenations did not
obey the "MUST" and in practice, a "SHOULD" or "MAY" would be more
productive as the standard.
In some cases we also had to tighten the requirements in order to make
things more portable. For example, there were a couple of SPF
implementations (pre-MARID) that enforced processing limits needed to
prevent SPF from being used as an (effective) DoS vector. Since these
implementations were deployed, domain owners need to make sure their
records conform to these limits in order to make sure their records
would be processed correctly everywhere.
Finally, we found some cases where features were simply not used in
practice. For example, the ABNF for the Received-SPF: header in the
older specs could allow for the creation of headers that did not
conform to what RFC2822 wants. In practice, the Received-SPF: headers
generated by actual implementations conformed to RFC2822, and so the
ABNF could be tightened up.
It took a great deal of work to find as many SPF implementations as we
could, figure out how the actually worked, find as many SPF records as
we could, figure out which features are used, and to resolve as many
conflicts as we could in the best, most coherent, way we could.
While I'm sure that the SPF-classic I-D can be improved, I think it
has done a good job of meeting the goal of documenting SPF, as it
existed pre-MARID.
-wayne
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf