Inline below (and I apologize for the corporate URL mangler) -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> -----Original Message----- > From: Orie Steele via Datatracker <[email protected]> > Sent: Monday, February 17, 2025 3:09 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Orie Steele's Discuss on draft-ietf-dmarc-aggregate-reporting-28: > (with DISCUSS and COMMENT) > > Orie Steele has entered the following ballot position for > draft-ietf-dmarc-aggregate-reporting-28: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/state > ments/handling-ballot-positions/__;!!CQl3mcHX2A!COutvkmjzyrHMi0- > QeFuhIcSa4hpgDpKNRMgjrj0dGpdN6z8u-S1uqrOUOlG67Mqy_FM- > WO5OlLM_YecHCU$ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > dmarc-aggregate-reporting/__;!!CQl3mcHX2A!COutvkmjzyrHMi0- > QeFuhIcSa4hpgDpKNRMgjrj0dGpdN6z8u-S1uqrOUOlG67Mqy_FM- > WO5OlLMeQ15efg$ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # Orie Steele, ART AD, comments for draft-ietf-dmarc-aggregate-reporting-27 > CC @OR13 > > * line numbers: > - > https://urldefense.com/v3/__https://author- > tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf- > dmarc-aggregate-reporting- > 27.txt&submitcheck=True__;Ly8vLy8!!CQl3mcHX2A!COutvkmjzyrHMi0- > QeFuhIcSa4hpgDpKNRMgjrj0dGpdN6z8u-S1uqrOUOlG67Mqy_FM- > WO5OlLMOOiY45A$ > > * comment syntax: > - https://urldefense.com/v3/__https://github.com/mnot/ietf- > comments/blob/main/format.md__;!!CQl3mcHX2A!COutvkmjzyrHMi0- > QeFuhIcSa4hpgDpKNRMgjrj0dGpdN6z8u-S1uqrOUOlG67Mqy_FM- > WO5OlLM6EmMDk4$ > > * "Handling Ballot Positions": > - > https://urldefense.com/v3/__https://ietf.org/about/groups/iesg/statements > /handling-ballot-positions/__;!!CQl3mcHX2A!COutvkmjzyrHMi0- > QeFuhIcSa4hpgDpKNRMgjrj0dGpdN6z8u-S1uqrOUOlG67Mqy_FM- > WO5OlLM3x6DOZU$ > > Thanks to Martin Thomson for the ARTART Review. > > Keep in mind I am not an expert on email. > > ## Discuss > > ### Size limit obsolete? > > ``` > 699 given. Any reporting URI that includes a size limitation exceeded > by > 700 the generated report (after compression and after any encoding > 701 required by the particular transport mechanism) MUST NOT be used. > An > 702 attempt MUST be made to deliver an aggregate report to every > 703 remaining URI, up to the Receiver's limits on supported URIs. > ``` > > draft-ietf-dmarc-dmarcbis-39 states: > > ``` > obs-dmarc-uri = dmarc-uri obs-dmarc-report-size ; Obsolete syntax, reporters > should ignore the ; obs-dmarc-report-size if it is found in a DMARC Policy R > ``` > > Is there an incompatibility between ignore and MUST NOT here? > > Is the URI supposed to be ignored, and not used regardless of the size > constraint? Or is the URI supposed to not be ignored, and not used when the > size constraint is exceeded? Removed > > ``` > 705 If transport is not possible because the services advertised by the > 706 published URIs are not able to accept reports (e.g., the URI refers > 707 to a service that is unreachable, or all provided URIs specify size > 708 limits exceeded by the generated record), the Mail Receiver MAY > cache > 709 that data and try again later, or MAY discard data that could not > be > 710 sent. > ``` > > Does try again later here, mean check to see if the report size has changed? > Removed that portion of the statement. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### MAY distinguish by ridtxt > > ``` > 826 Optionally, the report sender MAY choose to use the same "ridtxt" > as > 827 a part or whole of the RFC5322.Message-Id header included with the > 828 report. Doing so may help receivers distinguish when a message is > a > 829 re-transmission or duplicate report. > ``` > > This MAY seems undesirable, a retransmission would need a new unique id, a > duplicate would need a new filename. How is this may related to those > requirements? > The re-transmitted report would have the same unique ID > ``` > 842 duplicate data lies with the receiver. As noted above, the sender > 843 MUST use the same unique identifiers when sending the report. This > 844 allows the receiver to better understand when duplicates happen. A > ``` > > ... when intending to send the same report? Yes, the same report > > ### Which section? > > ``` > 658 The document format supports optional elements for extensions. The > 659 absence or existence of this section SHOULD NOT create an error > when > 660 processing reports. This will be covered in a separate section. > ``` > Added reference to Section 4 > ### Is there consensus on which of these is better / recommended? > > ``` > 669 period, all depending on the Mail Receiver's implementation. Under > 670 these conditions, it is possible that a Mail Receiver could do any > of > 671 the following: > ``` > I don't believe there is a preference, and the Domain Owner/Report Aggregator should probably be able to understand/handle such variances. > ### Limitations on human readable content types > > ``` > 734 corresponding media type from below. A human-readable annotation > MAY > 735 be included as a body part (with a human-friendly content-type, > such > 736 as "text/plain" or "text/html"). > ``` > > Is i18n a consideration here? > Perhaps this human readable annotation is expected to be in the language of > the Mail Receiver and not the Author Domain? Others should chime in here, but I'd expect the report generator to use the language that best gets the point across. If that's something that needs to be translated on the receiver end, then so be it. > > ### Overwrite > > ``` > 773 "unique-id" allows an optional unique ID generated by the Mail > 774 Receiver to distinguish among multiple reports generated > 775 simultaneously by different sources within the same Domain Owner. > A > 776 viable option may be to explore UUIDs [RFC9562]. > We looked at that, though we stuck with something that was closer to the original in RFC7489 > 778 If a report generator needs to re-send a report, the system MUST > use > 779 the same filename as the original report. This would allow the > 780 receiver to overwrite the data from the original, or discard second > 781 instance of the report. > ``` > > I assume that in the case of sending a report with the same filename a new > unique id is required. Is there a missing MUST here? > As I understand this, should be the same unique-id > ``` > 808 report was generated. The second domain-name indicates the DNS > 809 domain name representing the Mail Receiver generating the report. > 810 The purpose of the Report-ID: portion of the field is to enable the > 811 Domain Owner to identify and ignore duplicate reports that might be > 812 sent by a Mail Receiver. > ``` > > Implies this is optional, I wonder what is required for "conformance" here. Ultimately, the data belongs to the receiver after processing. If they don't want to remove duplicate data, that's up to them I'd say. > > ### fraudulent reports > > ``` > 793 Email streams carrying DMARC feedback data MUST conform to the > DMARC > 794 mechanism, thereby resulting in an aligned "pass" (see Section 4.4 > of > 795 [I-D.ietf-dmarc-dmarcbis]). This practice minimizes the risk of > 796 Report Consumers processing fraudulent reports. > ``` > > What is a fraudulent report in this case? > Is it a report that contains fake records, but is transmitted in conformance > with > DMARC? Is the MUST conform mechanism including conformance to draft- > ietf-dmarc-aggregate-reporting? > Correct, fake data in a "good" report. The MUST here says the Report Receiver must apply DMARC processing to inbound reports. This would prevent a bad actor from sending reports that are from "aol.com" for example, who is currently at p=rejejct, and interpreting that data as valid from AOL. > ``` > 798 The RFC5322.Subject field for individual report submissions MUST > 799 conform to the following ABNF > ``` > > Does this imply that any non conforming report will not be processed? Yes > > ### Is there a consensus to recommend an option here? > > ``` > 847 * Reject back to sender, ideally with a permfail error noting the > 848 duplicate receipt > 849 * Discard upon receipt > 850 * Inspect the contents to evaluate the timestamps and reported > data, > 851 act as appropriate > 852 * Accept the duplicate data > ``` > > ## Nits > > ### which is the only valid value? > > ``` > 546 * "scope" MUST contain "mfrom", the only valid value. > ``` > > could be worded more clearly. Updated to hopefully be more clear > > ### was -> were > > ``` > 406 A "row" element contains the details of the connecting system, and > 407 how many e-mails was received from it, for the particular > combination > 408 of the policy evaluated. > ``` Updated > > ### PSO expand on first use > > ``` > 1083 Providing feedback reporting to PSOs for a PSD > ``` > > Or add to terminology inherited from dmarcbis. > > Updated _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
