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
[buy-v1(_at_)gra-at-www(_dot_)p1llz(_dot_)com](_dot_)
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