DMARC fo tag values 0 and 1 mutual exclusivity: warning, syntax error, or ignore?

[chrislandis]

🐛 Summary

When a DMARC record's fo tag values include both 0 and 1, trustymail throws the syntax error "fo tag values 0 and 1 are mutually exclusive" but does not mark the domain's DMARC record as invalid (domain.valid_dmarc = False).

To reproduce

Steps to reproduce the behavior:

1. Run a trustymail DMARC scan on any domain having fo tag values that include both 0 and 1 (omb.gov, for example).
2. Look at the syntax errors field of the resulting CSV to see this syntax error there.

Expected behavior

Because trustymail reports a DMARC record syntax error, I expected that it would also mark the DMARC record as invalid.

0 is the default value and is the more restrictive value of the two, requiring all authentication mechanisms to fail to trigger a DMARC failure report, whereas 1 triggers a DMARC failure report when any underlying authentication mechanism fails.

• Does having both 0 and 1 as fo tag values cause problems for email servers trying to process the DMARC record for a domain from which it received an email?
• If having both 0 and 1 is a syntax error, should trustymail mark the DMARC record as invalid?
• Should trustymail stop checking for the presence of both 0 and 1 because RFC 7489 (see below) does not indicate this is a problem?

References and Considerations

Section 6.3 of RFC 7489 states:

   fo:  Failure reporting options (plain-text; OPTIONAL; default is "0")
      Provides requested options for generation of failure reports.
      Report generators MAY choose to adhere to the requested options.
      This tag's content MUST be ignored if a "ruf" tag (below) is not
      also specified.  The value of this tag is a colon-separated list
      of characters that indicate failure reporting options as follows:

      0: Generate a DMARC failure report if all underlying
         authentication mechanisms fail to produce an aligned "pass"
         result.

      1: Generate a DMARC failure report if any underlying
         authentication mechanism produced something other than an
         aligned "pass" result.

Note that RFC 7489 does not specify that including both 0 and 1 as fo tag values is a problem (copied/pasted from the augmented Backus–Naur form specification in section 6.4); it actually defines any combination of 0s, 1s, ds, and ss so long as they are each a single character delineated by colons:

     dmarc-fo        = "fo" *WSP "=" *WSP
                       ( "0" / "1" / "d" / "s" )
                       *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))

There is another discussion starting in this comment about whether a different problem should be a warning or an error, which may inform the direction that this issue takes.