On Jan 6, 2009, at 6:06 PM, MH Michael Hammer (5304) wrote:
I'll stick t o inline comments at the risk of this getting confusing.
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Suppose that ietf.org asserts an ADSP record but doesn't require
signatures on incoming messages, even from its own domain (there's
no requirement that they do). Someone spoofs a message from
chair(_at_)ietf(_dot_)org, which is of course unsigned. The message coming
out of the list looks like it has an author signature. I have a
problem with that.
An ADSP signature represents the Domain of the Author, and not that of
If ietf.org is willing to put it's signature on the spoof message I
would assert that it has a DKIM problem more than an ADSP problem.
Since the From is always included within a DKIM signature, when just
d= compliance is required, it remains a matter of signing policy as to
which message is signed by the domain. If they have asserted that all
of their email is signed, then proper list operation should not
require a signature unable to indicate for which entity the message
had been signed. The signature should not be forced to affirm a From
email-address, as might be the case with mailing lists. The more
fundamental aspect as to how an acceptable ADSP signature is defined,
and whether it changes the RFC4781's definition for the i= parameter.
Either the message has a valid signature or it does not. If there is
a valid signature then ietf.org is claiming responsibility. If it
doesn't have a valid signature....then not so much. If ietf.org is
sending out spoofed messages spoofing a "from" then it has a problem
regardless of whether it DKIM signs, uses ADSP or does anything else..
This of course would only be a problem when the domain used within the
mailing list corresponds to the same domain as used by a mailing
list. When the i= does not match with that of the From, it should be
obvious the signature is not indicating prior authentication of the
The d=/i= distinction was originally created to simplify key
management by domains having many subdomains, in that they could
publish the keys in a parent domain (d=) while signing for a
subdomain (i=). You're basically suggesting that we abandon that
optimization so that we can use the d= domain rather than the i=
domain for ADSP.
I'm too tired to wade back through the list to find the discussion
that included statements from receivers that for the most part the
finer granularity desired by some senders was not necessarily useful
from the receiver perspective. I'm not going to argue with
receivers. I sign email with DKIM because it helps them identify
legitimate mail from our domains vs the spoofed mail. For my use
case I try to keep it as simple as possible.
I do not agree that by not restricting the use of the i= parameter,
beyond what is already required by RFC4871 when assessing ADSP
compliance, abandons any optimization. The i= parameter will still
allow the signature to communicate for which entity was the signature
added. In the normal range of email, there will be cases where a
message is not introduced by one of the entities found within the From
header field. Basing compliance upon the d= parameters matching still
allows the domain to determine what email they are willing to sign,
and importantly, indicate on whose behalf the signature was applied.
(The original definition of the i= parameter.) I tend to agree with
Michael more than Jim on this topic.
NOTE WELL: This list operates according to