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
