> I'm scratching my head to see if there is any advice we can offer to make > signing and verification more robust while not changing the behavior of > existing code for normal (for some definition of normal messages). > > A) You have to sign either all occurences of a header or none of them, and > a message with some but not all occurences signed fails verification. This > is probably too strong, although I doubt that there are many places in > practice where it would matter. > > B) Same as A, but limited to an enumerated set of headers that are > supposed to occur only once. > > c) Same as B, but tell signers to use the h= trick to make verification > fail if extra headers show up.
Realistically useful advice probably has to influence rendering of messages. That might mean MUA participation or it might mean mailstore participation that removes all (typically) rendered headers that are unsigned. That raise a pre-cursor question as to whether DKIM is intended to offer rendered-to-user value? If not, then this whole discussion is moot. If so, then that implies greater participation from the rendering process. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
