In the IETF 74 DKIM meeting, we had a brief discussion about the current state of ADSP, given the recent discussions on i= (and other things). It seems to the chairs that ADSP isn't severely affected, and that changes would be needed only in section 2.7, "Author Signature", which is the only place that d= and i= are mentioned. Here's the current text (from -09), for reference:
> 2.7. Author Signature > > > An "author signature" is a Valid Signature that has the same domain > name in the DKIM signing identity as the domain name in the Author > Address. If the DKIM signing identity has a Local-part, it is be > identical to the Local-part in the Author Address. Following > [RFC5321], Local-part comparisons are case sensitive, but domain > comparisons are case insensitive. > > For example, if a message has a Valid Signature, with the DKIM- > Signature field containing "[email protected]", then domain.example > is asserting that it takes responsibility for the message. If the > message's From: field contains the address "[email protected]", that > would mean that the message does not have a valid Author Signature. > Even though the message is signed by the same domain, it will not > satisfy ADSP that specifies "dkim=all" or "dkim=discardable". > > 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=". The current proposal is to remove i= here, and rework the text so that ADSP uses d= only. We note the following: 1. If, after some implementation and operational experience, the group decides that i= does need to be there, it can be added back in as an extension. 2. Alternatively, if, after some implementation and operational experience, the group decides that the function needs to be there, it can be added as an extension, with a new tag (as with Jim's example of r=). 3. We don't have that operational experience at this point. The chairs recommend going ahead with this proposal. The chairs' recommendation aside, the decision is, as always, with the working group. Please begin discussing this, in this thread, forthwith, and desist next Friday, 3 April, at which point we'll evaluate the consensus and proceed with ADSP. <strike>Go wild.</strike> <strike>Knock yourselves out.</strike> Proceed with the discussion. Barry -- Barry Leiba, DKIM working group chair ([email protected]) http://internetmessagingtechnology.org/ _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
