The next post with the example DKIM bypass exemplifies the point that
it is about DKIM fitting into the system, not the other way around.
The current text tries to too hard to pass the buck on other systems
when in fact, hate to say it, its about DKIM faults not anyone else.
This is especially the case when it states it knows that "many email
implementations violates RFC5322" and thats simply not true. This
offends developers quite frankly.
Lets stop rationalization and lets call it for what it is. This issue
fell through the (Threat Analysis) crack. If we realized it back in
2005/206 during the TA work, I think it is pretty safe to say we would
of closed this loop more above and beyond just simply saying "Requires
RFC 5322 compliance"
IMO, it really has nothing to do with user experiences per se,
although that might be the end result. Many, if not most, existing
systems do already check for valid 822, 2822/5322 messages, especially
ones that are blatant as this double 5322.From issue. I'm sure even
the better ones missed this one. But many systems also do
corrections, like add a missing Date: (a violations) or even a To:.
All that does is make sure things are "correct." Other systems might
not like having a missing Date for example.
The point is this is par for the course and DKIM should recognized it
to fit into it, not for others to fit into DKIM.
--
HLS
Barry Leiba wrote:
Hector says...
If DKIM designers knew there were many email implementations with less
than strict enforcement and strictness was an requirement, then DKIM
started with a problem it ignored to address. �Either it was ignorant
or poor engineering.
That's not true at all. It's common and reasonable for newer
protocols to tighten things up and require stricter adherence to the
older protocols. New features often make it unwise or incorrect to
treat earlier requirements loosely. This is one of those cases, and
in earlier versions of DKIM work there was certainly wording about
requiring valid RFC 2822 (at the time) messages.
2) There is no intent.
There is, quite often. It's very often the case that things on the
receiving side tolerate malformed messages *specifically* to avoid
rejecting more messages than necessary. "With the intent of providing
a better user experience," is absolutely correct in a great many
cases. And we're telling verifiers that when you add DKIM, that
tolerance might now be unwise.
3) Philosophical conflictive parenthetical sentence:
� (This can also be taken as a �demonstration that DKIM is not designed
� �to support author validation.)
Yeh, that's the only part I agree on (though not with the reasoning
that follows). I'm ambivalent about having that parenthetical
statement in there. I'd like to see some consensus about whether to
leave it or keep it.
Here is my reworded text. I would not give the "How to Exploit." Let
the bad guy figure it out. �No blaming anyone.
-1; I like the wording that's there.
I also look at the description of the attack not as helping "bad
guys", but as giving a clear explanation of what the problem is, so
implementers understand the problem, and the difficulty that
tolerating multiple instances of single-instance fields can create.
Barry, as participant
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html