On Thu, Feb 29, 2024 at 10:10 AM Todd Herr <[email protected]> wrote:
> On Thu, Feb 29, 2024 at 9:58 AM OLIVIER HUREAU < > [email protected]> wrote: > >> Would you prefer one comment/issue or in batch? >> > > I would prefer that Barry's request be honored from his original post in > this thread, to wit: > > If you have significant issues to raise that have not already been > discussed and closed, please post each of those as a separate thread. > Minor issues and editorial comments can just be posted here, to this > thread, and we can split them off if necessary. > > > As I wrote: > > I'll be tracking minor issues and editorial comments in Github Issue 121, >> which I've cleverly titled "WGLC Minor Issues and Editorial Comments". >> > > so I can pull the minor issues and comments from this thread into that > Github Issue. > Just completed a full reading of the DMARCbis document, and here are the minor nits I've collected in Github Issue 121: - Kurt Andersen's name is spelled incorrectly (Anderson) in the section titled "Acknowledgements - RFC 7489" - Introduction section: Move the word 'in' to outside the quotes in the phrases: "in strict alignment" and "in relaxed alignment" - 2.1 High-Level Goals: Perhaps flip-flop the first two bullet points - 2.2 Anti-Phishing: Change "<display-name>" to "display-name" and make it link to RFC 5322 Section 3.4 - 2.3 Scalability: Change first sentence to read "Scalability is a significant issue for systems that need to operate in *an environment* as widely deployed as current SMTP email. - 3.2.4 Enforcement: Change "mail using the domain name that is unauthenticated" to "unauthenticated mail using the domain name" - 4.7 DMARC Policy Discovery: In the following paragraph: "Handling of DNS errors when querying for the DMARC policy record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed")." should the word 'or' be inserted before the last clause 'allowing a definite DMARC conclusion to be reached ("fail closed")'? - 5.3 General Record Format - The definitions of the rua and ruf tags are a bit messy; they should be worded essentially identically, i.e., Here's what the tag means, receivers must support mailto:, $OTHER_DOCUMENT discusses third party receiver considerations and the format of these reports. (I may break this out into its own ticket/issue with proposed text.) - 5.3 General Record Format - Add link to Appendix A.7 in description of the 't' tag. - 5.7.1 Extract Author Domain - Change MAY to may - 7.6 Expansion of Domain Owner Actions Section - Change "domain owner" to "Domain Owner" -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* [email protected] *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
