Inline below. Thank you for your feedback -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> -----Original Message----- > From: Gunter Van de Velde via Datatracker <nore...@ietf.org> > Sent: Wednesday, February 12, 2025 11:52 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-dmarc-aggregate-report...@ietf.org; dmarc-cha...@ietf.org; > dmarc@ietf.org; barryle...@computer.org; barryle...@computer.org > Subject: Gunter Van de Velde's No Objection on draft-ietf-dmarc-aggregate- > reporting-28: (with COMMENT) > > Gunter Van de Velde has entered the following ballot position for > draft-ietf-dmarc-aggregate-reporting-28: No Objection > > 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!DLYO9r6i- > 6SzqMMucqOKg_SC1-MyS06wo4yH__SJpg4ONmN7I7wXahu- > CW9v0CYBKfrodIreIZb3oQDCztc$ > 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!DLYO9r6i- > 6SzqMMucqOKg_SC1-MyS06wo4yH__SJpg4ONmN7I7wXahu- > CW9v0CYBKfrodIreIZb3fHVnNrY$ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for > draft-ietf-dmarc-aggregate-reporting-28 > > # The line numbers used are rendered from IETF idnits tool: > https://urldefense.com/v3/__https://author- > tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf- > dmarc-aggregate-reporting-28.txt__;Ly8vLy8!!CQl3mcHX2A!DLYO9r6i- > 6SzqMMucqOKg_SC1-MyS06wo4yH__SJpg4ONmN7I7wXahu- > CW9v0CYBKfrodIreIZb36Wf__LI$ > > # DMARC isn't really my area of expertise, so this review comes from a > network generalist perspective. Some of my comments might be due to not > fully understanding the technology; just something to keep in mind! > > # following you find some non-blocking comments. > > # General Review > # ============== > > ## I noticed that the word "Mail" is sometimes written with an uppercase M > and other times in lowercase. Additionally, "email" is used in some places. > Was > this intentional? Would it make sense to standardize it and simply use "mail" > throughout for consistency? I tried to make this more consistent. > > ## idnits identifies few downrefs. The shepherd report suggest that only > RFC6713 is not in the downref register, however it seems that RFC7489 may > also not be in there > (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/downref/__;!! > CQl3mcHX2A!DLYO9r6i-6SzqMMucqOKg_SC1- > MyS06wo4yH__SJpg4ONmN7I7wXahu-CW9v0CYBKfrodIreIZb3SiI1CxU$ ) > and is an ISE document. The last call did call out the 3 downrefs. > I've heard this before, but didn't know there was a site that tracked them. I don't think we can avoid either the 6713 or 7489 references. And it seems unwise to make them informational references? I'll defer to others that may understand this a bit better. > # Detailed Review > # =============== > > 167 The report may include the following data: > > GV> next a list of metadata included. Would it be useful to add usage > GV> structure > for these? For example: I may misunderstand this request. These are specified in Appendix A. > > Report ID > * Reporting Organization (ISP, mail receiver) > * Date range covered by the report > > Email Authentication Results: > * SPF (Sender Policy Framework) alignment status > * DKIM (DomainKeys Identified Mail) alignment status > * DMARC policy result (pass/fail) > > Sending Source Details: > * IP addresses of sending servers > * Number of messages sent from each IP > * Reverse DNS information of the sending IP > > Policy Evaluation: > * The applied DMARC policy (none, quarantine, or reject) > * How many emails were accepted, rejected, or quarantined > * Alignment failures and reasons > > Domain Alignment Check: > * Whether the SPF and DKIM domains align with the From: domain > > 597 1. A signature that passes DKIM, in strict alignment with the > 598 RFC5322.From domain > 599 2. A signature that passes DKIM, in relaxed alignment with the > 600 RFC5322.From domain > > GV> idnit or clarification. Not sure what "RFC5322.From domain" wants to > specify? Is this a typo or copy/paste glitch? Most in the email industry understand that to be from the "From" specification from RFC5322, Section 3.6. If you'd like it to be made more clear, I can try to do that. > > 789 > mail.receiver.example!example.com!1013662812!1013749130.xml.gz > 790 No specific MIME message structure is required. It is presumed > that > > GV> idnit or clarification. Should this maybe read as: > There is no specific MIME message structure required with > mail.receiver.example!example.com!1013662812!1013749130.xml.gz I clarified that this applies to the report body. > > Kind Regards, > Gunter Van de Velde > Routing Area Director > > _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
