> Verifiers MUST NOT use the header field names or copied values > for checking the signature in any way. Copied header field > values are for diagnostic use only. > >But of course that restriction could be relaxed.
My recollection is the point of that restriction is that a verifier has to use the actual values of the headers in the message, not the copied versions in the z= header. There had been some suggestions that if a header were "close enough" to the copied version, the verifier might substitute in the copied version. As always, this was part of the mailing list argument, with the idea to have signatures tolerate subject munging that lists like this one do. We decided against it both because nobody proposed a concrete version of close enough, and because nobody could say how a verifier would distinguish algorithmically between an inserted [ietf-dkim] and an inserted [EMAIL PROTECTED] A perfectly legitimate diagnostic use on a failed signature is to detect what header(s) don't match the copies, and whether the signature would have verified had the current versions matched the copied versions. But I don't know what you'd do operationally once you figured that out, and I don't recall any other suggestions that didn't involve considerable hand waving. > That said, this representation is more compact, so it's a tradeoff. You're right, but in an era when one line messages routinely contain 20K of HTML style goop, compact headers are the least of our worries. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
