On 4/25/11 9:29 PM, Dave CROCKER wrote:
On 4/25/2011 9:18 PM, Murray S. Kucherawy wrote:
Double listing in the "h=" tag can not fully mitigate risks
related to appended header fields when messages are signed by a
different domain than the domain found in the appended From
header field.
DKIM doesn't create any binding between the RFC5322.From domain and
the "d=" value as you're doing. What you're talking about here
falls into the realm of ADSP or other policy-like assertions, not
DKIM itself which is the topic of this draft.
Perhaps I am wrong, but I believe that this point has been made and
re-made enough times to warrant not making it again.
If someone participating in this working group continues to make that
error, they are unlikely to change. And the mailing list archive has
more than enough evidence of clarifying this point; more is not
needed.
Dave,
Forgive me, but IMHO you are wrong. The issue is _not_ about whether
the From and the DKIM-Signature header fields have been bound by the
application of policies specified elsewhere and not within the base
specification.
With the multiple From header field defect being ignored in the base
specification, malefactors are able to leverage the omitted check to
obtain unintended acceptance which may injure uninvolved third-party
domains and their recipients. Even domains that may make extraordinary
efforts at establishing restrictive acceptance policies.
Before DKIM is able to offer a trust basis for acceptance, it is
important that DKIM ensures what has been signed and trusted is not
easily confused by trivial acts of pre-pending deceptive From header
fields. When larger domains fail to include the double listing in the
"h=" tag because size alone ensures acceptance, all other domains are
put at risk.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html