On 10/07/2010 11:01 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Michael Thomas >> Sent: Thursday, October 07, 2010 9:09 AM >> To: Charles Lindsey >> Cc: DKIM >> Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE >> >> I'm with Steve on this one. Forcing implementations of DKIM to >> determine whether a message is compliant is a pretty high bar. I >> for one wouldn't be in any particular big hurry to add a batch of >> code to insure that that MUST was fulfilled. I doubt anyone else >> would be either. The net effect of this MUST would be to make a >> lot of compliant DKIM implementations non-compliant. And for what? > > I disagree that it's all that tough. Any DKIM implementation already has to > have some code to isolate particular header fields so that they can be > replayed in the order "h=" states, for example. Code to verify there's only > one From: (plus the rest of the min/max counts that RFC5322 defines) in that > set can't be that expensive. Granted that only covers the chart in section > 3.6 of RFC5322, but it would completely handle this problem vector. > > And there are plenty of open source MTA implementations, the union of which > contains a variety of validity checking code that can be used to come up with > a valid solution to satisfying the entire RFC.
The larger issue here is would anybody rush out to close this MUST. I think that it is highly unlikely that anybody is going to care at this point. That goes for *any* new MUST, IMO: unless it's really a serious protocol endangering problem, it shouldn't be in the -bis document. Save new MUST's for genuine emergencies. >> I'd say that it would be better to just say that if you sign a >> non-compliant 5322 message that its verification is undefined, >> and move on. That at least matches reality, and hasn't hurt >> anything that I'm aware of. > > Generally I agree, but does saying "verification is undefined" satisfy those > concerned that this is a security vulnerability? The example of double-From: > shows verification succeeds. It's the interpretation of those results that > is the problem. These are two separate questions, I think. I'm only commenting on whether DKIM should be the SMTP police. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
