Mark Delany wrote: >>>> Note: ADSP is incompatible with valid DKIM usage in which a signer >>>> uses "i=" with values that are not the same as addresses in mail >>>> headers. In that case, a possible workaround could be to add a >>>> second DKIM signature a "d=" value that matches the Author >>>> Address, but no "i=". >>>> >> >> I'll start by proposing text that we could use if we adopted an >> alternate definition of Author Signature based on the d= value only. >> Then I'll describe what I think we'll lose by going to that definition. > > Given that i= is an arbitrary value assigned by the signer, the > question to me is what value does it add beyond what signed RFC2822 > headers can do just as well. Eg, why not set an rfc2822.Sender Field > and sign that rather than invent i=? > > 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. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
