ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

2010-10-07 12:06:39

Michael Thomas wrote:
On 10/07/2010 03:40 AM, Charles Lindsey wrote:
On Wed, 06 Oct 2010 13:00:25 +0100, Steve 
Atkins<steve(_at_)wordtothewise(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>