On Mar 28, 2009, at 11:34 AM, Jim Fenton wrote: > Mark Delany wrote: >> >> IOW, what is the value-add in inventing yet another identity called >> DKIM.i= when we already have rfc2822.From, rfc2822.sender, >> rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom? >> >> Are you suggesting that DKIM.i= should have preference over signed >> RFC2822 identifiers? > > Not at all. Signing a particular header field doesn't have any > semantics for DKIM other than to make sure that it doesn't change > between the signer and verifier. In other words, signing the > rfc2822.Sender field doesn't change the meaning of the signature a > bit. It just makes sure that a man-in-the-middle hasn't changed that > header field, potentially in a deceptive way. > > The "signing identity", i=, is already in the DKIM specification and > isn't a new invention of ADSP. It doesn't take precedence over > signed RFC2822 identifiers, although there is a suggestion in > RFC4871 section 6.3: "If the message is signed on behalf of any > address other than that in the From: header field, the mail system > SHOULD take pains to ensure that the actual signing identity is > clear to the reader." I take this as a suggestion to display it in > addition to the 2822 From address.
Email-Address annotations should require the RFC5322 identity to explicitly matching against the i= value. In other words, with respect to message email-address annotation, the i= value determines which RFC5322 signed header field represents the on-behalf-of identifier that might be annotated and serve as an intra-domain reputation identifier. When the i= value does not match against against an RFC5322 identity, it represents just an intra-domain reputation identifier that should not be displayed because it is not defined as representing a real identifier. This identifier would only provide a means to mitigate intra-domain abuse. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
