Here are my comments on the subject document: In both the Abstract and the first paragraph of the introduction, we find the phrase "DMARC is a scalable mechanism". The word "scalable" does not appear in DMARCbis, and while there is a section in DMARCbis titled "Scalability", it makes no claim that DMARC mechanism is scalable per se; instead, "Scalability" here refers to the fact that there is no need for any pre-sending agreements between senders and receivers. I would recommend just removing the word "scalable" in both instances.
Second paragraph of the Introduction contains the phrase "Sender domain". DMARCbis defines the term "Author Domain", which is I think what's meant here, and I would argue that "Sender domain" should be changed to "Domain Owner of the Author Domain" here. Inconsistent capitalization throughout (e.g., both "Domain Owner" and "domain owner" are used) but perhaps the RFC Editors will clean that up. Broken link in the Terminology section for the definitions section of DMARCbis (at least in the HTML version). Regarding the Reporting Format Update, specifically sub-section 2 of section 4, if a message has multiple DKIM signatures and more than one DKIM signature fails to validate, does this mean that multiple failure reports will be produced? It says that each dmarc-method may appear at most once in an id-align. I would strike the parenthetical "(sometimes referred to as 'forensic reports')" entirely from the first paragraph of the Privacy Considerations section. The word "forensic" doesn't appear in either DMARCbis or the Aggregate Reporting document. I'm not quite sure that section 7.2 (Report Recipients) is even necessary. One presumes that a Mail Receiver has reviewed its policies before deciding to go ahead and do failure reporting (or not), and the seemingly implied need in section 7.2 for a Mail Receiver to do independent additional vetting of a Report Consumer goes against any claim of scalability associated with DMARC. Maybe pull a sentence or two out of it and add it the first paragraph of Privacy Considerations, something like: "The generation and transmission of DMARC failure reports raise significant privacy concerns that must be carefully considered before deployment. Additionally, Mail Receivers must be aware that Report Consumers may be able to extract and/or infer metadata from the reports, metadata that is not necessarily directly associated with the failed message." I don't offer the "Additionally...." sentence here as a possible contribution to the text so much as I present it as a placeholder for what might be pulled from section 7.2 if the authors go that route. I'm confused by the Example Failure Report (Appendix A) in two respects: 1. There is no redaction in the example, not even of the To: address 2. There are two Authentication-Results headers in the example, one of which reads, in part, "auth=pass (details omitted)" and so I'm not sure how this would appear in a Failure Report. I wonder if perhaps a more straightforward example, one that doesn't attempt to show a message that passed through a mailing list as this one seems to but rather is just a direct point A to point B message that failed, might be better? That is all... -- Todd
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
