Domain-based Message Authentication, Reporting, and Conformance (DMARC)
draft-ietf-dmarc-dmarcbis-41

Many thanks to Stephen Farrell for his secdir review (and massive followup).

Thanks for the DMARC-bis, it is even a mostly full rewrite! I second Paul Wouters' wish that the document had an Operational Considerations Section that explained the pitfalls of DMARC, as section 7.4 does not bring a lot of solutions. Finally, the example in the appendix are dated 2002...

# Orie Steele, ART AD, comments for draft-ietf-dmarc-dmarcbis-38 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-38.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ Thanks to Scott Hollenbeck for the ART ART Review. ## Comments ### use of reports ``` 296 Domain Owners can use these reports, especially the aggregate 297 reports, not only to identify sources of mail attempting to 298 fraudulently use their domain, but also (and perhaps more 299 importantly) to flag and fix gaps in their own authentication 300 practices. However, as with honoring the Domain Owner's stated mail ``` How common is it to receive information in these reports that is impossible to fix? In other words, are these reports generating alert fatigue more often than they are helping identify real threats? There is also the question of the cost(cpu/memory/traffic/sustainability) of sending the reports. ### double negative reads awk ``` 726 from any domain, even one used by a bad actor. A DKIM-Authenticated 727 Identifier that does not have Identifier Alignment with the Author 728 Domain is not enough to validate whether the use of the Author Domain 729 has been authorized by its Domain Owner. ``` does not have + is not enough to ... makes this difficult to read. BCP14 language might be a better fit for describing the interoperability supported by alignment in 4.4.1 and 4.4.2. ### What is recommended? ``` 816 Author Domain. Neither approach is recommended, however. ``` I assume: It is RECOMMENDED to enable both DKIM and SPF. ### MUST NOT change p=none ``` 1514 Identifiers being unaligned or missing entirely. For such legitimate 1515 uses, these shortcomings MUST be addressed prior to any attempt by 1516 the Domain Owner to publish a Domain Owner Assessment Policy 1517 (#domain-owner-policy) of Enforcement (#enforcement) for the Author 1518 Domain. ``` How does this MUST achieve interoperability? The way I read this, it is a directive to not change "p=none" until all legitimate use is absent from reports. Section 7.4 makes this guidance even clearer, but uses SHOULD instead of MUST. ### MAY -> SHOULD NOT ``` 1712 Per-message failure reports can be a useful source of information for 1713 a Domain Owner, either for debugging deployments or in analyzing 1714 attacks, and so Mail Receivers MAY choose to send them. Experience 1715 has shown, however, that Mail Receivers rightly concerned about 1716 protecting user privacy have either chosen to heavily redact the 1717 information in such reports (which can hinder their usefulness) or 1718 not send them at all. See [I-D.ietf-dmarc-failure-reporting] for 1719 further information. ``` This MAY reads to me as a SHOULD NOT, given the privacy risk can the guidance be strengthened? ### MAY / SHOULD ... accept / reject ``` 1735 Mail Receivers MAY choose to accept email that fails the DMARC 1736 validation check even if the published Domain Owner Assessment Policy 1737 is "reject". In particular, because of the considerations discussed 1738 in [RFC7960] and in Section 7.4 of this document, it is important 1739 that Mail Receivers SHOULD NOT reject messages solely because of a 1740 published policy of "reject", but that they apply other knowledge and 1741 analysis to avoid situations such as rejection of legitimate messages 1742 sent in ways that DMARC cannot describe, harm to the operation of 1743 mailing lists, and similar. ``` The guidance here regarding reject feels like a weak point in the document. In context, this reads as "reject" is NOT RECOMMENDED, and if present MAY be ignored. It is RECOMMENDED to ignore it, when "other knowledge" enables legitimate messages to be distinguished? ### normative guidance on 4xy dmarc reject ``` 1857 If a Mail Receiver elects to defer delivery due to the inability to 1858 retrieve or apply DMARC policy, this is best done with a 4xy SMTP 1859 reply code. ``` Should this guidance be normative? ### Stronger guidance on encryption ``` 2399	11.7. Secure Protocols 2401 This document encourages the use of secure transport mechanisms to 2402 prevent the loss of private data to third parties that may be able to 2403 monitor such transmissions. Unencrypted mechanisms should be 2404 avoided. 2406 In particular, a message that was originally encrypted or otherwise 2407 secured might appear in a report that is not sent securely, which 2408 could reveal private information. ``` Is it possible to strengthen the guidance here (MUST / SHOULD)? ## Nits ### An attacker is... ? ``` 2460 * An is able to send mail with the Author Domain of 2461 "evil.example.com" and an Authenticated Identifier of 2462 "mail.example.com" ``` ### with -> which ``` 1512 uses, as in the case of a mail stream created by an agent of the 1513 Domain Owner but one with is not passing is due to Authenticated ``` ### size? ``` 1052 ; Obsolete syntax, reporters should ignore the 1053 ; size if it is found in a DMARC Policy Record. ``` Not sure what size is referring too. ### Please no anchor references in abstract ``` 16 DMARC permits the owner of an email's Author Domain (#author-domain) 17 to enable validation of the domain's use, to indicate the Domain 18 Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix- 19 operator) message handling preference regarding failed validation, 20 and to request reports about the use of the domain name. Mail 21 receiving organizations can use this information when evaluating 22 handling choices for incoming mail. ```

I wish the document had an Operational Considerations Section that explained the pitfalls of DMARC, eg the issues with mailing lists or alias expanders (eg like we suffer from at IETF itself). It could perhaps recommend something (eg support for From rewriting as commonly done). It feels just declaring the pain points "out of scope" is a bit of a weak solution. * Signing DNS records with Domain Name System Security Extensions (DNSSEC) [RFC4033], which enables recipients to validate the integrity of DNS data and detect and discard forged responses. Please use RFC9364 or BCP237 as the proper reference to DNSSEC.

(revised ballot for -40) Thank you to Ines Robles for the GENART review. Thank you for addressing my DISCUSS and COMMENT feedback.

Thank you for the work on this document. I wanted to acknowledge the point, particularly controversial, brought up by several people, if this document belongs to the standard track, but I agree that the rough consensus is to publish the document as standard track. I also wanted to say I appreciate the work of the authors and the working group to describe the interoperability considerations and issues.

Thanks to Miek Gieben for the DNSDIR review, and the followup (https://datatracker.ietf.org/doc/review-ietf-dmarc-dmarcbis-36-dnsdir-lc-gieben-2024-12-08/)

I am supporting Roman's Discuss on "status". Is this DE's own judgement?