> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Tuesday, October 12, 2010 8:48 AM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments > > 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.
Indeed, the advancement from PS to DS is the perfect time to tighten up requirements. It's not any kind of re-engineering. > > 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. Concur here as well. "Be liberal in what you accept, be strict in what you send" has some very clear intent behind it. > > 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. Also +0. > > 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. Concur; -1 on the change. I furthermore submit that we are compelled to describe the known "attack", as that's precisely what we are supposed to include in Security Considerations. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
