On 09/Nov/10 03:05, John R. Levine wrote: >> "Signers SHOULD take reasonable steps to ensure >> that the messages they're signing are valid according to [RFC 5322, >> etc]." Leaving the definition of "reasonable" out allows flexibility. It >> may be waffly, but I like the approach in this case. > > This is OK, but it misses the scenario where a bad guy takes an existing > signed message and prepends another Subject: or From: header. It's more > effective to address this in the verifier.
I'd agree on the effectiveness of that approach from a software design POV only. Designing specifications may involve different considerations... >> 3. It'd be reasonable for the DKIM spec to remind verifiers that >> signers aren't supposed to sign stuff like this, so they might >> consider that when deciding what to do with it after verification. >> It'd be reasonable to remind them of this particular case. But >> I think that all ought to be informative text. > > I don't feel strongly about how normative we make the language, but I do > think it would be a good idea to encourage verifiers not to say the > signature is valid on a message with extra headers, even if it > mechanically verifies. This catches both the sloppy signer and the > hostile intermediary. > > FWIW, my DKIM verifier has for several weeks rejected anything which has > an extra of any of these [omitted] headers: Thanks for putting it that way, John. It makes it easier to clear the issue: I think everybody agrees that DKIM specifications say nothing about rejecting. Therefore, John's software is called a "DKIM verifier" somewhat improperly. It /includes/ a DKIM verifier, but also acts as a band-pass message filter. IMHO, strong feelings about this issue come up from misunderstandings about these roles. On the one hand we have a normative definition of the mechanical properties of signatures. On the other hand we want to deal with MTA behavior, since that is the mechanism's semantics. One problem of tackling both topics within the same document is that making normative statements about MTA behavior may result in confusion between semantic validation and mechanical verification. At this point I would rephrase the third paragraph of Murray's "Take two" for 8.14 Malformed Inputs, as follows: Because of this, DKIM implementations for MTAs are strongly advised to couple with message filters who can complement their MTA's native checks and reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature validates according to normative DKIM specification. However, referring to another document --either ADSPbis or draft-kucherawy-mta-malformed-- may allow for stronger and clearer language. For example, setting "dkim=fraud" in an A-R field would not be confused with broken signatures like "dkim=fail (technically pass)". _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
