On 6/30/11 9:53 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Charles Lindsey >> Sent: Thursday, June 30, 2011 7:05 AM >> To: DKIM >> Subject: Re: [ietf-dkim] Pete's review of 4871bis >> >> The problem is that an apparently valid signature (albeit atching the >> wrong From) is likely to give a false impression of validity somewhere >> along the line unless modules down the line are watchig for this case (and >> for sure MUAs will not be watching for it for a long time, so it is the >> ISPs/boundary agents that need to do it). > If the advent of DKIM means that numerous modules implementing other > specifications loosely suddenly have to pay a price for doing so, then that's > the reality, and I still don't see how that's a problem DKIM needs to fix. > Sure, we need to document the nuances DKIM introduces, but it's still not an > attack against DKIM, so this remains the wrong place to deal with it in a > normative sense. > > If you prefer the loose application of other standards, don't use DKIM (and > lose out on its benefits). Murray,
DKIM is not enforcing RFC5322's format. Nor is it reasonable to expect that SMTP has either. It is reasonable to expect security related protocols validate input. Whether a message gets rejected or dropped is immaterial. For DKIM's output to be usable, it must be clear what was signed without expecting subsequent message handlers to adopt bottom-up selection. Otherwise, DKIM can not be safely deployed in an incremental fashion as claimed in its introduction. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
