> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman
> While there is certainly nothing an RFC can do to prevent > receivers from attempting to do the kind of message reverse > engineering being discussed, the current MUST NOT wording > makes it clear that the results of that processing are not > part of the protocol. Receivers can guess all they want, but > don't call the result of that effort a DKIM result. If you want to state that something is not part of the protocol you should use SHOULD. The rules are very clear, MUST can only be used in cases when breaking the rule will inevitably produce incompatibility. Speculation that breaking the rule might produce incompatibility is not enough. RFC 2119 is very clear. We can debate whether this behavior is a good idea or not. What we can't do is to state that we are using the definitions of MUST and SHOULD from 2119 and then use our own private definitions because we think we know better. Incidentally does RFC 2119 make Scott the most cited author in the field? I suspect so since it is cited in practically every OASIS and W3C standard as well. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
