Tolerate experimental RFC9091 DMARC policies for Public Suffix Domains

[AZ-DPC-OA-DNR]

The currently experimental RFC9091 (https://datatracker.ietf.org/doc/rfc9091/) aims to improve DMARC functionality for domains published on the Public Suffix List (PSL, https://publicsuffix.org/), also known as Public Suffix Domains (PSD's). This RFC facilitates extending the curent DMARC spec, to be able to set policies for the special treatment of these PSD's, especially the non existing subdomains without their own DMARC record/policy.

The internet.nl email test currently marks these RFC9091 additions as errors, because "Your DMARC policy is not syntactically correct.". Despite indeed being a syntax validation of the DMARC1 spec, throwing an error when a DMARC record complies with the RFC9091 spec might not be the optimal test result. Imho, it would be better to validate ok, if RFC9091 is implemented correctly for a PSD. Perhaps with the information/disclaimer added, that experimental DMARC elements have been detected.

Example: gov.nl
The gov.nl domain is published on the PSL and the published DMARC record contains the experimental "np=reject" policy. DMARC test fails, see https://en.internet.nl/mail/gov.nl/868398/#control-panel-9.

JvB

[AZ-DPC-OA-DNR]

These subdomains and test cases might be of interest for some additional testing:

3LD with DMARC record [DMARC validation already OK - RFC9091 is overruled]
https://www.internet.nl/mail/forumstandaardisatie.gov.nl/868409/#control-panel-8

3LD without DMARC record [DMARC validation FAIL -> should validate OK]
https://www.internet.nl/mail/economicdiplomacy.gov.nl/868416/#control-panel-8

4LD without DMARC record [DMARC validation FAIL -> should validate OK]
https://www.internet.nl/mail/www.economicdiplomacy.gov.nl/868417/#control-panel-8

JvB

[edit 20230502] last two test cases should fail now (see #876 (comment)) and correctly do so.

[bwbroersma]

👍 Nice you're looking into protecting subdomains without DMARC.

Slightly off-topic: did you already consider to preload HSTS for .gov.nl like .gov.uk is doing? (and the CIO Council had some thoughts about this too for .gov:)

Zooming out even further: it’s technically possible to preload HSTS for an entire top-level domain (e.g. “.gov”), as Google first did with .google. As a relatively small, centrally managed top-level domain, perhaps someday .gov can get there.

It easier to do that now, than later. BTW currently checking gov.nl on hstspreload.org shows a 🐛 bug, probably because of an out of date publicsuffix library 🙁.

Update: actually only gov.uk is preloaded, without subdomains via some manual procedure, that a few months and some MS updates later caused some issues when Microsoft probably assumed it should include subdomains. For .gov.nl it's probably best not to take the path of using the PSD. Preoading a PSD is a manual procedure. I would expect the same output as .co.uk generates.

[AZ-DPC-OA-DNR]

<offtopic @bwbroersma>
The domains gov.nl and www.gov.nl contain no IP addresses currently, so there is no web traffic to check HTTP headers for. The test reports "Error: Cannot connect using TLS", which is correct and to be expected in this case.

Opinions on HSTS Preload differ, there are substantial downsides as well, it depends on who you ask. It is not a mandatory or recommended open standard published on the "Pas Toe of Leg Uit"-lijst (comply or explain list for NL government, in dutch). There are reasons for that, which we have to weigh in also.
</offtopic>

[mxsasha]

@AZ-DPC-OA-DNR

3LD without DMARC record [DMARC validation FAIL -> should validate OK] https://www.internet.nl/mail/economicdiplomacy.gov.nl/868416/#control-panel-8

4LD without DMARC record [DMARC validation FAIL -> should validate OK] https://www.internet.nl/mail/www.economicdiplomacy.gov.nl/868417/#control-panel-8

What makes you say these should succeed?

[AZ-DPC-OA-DNR]

Thanks for the commit, @mxsasha

What makes you say these should succeed?

Without respecting the PSL, 3LD and 4LDs without their own DMARC policy set should make use of the DMARC policy set for the 2LD (gov.nl in these two cases). The error "Your DMARC policy is not syntactically correct." implies that was the case at the time.

However, running the tests now (https://www.internet.nl/mail/economicdiplomacy.gov.nl/919744/#control-panel-8) shows the error "Your domain does not have a DMARC record". This indicates the PSL is respected. In that case the reported DMARC error is correct (both 3LD and 4LD tests should fail for this reason).

TLDR; It looks like PSL handling has changed, both tests should fail now and correctly do so.

PS: We'll add DMARC records to these subdomains soon, which will render these two subdomain test cases obsolete also.

[AZ-DPC-OA-DNR]

Any indication if/when this fix will be in production?

v=DMARC1; p=reject; np=reject;

https://en.internet.nl/mail/gov.nl/1027065/#control-panel-9
Verdict: Your DMARC policy is not syntactically correct.

https://internet.nl/mail/gov.nl/1027065/#control-panel-9
Uitslag: Je DMARC-policy is syntactisch niet correct.

JvB

[AZ-DPC-OA-DNR]

I see this is fixed now... thanks!

https://en.internet.nl/mail/gov.nl/1078340/#control-panel-9
Verdict: Your DMARC policy is sufficiently strict.

[edit 20231127] The API testresult still shows a DMARC error

JvB

[baknu]

Yes, well spotted. The 'single test' server has been upgraded. Note that the allowance for the np tag is also mentioned in the test explanation.
The 'batch test" server will be upgraded to the latest version in January.