Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-dmarc-dmarcbis-36 Reviewer: Ines Robles Review Date: 2024-12-04 IETF LC End Date: 2024-12-04 IESG Telechat date: Not scheduled for a telechat Summary: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This draft, proposed as -Standards Track- obsoletes RFC7489 (Informational) and RFC9091 (Experimental), explanations are found in Appendix C. I have some comments and questions as follows: Issues/Questions: 1- DMARC Tree Walk: 1-1: Related to CNAME: 1.1.1- Does the resolution of a CNAME record during a DMARC Tree Walk override the normal Tree Walk process? 1.1.2- Should the Tree Walk proceed at the resolved domain after following the CNAME, or should it terminate after the CNAME resolution? 1.1.3- Is there a limit to the number of CNAME hops or redirections allowed during the Tree Walk (e.g., similar to DNS's general 5-hop limit)? 1.1.4- If a domain has both a CNAME and other DNS records (e.g., TXT), which record takes precedence for DMARC resolution? Should the CNAME always be prioritized? 1.1.5- In a CNAME chain (e.g., _dmarc.example.com → _dmarc.alias.net → _dmarc.other.net), should the Tree Walk follow all redirects until a valid DMARC record is found, or stop at a predefined limit? How should Mail Receivers handle excessively long or circular chains? 1-2: Related to Wildcard Records: 1.2.1: Does a wildcard DMARC record apply only when no explicit _dmarc record exists for the queried domain? 1.2.2: If both an explicit _dmarc record and a wildcard record exist at the same level (e.g., _dmarc.example.com and *.example.com), does the explicit record always take precedence over the wildcard? 1.2.3: If a wildcard DMARC record (*.example.com) exists, and a subdomain-specific record (_dmarc.mail.example.com) is found, should the Tree Walk stop at the subdomain record or evaluate the wildcard? 1-3: What happens if a Wildcard or CNAME resolution fails or points to an invalid/missing DMARC record? 2- How should multi-tenant email systems, where subdomains are shared among different organizations, manage DMARC policies effectively? Are there best practices or recommendations for defining subdomain policies using the sp tag in such setups? For example, in cases where multiple tenants share subdomains (e.g., tenant1.example.com and tenant2.example.com), should the sp tag be recommended to enable policy differentiation among tenants? 3- How should Mail Receivers handle malformed or incomplete DMARC records during policy discovery and evaluation? 4- How should Mail Receivers handle cases where no PSD-related DMARC policy is found (e.g., no DMARC record at the PSD level, incomplete PSD DMARC record, or missing p= tag)? 5- Should the draft include guidance on handling replay attacks that leverage valid DKIM signatures, given the potential for misuse in bypassing DMARC validation? 6-Appendix C.3: Related to "...That RFC was an Experimental RFC, and the results of that experiment were that the RFC was not implemented as written..." It would be nice to add some references to the results of that experiment. Nits: 7- Section 4.9: Add caption in Figure of Flow Diagram 8- Section 4.10: discovry --> discovery? 9- Section 10.8: Organizataional --> Organizational Thanks for this document, Ines. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
