-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Tuesday, October 12, 2010 8:48 AM
To: ietf-dkim(_at_)mipassoc(_dot_)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