On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote: > How about a new tag, "shf=" (special header fields). Ignored by legacy > verifiers, as required; otherwise, contains a colon-separated list of > fields that get special handling by verifiers. "Special handling" > depends on the header field and would need to be documented in each > case. For DKIM-Delegate, for example, it is always canonicalized in a > special way that would cause the signature never to validate for a > legacy verifier. > > Or maybe "shf=" header fields are only canonicalized by verifiers that > know that they're special and why; they're a separate list than "h=". > > Somewhat less bogus than a new canonicalization that imparts new > semantics; a new tag would, one would think, always impart new semantics > in the first place.
I do not understand this predilection for trying to change the DKIM base engine. It doesn't need it. I also don't understand the construct of 'special handling', nevermind not liking the idea of it, especially since it explicitly creates the complexity of "depends on the header field". What I was suggesting was merely registering a new canonicalization algorithm. Legacy DKIM implementations won't understand it. New ones (presumably also modified to know about DMARC) will. The new canonicalization should have actual differences from the current ones that are deemed worthy for general use. For example, how about 'very-relaxed' which is like relaxed but eliminates all WSP from the calculation rather than just compressing it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
