In <6503D26C-DB8E-404D-8D8F-5087F64A9119@xxxxxxxxxxxxxx> Douglas Otis <dotis@xxxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf