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 <todd.herr= [email protected]> wrote: > On Wed, Sep 20, 2023 at 3:56 PM Brotman, Alex <Alex_Brotman= > [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/ >> >> > 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] > *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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
