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
