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 "i=a(_at_)domain(_dot_)example", then
domain.example
is asserting that it takes responsibility for the message. If the
message's From: field contains the address "b(_at_)domain(_dot_)example",
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 (barryleiba(_at_)computer(_dot_)org)
http://internetmessagingtechnology.org/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html