Michael Thomas wrote: > On 10/07/2010 03:40 AM, Charles Lindsey wrote: >> On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkins<st...@wordtothewise.com> >> wrote: >> >>> On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: >>>> Right. We could attempt to enumerate the 1,000 edge-cases we know >>>> today and then re-bis 4871 for the additional 1,000 edge-cases we >>>> learn tomorrow, or we could simply say that invalid 2822 messages >>>> MUST never verify and call it a day. >>> To comply with that MUST every DKIM verifier would have to >>> include a full 5322 verifier. That's a fairly high bar. >> No, that is not true, as I have demonstrated in the text I have proposed. >> >> You only need to look at whatever headers are actually mentioned in the >> "h=" tag of the signature, and you only need to verify those properties of >> those headers that could lead to trouble, and that would seem to be a >> simple count of the number of occurrences of those headers. > > 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'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.
This is a half full, half empty issue. Lets look at the positive side. DKIM by its very nature has already raised the bar of legacy mail by adding a new level of considerations that mandates certain parts, especially the 5322.From (since its the only requirement for hashing), be valid. We never (afaik) had any technology that does this at the MTA level. DKIM serves that purpose, thus the beauty of it. Before DKIM, RFC5322 has this major problem today. DKIM can leverage this RFC5322 vulnerability by helping address attention to it and close the loophole. It does raise the bar for "wannabe" DKIM compliant systems to do more than what is normally done. A implicit presumption that mail is RFC5322 compliant is not a safe presumption. The beauty of DKIM is that it moves us away from the legacy system exploits - by raising the "email compliancy" bar. In that vain this multiple 5322.From issue is directly related to a DKIM purpose to secure it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
