[ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Murray S. Kucherawy
msk at cloudmark.com
Tue Oct 12 11:21:51 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Barry Leiba
> Sent: Tuesday, October 12, 2010 8:48 AM
> To: ietf-dkim at 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.
> > 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.
More information about the ietf-dkim