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