Yes, it ties an identifier to a bag of bits, and yes it specifies what
those bits are, but it really does deal only with those bits and not
(necessarily) the entire message.
Technically. you are correct. Semantically, that's silly.
We went through backflips trying to figure out how to design the
signatures so that the message modifications they allowed would preserve
the same message, for an ill defined but I think well understood version
of the same. While it's always been possible to sign messages in ways
that allow gross changes, e.g. don't sign the subject or MIME headers, set
l=0, if you sign a message using a normal set of options, the idea was
always that the message the recipient saw would be the one you signed.
Throwing up our hands at the double header trick is, one might say,
ahistoric. Claiming it's an MUA problem is simply wrong.
For the umpteenth time, we don't need to change the bits on the wire for a
valid signed RFC 5322 message. But we really need to give some advice
about how to defend against it. Jim's proposed language with SHOULD seems
right to me.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html