In the new section 8.14, I believe there is many statements that are hardly true, but subjective and written by someone begging to pass the buck with conflictive arguments.
DKIM is part of the SYSTEM, DKIM is NOT the SYSTEM. Lets play fair with all parties. 1) Contradiction Many email implementations do not enforce [RFC5322] with strictness. As discussed in Section 5.3 DKIM processing is predicated on a valid mail message as its input. 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. Reword this. 2) There is no intent. With the intent of providing a better user experience, many agents tolerate these violations and deliver the message anyway. There is no intent by anyone to allow violations. This isn't a game. People have commercial systems and do not just say "Hell, lets not follow rules." There are just things that are not expected just like DKIM didn't expect it. Also keep in mind, many systems do reject or flag bad RFC 822/8222/5322 messages. The issue here is that DKIM was a loophole even against compliant RFC5322 checking systems as the President Obama message shown. Reword this. 3) Philosophical conflictive parenthetical sentence: (This can also be taken as a demonstration that DKIM is not designed to support author validation.) It demonstrated the opposite. Please, DKIM *does not reduce* the long historical power of author of the message in any shape or form. The AUTHOR will always be a powerful part of the message. DKIM does validate the author and this requirement is reaffirmed by its special consideration - the only REQUIRED header binding. Until the 5322.From binding is made optional, it will always continue to be very important. In addition, the statement is protocol inconsistent with other existing and new internet protocols that do and continue to make the author a powerful part of the message. Please STOP trying to disassociate the 5322.From from the long time email message communication between parties. Please remove this "Oh by the way.." parenthetical statement. Here is my reworded text. I would not give the "How to Exploit." Let the bad guy figure it out. No blaming anyone. 8.14. Attacks Involving Addition of Header Fields Historically, email implementations have been tolerant of less than 100% strict RFC822, RFC2822 and RFC5322 formatted messages. There are certain elements within DKIM predicated on having a valid RFC 5322 messages. For example, a message with a single From: header field is expected and required by DKIM. Having more than one From: header violates Section 3.6 of [RFC5322] and should be rejected or flagged by receiving MTA systems and not passed on to DKIM signing engines. A signer wishing to be resistant to any specific multiple header attacks can include in the signed header field list an additional instance of each field that was present at signing. For example, a proper message with one From: field could be signed using "h=From:From:..." Because of the way header fields are canonicalized for input to the hash function, this would prevent additional fields from being added, after signing, as this would render the signature invalid. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html