Re: Unknown mechanisms
Frank Ellermann <[email protected]>
| Newsgroups | gmane.mail.spam.spf.discuss |
|---|---|
| Message-ID | <CAHhFybrunsDv9SCwSZXoVOgR=wrDvOXRU7yX_aM5PSs+uN2R5g@mail.gmail.com> |
On 3 September 2011 02:40, Murray S. Kucherawy wrote: Hi, > Yes, it's in the ABNF, and the definition of "permerror" > basically covers it. Is there harm in explicitly > connecting the two? Not directly, but I recall that we had *big* difficulties to limit the size (in pages) of this beast. Your proposal could result in new text like this: | Note that there are no "unknown mechanisms", because this | would | result in a syntax error while parsing a policy, | or, if it were explicitly allowed, in PERMERROR results | with older implementations, and in different results with | newer implementations either supporting or ignoring such | mechanisms. Therefore a new version different from v=spf1 | is REQUIRED for the introduction of new mechanisms. That would cover the issue completely, hopefully, but it is also one of those cases where not talking about it might be clearer for readers. [There is a complete draft explaining the similar issue of unknown modifiers with incompatible results depending on the implementation (support as new vs. ignore as unknown), originally intended as RFC 4408 section. And there were good reasons to never add it to RFC 4408: It is just not interesting as long as nobody invents new modifiers with this property -- Scott's MARF modifiers are not affected.] If you have a shorter/clearer idea to explain the issue of unknown mechanisms in prose, shoot. -Frank