-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Thursday, October 07, 2010 3:29 AM
To: DKIM
Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple
5322.From
If we can't rely on people to provide valid input when admonished to do
so, then there's no point in continuing any of this work.
Well it is a plain fact that lots of mail non conforming to RFC 5322 is
floating around, and nearly all MUAs are accepting it on the grounds of
"being liberal in what they accept". So it is clear that we cannot "rely
on people" as you suggest. And for sure you cannot expect phishers to heed
any admonishments whatsoever.
And yet we must develop systems that are secure in spite of all that.
Any implementer must understand that "be liberal in what you accept" is not
carte blanche to weaken parsing strictness in arbitrary ways just to make
things easier on the user (or to satisfy a laziness quota). Every such choice
introduces risk.
There's a difference between a what specification can mandate in order for an
implementation to be compliant with it, and what people actually do. We can
say MUST until we're blue in the face but there's no way to compel implementers
to stick to every aspect of a specification other than to expose them to the
risks of not doing so. They simply lose the badge of saying they're compliant.
As you say, a lot of people are probably okay with that until it stings them
somehow.
This has been a vector for spoofing users via MUAs for a long time because a
message with two From: fields may still render the "wrong" one when, say, a
greylist or spam filter has acted on the "right" one (whatever those terms
might mean). This was true even before DomainKeys or SPF happened along, so
it's not strictly a DKIM issue. That "From" is a special case for DKIM merely
because its signing is required doesn't change that fact.
As another data point, RFC4407 (the PRA portion of Sender ID) also declared
that a multiple-From message could not be considered to have a valid Purported
Responsible Address, and so Sender ID cannot execute on such a message because
there is no input to its algorithm.
And I do not buy the argument that DKIM is the right place to "fix" this just
because it's the most recent email RFC that email people might read.
Maybe we need a "Be Liberal In What You Accept Considered Harmful" document.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html