Description
Currently recognizing the new DMARCbis tags are already implemented in #2080. Currently we do not yet give guidance based on DMARCbis however. I propose the following changes:
-
The np tag should be set to 'reject' since there are (to my knowledge) no valid reasons to allow non-existent subdomains to send mail. A error/failure should be displayed and scores should be reduced for this. Exceptions to this are when sp is set to reject and/or p is set to reject since a missing np would automatically fallback to sp or p policy.
-
A psd tag should be configured on psd=n or psd=y. This reduces the amount of DNS lookups compared to a missing psd tag. I cannot think of a legitimate case where you would want a psd=u since the DMARC policy would either be unused (i.e. it is not the Author domain, Organisational domain or the PSD) or could have had a psd=n (Author and Organisational domain) or a psd=y (PSD). Not using it could theoretically be a security issue if a public suffix is not yet present in a mailreceivers PSL. Personally I think a warning would suffice. I am not sure if it should impact the score.
-
If using pct make sure it A) only allows for pct=100 or pct=0 and B) (when pct=0 it also includes a t tag. The opposite is true too: If using a t tag, make sure a pct=0 is included as well (for backwards compatibility). Maybe this should be considered a "failure" since I cannot think of legitimate reasons not to do this.
-
When still using rf and ri give an error since it's not compliant with DMARCbis and there are no use cases for it anymore since de facto only one option is supported.
-
Also give a warning when using maximum reportsize syntax (i.e. !10m) since it is not longer supported in DMARCbis (it ignores it). DMARC receivers usually ignore it too because of problems with partial reports.
-
Maybe we should give a warning or informational when using ruf tags because of privacy reasons?
-
An informational when not using a rua tag would maybe also be nice to hint people to setup a monitoring system for aggregate reports.
-
Lastly, if a rua tag is configured we should check if the Reporting Policies are also set (i.e. example.com._report._dmarc.thirdparty.example.net. This should be an error since DMARC receivers would not send aggregate reports do a failed validation check. The score should be reduced for this.
I wonder what you guys think.
Ps. I was aware of this ticket: #1809, but since it only covered the DNS Tree Walk I figured a new issue would suffice
Description
Currently recognizing the new DMARCbis tags are already implemented in #2080. Currently we do not yet give guidance based on DMARCbis however. I propose the following changes:
The
nptag should be set to 'reject' since there are (to my knowledge) no valid reasons to allow non-existent subdomains to send mail. A error/failure should be displayed and scores should be reduced for this. Exceptions to this are whenspis set torejectand/orpis set torejectsince a missingnpwould automatically fallback tosporppolicy.A
psdtag should be configured onpsd=norpsd=y. This reduces the amount of DNS lookups compared to a missingpsdtag. I cannot think of a legitimate case where you would want apsd=usince the DMARC policy would either be unused (i.e. it is not the Author domain, Organisational domain or the PSD) or could have had apsd=n(Author and Organisational domain) or apsd=y(PSD). Not using it could theoretically be a security issue if a public suffix is not yet present in a mailreceivers PSL. Personally I think a warning would suffice. I am not sure if it should impact the score.If using
pctmake sure it A) only allows forpct=100orpct=0and B) (whenpct=0it also includes attag. The opposite is true too: If using attag, make sure apct=0is included as well (for backwards compatibility). Maybe this should be considered a "failure" since I cannot think of legitimate reasons not to do this.When still using
rfandrigive an error since it's not compliant with DMARCbis and there are no use cases for it anymore since de facto only one option is supported.Also give a warning when using maximum reportsize syntax (i.e.
!10m) since it is not longer supported in DMARCbis (it ignores it). DMARC receivers usually ignore it too because of problems with partial reports.Maybe we should give a warning or informational when using
ruftags because of privacy reasons?An informational when not using a
ruatag would maybe also be nice to hint people to setup a monitoring system for aggregate reports.Lastly, if a
ruatag is configured we should check if the Reporting Policies are also set (i.e.example.com._report._dmarc.thirdparty.example.net. This should be an error since DMARC receivers would not send aggregate reports do a failed validation check. The score should be reduced for this.I wonder what you guys think.
Ps. I was aware of this ticket: #1809, but since it only covered the DNS Tree Walk I figured a new issue would suffice