On Sat, Jun 14, 2014 at 8:57 PM, Dave Crocker <[email protected]> wrote:
> It's an interesting idea, but does seem like some sort of layer > violation. (i wanted some phrase other than 'kludgy' just so i didn't > echo john...) > > Surely there are enough details we could vary in a header > canonicalization that are legitimate so that we don't need to toss in > odd 'policy' characteristics to the of the algorithm? > Hmm. 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. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
