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