On Wed, 2007-01-10 at 22:52 -0500, Scott Kitterman wrote: > [Must sign the From header.] > > This has nothing to do with the originator address and everything to > do with signing the required elements of the message. > > Taken to an extreme, there are reasons why any part of the message > might get changed and so we ought not sign anything.
Robust signatures are needed to abate criminal spoofing of originators and to be utilized for ensuring abuse feedback and DSNs. The agent transmitting the message might not be represented by From header. In the case of a mailing list, the Sender header is likely associated with the signing domain. A mailing list signing the From header reduces robustness of the signature for little benefit. The signature should clarify which identity the message is being signed on behalf of, as this likely represents who is being trusted. When the signature is permitted to carry the "Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed" _without restriction_, there would be far less reason to sign associated headers. A valid signature is never apparent to the recipient without annotation. Annotate headers containing "trusted" identities associated with valid signatures. Even when this header is signed, the Display-Name will not have been verified as being associated with the signing-domain. As such, the recipient should place little trust in the Display-Name. The Identity could be in the form of <[EMAIL PROTECTED] <[EMAIL PROTECTED]>>. ASCII and UTF-8 domains may not be equivalent or match that of the signing domain. With a method to confirm that either the UTF-8 or the ASCII domain is associated with the signing-domain (even when they differ), then all is well without the header having been signed. There would be little point in annotating associated identities without the identity being trusted or digitally recognized. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
