[dmarc-ietf] DMARC: draft-crocker-dmarc-bcp-03

[Douglas Otis <[e-mail]>]

Dear DMARC WG,

The draft-crocker-dmarc-bcp-03 repeats a mistake made in RFC5863 Section 5.4 which caused several large service providers to permit easy DKIM From spoofing. A problem one the authors of the DMARC base draft had not realized affected their own large deployment until fairly recently. This draft fails to highlight essential checks needed to augment otherwise unreliable Authentication Results. The tests described in section 10.1 of the DMARC base specification remains excluded from the DKIM signature verification process. This means a subsequent message process must include DMARC base section 10.1 checks entirely overlooked yet again in this bcp. While the informational RFC7103, Advice for Safe Handling of Malformed Messages offers informational advice, RFC5863 describing DKIM deployment also makes the same mistake in its Section 5.4 when suggesting DKIM can be used to avoid subsequent processing.  Section 2.1.2 Runtime DMARC processing - Receiver side makes the same flawed recommendation as found in RFC5863 Section 5.4 which neglects a flaw in the DKIM signature verification process affecting DKIM result validity as required to properly enforce DMARC or to bypass additional checks. 

It seems the general view is that such checks must happen at a lower level, although neither RFC5321 nor RFC6376 Section 8.15 made format compliance an acceptance requirement.  In the case of RFC5321, a store-and-forward strategy would need to negotiate minor format changes as occurred with RFC6854 for example.  No harm would have occurred if RFC6376 ensured valid signature results had valid formats and can be implemented via software switch in OpenDKIM.   This change was largely overlooked in the DMARC base draft in until an overly vague mention in 10.1 which ignores its use when handling international email addresses.  Group syntax still permits a single address, and could be used to safely signal a non-compliant source which might be confirmed by other means, for example.  Once again, a need to evolve a format specification remains overlooked.  DMARC continues to lack any visible means for making often needed exceptions, which remains a serious flaw unless it can be overcome by a domain explicit exception strategy.  

RFC5321 Section 3.3. Mail Transactions
"When the RFC 822 format ([RFC 822], [RFC 5322]) is being used, the mail data
 include the header fields such as those named Date, Subject, To, Cc,
 and From.  Server SMTP systems SHOULD NOT reject messages based on
 perceived defects in the RFC 822 or MIME (RFC 2045) message
 header section or message body.  In particular, they MUST NOT reject
 messages in which the numbers of Resent-header fields do not match or
 Resent-to appears without Resent-from and/or Resent-date."

(The footnotes have been expanded to clarify a reference to RFC 822 includes all
 versions up to and including RFC 5322)

Minor notes:

Section 3.3 makes a reference to .blah.com which is a Brazilian web site merging social network messaging. This should be converted to example.com.

Section 7.3.  Use and Reporting of Local Policy Overrides has receivers reporting back to the DMARC domain why a policy assertion was ignored.  Since DMARC lacks any mechanism (say outside that of something like TPA-Label) the DMARC domain is unable to benefit those issuing such feedback, since they are still obliged to discover needed exceptions from other sources. What is their motivation for offering override feedback?

Regards,
Douglas Otis