> On August 17, 2005 at 08:26, Michael Thomas wrote: > > > PS: as I said, take a look at l= and z= and their implications > > for mailing lists. > > l= is a massive security problem. If you are relying on it, then > you are relying on a exploitable aspect of DKIM. How verifiers > deal with l= either needs to be revised or this tag needs to > be dropped. > > As for z=, the draft states that z= data should not be part > of validation.
I don't think it works to let a signer make assertions about what kinds of transformations a message might or might not undergo after the message is signed. On the other hand, if a signer wants to put redundant information in a message as a means of recovering from subsequent ... "transmission errors", and a verifier wants to make use of that redundant information to recover the original message and verify that it was recovered intact, I don't see anything wrong with that - provided that the verifier only uses that signature to establish trust in the original message, and not in the modified message. So for instance a verifying MUA that displays an indication that a message was signed should display the original message, rather than the modified message. If it provides an option to display the modified message, it should make it clear that the message was modified in transit after being signed. (I can imagine an MUA showing diffs between versions with strikethroughs, underlines, and change bars, but I doubt most recipients would bother with such.) Seen from that perspective, a filtering verifier might reasonably pass a signed message if the original content could still be recovered and verified by the filter, and presumably, by any subsequent verifier and the recipient's MUA. Keith _______________________________________________ ietf-dkim mailing list http://dkim.org
