Thanks Barry. I’ll do my best to address these and get a new version in the next week or so.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Barry Leiba <[email protected]> Sent: Wednesday, September 27, 2023 4:20 PM To: Brotman, Alex <[email protected]> Cc: [email protected]; Todd Herr <[email protected]> Subject: [EXTERNAL] Re: [dmarc-ietf] Aggregate Report Draft Thanks for that, Todd! Alex, if you want to post a new revision before I start a WGLC, I'll wait for that. Barry On Wed, Sep 27, 2023 at 3:07 PM Todd Herr <[email protected]<mailto:[email protected]>> wrote: On Wed, Sep 20, 2023 at 3:56 PM Brotman, Alex <[email protected]<mailto:[email protected]>> wrote: Hey folks, It feels like we're sort of getting near the end of work on the core document (maybe that's the optimist speaking), so I thought I'd see if there are any known issues with the aggregate reporting draft [1]. I believe I had previously addressed or closed all tickets and addressed known concerns. It's possible that some change to the main document has affected the reporting drafts in a way that hasn't yet been addressed. If you believe that document has yet to address some concern you've noted, please let us know. Thanks for your time 1: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!H7ysDk7jfjDwMiQfRc4D1P6IYmg2u7NH4SW-ylA1VeuBfkqXRvRNkmxgwoZEvKLbH5Y-Me4KxSeuDOXbEH1-dxFdJA$> My comments... Section 2.1, Aggregate Reports, contains a bulleted list headed with "The report may include the following data:". The sixth bullet ("A separate report should be generated...") seems more narrative text than a description of a data item and is to me inconsistent with the rest of the items in this list. I would move the text from this bullet to a separate paragraph, either just after the list or to the "Handling Domains in Reports" section. Section 2.1, Aggregate Reports, has a paragraph beginning with this text: "DMARC Aggregate Reports MUST contain three primary sections; one consisting of descriptive information (with two subsections), and the other a set of IP-focused row-based data." That reads to me as a description of two primary sections (descriptive information and IP-focused row-based data) not three, unless the two subsections are two of the three primary sections, but then if they are, they wouldn't be subsections. Same section, next sentence, "Each report MUST contain data for only one Author Domain". This contradicts the "A separate report should be generated..." text from the bulleted list above, because that text allows for the possibility of multiple 5322.From domains to be included in a report. DMARC and DMARCbis define Author Domain as the 5322.From domain. Pick one: subsections or sub-sections. This sentence is clunky: "The date_range section which will note begin and end values as epoch timestamps." The phrasing is a little awkward, and it reads like it is one of the two sub-sections that the paragraph is describing. However, the next sentence starts with "The other sub-section..." so I guess that date_range isn't one of the two sub-sections? Same section, in the auth_results discussion: "The dkim sub-element is optional as not all messages are signed, while there MUST be one spf sub-element. These elements MUST have a domain that was used during validation, as well as result. The dkim element MUST include a selector element that was observed during validation." I would really like that second sentence to be strengthened to require that reports contain results of attempts to validate any DKIM signature that used a domain that aligned with the 5322.From, if any such signature(s) existed. As written now, a message could be double-signed, once with the From domain and once with a 3rd party domain (e.g., an ESP) and the report might only include the 3rd signature, at least as the text reads to me. Section 2.1.1 Handling Domains in Reports - The first paragraph allows for multiple 5322.From domains in a report, but this contradicts the "Each report MUST contain data for only one Author Domain" mentioned above. Section 2.1.2 DKIM Signatures in Aggregate Report seems to address the concern I raised earlier about the text in the auth_results section, so perhaps clarifying things in that section would be the best approach. Section 2.1.3 contains a paragraph starting with NOTE that seems to be one that should be removed prior to publishing, and perhaps even prior to WGLC? Section 2.6.1 - "a commonly observed receiver limit is ten megabytes" - Is this still true? Section 2.6.1 - "ridtxt" is used twice (three times counting the "NOTE" paragraph above) before it's defined in Section 2.6.2 Section 3, Verifying External Destinations, makes mention of the "ruf" tag in the third paragraph just before the numbered list. I presume this is left over from when this text was part of RFC 7489. Step 5 in the numbered list in Section 3 makes reference to Section 6.4 ("same overall format as the policy record") but this is left over from when this text was part of RFC 7489, because Section 6.4 in this document is titled Feedback Leakage. I assume this is meant to refer to what is currently Section 5.3 in DMARCbis. Section 6.3 - Heading has extraneous "(Tkt64)" in it. Section 6.3 uses stronger language than does section 6.1 to address the same topic, namely PII in aggregate reports. 6.1 allows for the possibility that low-traffic reports might allow mapping of record elements to individuals, while the tone of 6.3 says that there is no PII, full stop. Might make sense to only address the topic in one section, rather than two. Section 6.4, Feedback Leakage. The paragraph on Multi-organizational PSDs that require DMARC starts with the word "Reports" stretched over two lines, but not hyphenated. Section 10, Normative References, contains no mention of RFC 7489 and/or DMARCbis, which seems odd. -- Todd Herr | Technical Director, Standards & Ecosystem e: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!H7ysDk7jfjDwMiQfRc4D1P6IYmg2u7NH4SW-ylA1VeuBfkqXRvRNkmxgwoZEvKLbH5Y-Me4KxSeuDOXbEH1R2jJ4LQ$>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
