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