[ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
MH Michael Hammer (5304)
MHammer at ag.com
Wed Oct 6 10:57:10 PDT 2010
Apologies all for top posting. Having to use a different client due to technical difficulties.
Murray, I'm violently agreeing with you that it is not strictly speaking a 4871 issue.
Having said that, I believe that it is an issue that begs the question... where should it land? You are correct that this is the difference between implementation and standards. Either way, we need to look at the outcomes of what we do.
I'm agreeing with you that IETF-DKIM may not be the place to address it...assuming there is a beleif that it is a problem at all. So the first question is whether this is a problem, if the consensus is that it isn't a problem, great...nothing more need be done.
If the consensus is that it is a problem but not really a 4871 problem then do we just walk away from it and leave it at that - "not our problem"? Should we perhaps look for the place where the 5322 people roost (I hear that working group shut down as part of IETF reorg) and at least say... "hey, this came up in the context of 4871 and we believe there may be some wider implications and it may be worth considering whether 5322 should be considered in light of this".
From: ietf-dkim-bounces at mipassoc.org on behalf of Murray S. Kucherawy
Sent: Wed 10/6/2010 8:13 AM
To: ietf-dkim at mipassoc.org
Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
> -----Original Message-----
> From: MH Michael Hammer (5304) [mailto:MHammer at ag.com]
> Sent: Wednesday, October 06, 2010 12:20 AM
> To: Murray S. Kucherawy; ietf-dkim at mipassoc.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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-dkim