Here's my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals.
8.14 Malformed Inputs 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." A number of popular email packages, including MTAs, MLMs, MUAs and so forth, thus forgive or ignore properties of messages that deviate from the standard format. A frequent example involves violations of Section 3.6 of [MAIL] which specifies minimum and maximum counts for particular header fields. Thus, a message with more than one From or Subject header field is not a legal email message, but most packages apply some trivial heuristic, e.g. use the first one and ignore the others, to interfere minimally with delivery of mail that might still be desirable to end users. This can expose those packages to subtle abuse vectors. For example, two different handlers of a message might identify the Subject field of a message by choosing the first one it finds. This would always produce the same result, regardless of whether the search is top-down or bottom-up, unless a message had more than one Subject field. Although [MAIL] specifically disallows this instance, it is tolerated by many mail handling agents, and so the possibility of confusion among implementations exists. This case becomes more interesting when one considers that a filtering agent might make a filtering decision based on one header field instance but a user agent might display the other. Knowing that this is the case, an attacker seeking to fool a user might exploit this to get past filters and render false data to a user. DKIM exacerbates this concern by assigning a signature to part or all of a message. It is possible that one could craft a message conforming to [MAIL], then affix a DKIM signature to it, and then add header fields atop the message that were not signed. Since many agents will overlook the fundamental invalidity of such a message, a DKIM verifier might produce a "valid signature" result while some other agent assumes an unsigned field is valid and applies it (e.g., renders it to a user) alongside some indication attesting to the message's validity. This is especially concerning where one of the fields in question has to do with an identity, such as From or Sender. Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. 2) Refuse outright to sign or verify any message that is not syntactically valid. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the "h=" portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion).
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
