ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues

2010-10-25 00:14:57

On Oct 24, 2010, at 9:55 PM, Mark Delany wrote:

The universe of email is replete with software that forgives
messages which do not conform strictly to the grammar that defines
what valid email looks like.  This is a long-standing practice known
informally as the robustness principle, originally coined by Jon
Postel: "Be conservative in what you do, be liberal in what you
accept from others."

Well, I'm clearly the outlier here, but I think "be liberal" is
protocol nonsense that has been accepted as "conventional wisdom" for
far too long now.

Put another way, "Accept crud and pass it on" constitutes good
protocol design? Gimme a break.

More particularly, DKIM is a security protocol which means that "being
liberal" is entirely antithetical and highly risky to boot.

In short, I don't think any part of DKIM should be based on "be
liberal" because it always trades off security.

A DKIM verifier generates a single bit, "validly signed or not",
and an identifier in the "validly signed" case. It doesn't
pass mail along, well formed or not, nor does it control
whether mail is passed on or not. All it can do is provide an
identity for other pieces of the mail path to consider when
making routing decisions.

The only action a DKIM signer can take with regards to
ill-formed email is to refuse to sign it. The only action a
verifier can take with regards to ill-formed mail is to
consider it unsigned, refusing to provide information
to the rest of the mail delivery system.

Given that, I don't think that either the DKIM signer or
the DKIM verifier are the right place to take a stand against
5322 format violations. And that makes DKIM overall
a poor place to do anything other than mention
specific issues that directly affect the DKIM security model.

Cheers,
  Steve

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>