On Apr 3, 2009, at 2:21 AM, Eliot Lear wrote:
Second, either the d= matches the domain in the rfc5322.From field,
or it doesn't. There is no complexity or subtlety to the test, so
there are no "implications" that need to be pointed out.
This is unresponsive to Jim's point.
Agreed. The current ADSP Author Signature definition in Section 2.7:
,---
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.
'---
ADSP is not intended to be applied across sub-domains, so there is
little reason to accommodate parent domain signing. Requiring
publication of the DKIM public key _and_ ADSP record for each email-
address domain does not seem like an undue burden. There is nothing
wrong with Jim's request to add a note regarding the restriction, but
this restriction is not being changed. That portion of the Author
Domain Signature definition has not be discussed.
IMHO, the definition is being changed by striking the following in
Section 2.7:
,---
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=".
'---
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html