You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Run a trustymail DMARC scan on any domain having fo tag values that include both 0 and 1 (omb.gov, for example).
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?
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:
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.
The text was updated successfully, but these errors were encountered:
🐛 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:
trustymail
DMARC scan on any domain having fo tag values that include both 0 and 1 (omb.gov, for example).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.
trustymail
mark the DMARC record as invalid?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:
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:
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.
The text was updated successfully, but these errors were encountered: