ietf-dkim
[Top] [All Lists]

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

2010-10-06 07:16:04
-----Original Message-----
From: MH Michael Hammer (5304) [mailto:MHammer(_at_)ag(_dot_)com]
Sent: Wednesday, October 06, 2010 12:20 AM
To: Murray S. Kucherawy; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

So, my belief is that this is really more of a 5322 issue than a 4871
issue. Having said that, I'm not comfortable kicking the can down the
road given that what we know, this potentially leads to abuse.

I don't think that's a fair characterization.  It is simply wrong to try to 
deal this problem in DKIM.  For example, a bug in the TCP stack that causes 
malformed data to arrive in an application which in turn causes something 
visible and unexpected, possibly even something dangerous, to happen in that 
application is still a bug in the TCP stack and saying so puts the 
responsibility for resolving the problem where it belongs.

There's also a practical difference between software engineering and 
specification.  You'd be justified in deciding to make your MUA code resilient 
to this problem, but it's wrong for doing so to be mandated by a standards 
document that has nothing to do with defining the proper format of email.

I believe this is a good example of a layering violation.

If the message is malformed and nonconforming then would it be
appropriate to treat the malformed message as no signature? This would
be one approach that appears consistent with 4871 yet this grinds on me
because it means we are saying that a malformed message with a
signature is the same as a conforming signature with no signature.

I understand that concern, but it sounds a lot to me like trying to ascribe a 
different value to the former case than the latter when we don't know that they 
deserve different handling.  (And that sounds a lot like the unresolved ADSP 
rathole.)

To me, there's a clear boundary between what DKIM defines and what RFC5322 
defines.  This problem isn't on our side of that line.  The RFC5322 part of the 
code in a verifier should detect and report that the message is malformed, and 
the DKIM part shouldn't even be invoked.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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