On 7/7/11 3:21 PM, John Levine wrote: >> Will your "assume one more From than listed in h=" lead to failed >> verifications on messages that actually follow the advice in the RFC >> to list duplicate headers in their h= values? > The RFC also says you shouldn't sign messages that aren't RFC 2822. So > pick your poison. > > I have to say it's a little surreal to have these arguments about what > changes to make to avoid the horrors of a duplicate From: attack that > is and likely will always be entirely hypothetical, when we can't even > get our act together to deprecate the l= option, including l=0. John,
When a domain is found using the l=0 option, this provides a basis to assign the domain with no positive reputation. In other words, this domain's signature can not be a basis for acceptance hence reputation is able to cure this ill. The specification of SHOULD ensure messages are RFC5322 valid must not imply there are also valid reasons where these messages need not comply with checks for multiple header fields limited to single occurrences. There is no reason to have these checks be an optional configuration as they are in OpenDKIM. In light of conversations by influential individuals that DKIM verifier's role is NOT to make these checks, it therefore becomes essential to clarify the specifics of this particular requirement as a MUST. Skipping these checks invites harm. In addition, these checks have not been defined as the duty of SMTP. Also, the DKIM verifier making this check will not assure RFC5322 compliance, since not reporting a valid signature is to be considered not being signed. The difference is that acceptance based upon trust given a signing domain is not easily exploited when these checks are made by the DKIM verifier. Unfortunately, the norm is not to make these checks because only DKIM invites the possible exploit. DKIM MUST accept the role of preventing the exploit it invites. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html