Thanks for the feedback. I believe I've corrected all except - 2.1: "(...) while there MUST be one spf sub-element". At least one according to the XML Schema Definition (might be two, each with a different scope "helo" and "mfrom").
Can we talk about how this looks in a sample report? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Matthäus Wander > Sent: Thursday, March 21, 2024 6:23 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Working Group Last Call on > draft-ietf-dmarc-aggregate- > reporting-14 > > Barry Leiba wrote on 2024-02-29 16:03: > > This document is also ready for our final look, so this message starts > > a working group last call for the aggregate reporting document, with > > the same timing as for the DMARC spec. > > > > Please post to the DMARC mailing list by 31 March, giving your last > > call comments (which should include “I read it and I think it’s ready” > > as well). 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. > > Editorial and nits: > > - Would it be useful to add a reference to dmarc-bis? > - 2.1: Bullet point "A separate report should be generated (...)" > appears to be a requirement, not an enumeration of data included in the > report. > - 2.1: Bullet point "The DMARC policy discovered and applied, if any" is > redundant > with "The policy requested by the Domain Owner and the policy actually applied > (if different)". > - 2.1: Write out "IP" as "IP address". > - 2.1: The terminology of having two sections and two subsections may be > misleading, as this is not reflected in the XML structure. Suggestion: > replace "subsection" with "element", which is a term used in XML. > - 2.1: "In most cases, this will be a header_from element, which will contain > the > 5322.From domain from the message." Add: "There may be an envelope_from > element, which contains the RFC5321.MailFrom domain." > - Multiple instances: Replace "5322.From" with "RFC5322.From". > - 2.1: "the 'record' element". Only instance where the element name is > enclosed > in quotes. > - 2.1: "(...) while there MUST be one spf sub-element". At least one > according to > the XML Schema Definition (might be two, each with a different scope "helo" > and > "mfrom"). > - 2.1: "(...) the value is one of > none/neutral/pass/fail/softfail/temperror/permerror." Would it make sense to > add a reference to RFC 8601? > - 2.1.3: "Specified below, the reader will see a msg-id, Report-ID, > unique-id." msg- > id is not specified below. "5322.Message-Id" is briefly mentioned in 2.6.2. > - 2.3: "(...) regardless of any requested report interval." The report > interval (ri tag) > has been removed from dmarc-bis. > - 2.6: "Any reporting URI that includes a size limitation exceeded by the > generated > report (...) MUST NOT be used." The size limitation has been removed from > dmarc-bis. However, leaving the text as-is offers the option to re-introduce > a size > limitation in future URI schemes. > - 2.6: "(...) the Mail Receiver MAY send a short report (see Section 7.2.2)" > Dangling reference: error reports have been removed. > - 2.6.2: "This transport mechanism potentially encounters a problem when > feedback data size exceeds maximum allowable attachment sizes for either the > generator or the consumer. See Section 7.2.2 for further discussion." Dangling > reference. > - 3: "(...) after conversion to an A-label if needed." Add reference to > definition of > an A-label. Dmarc-bis references Section 2.3 of [RFC5890]. > - 3: "the same overall format as the policy record (see Section 5.3)." > Section 5.3 (or 5.4) of dmarc-bis. > - 8: "report_id: UUID, specified elsewhere". Change to: "report_id: > Unique Report-ID". > - 8: "error: ?". Change to: "error: Optional error messages when processing > DMARC policy". > - 8: "The percent declared in the DMARC record". Change to: "Whether testing > mode was declared in the DMARC record." > - 9: The policy_evaluated in the sample report evaluates to <dkim>pass</dkim>, > but still results in <disposition>quarantine</disposition>. Is that an > adequate > example? > Suggestion: change to <disposition>pass</disposition>. > > Regards, > Matt > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C > Ql3mcHX2A!Bnuiz20ACdarSauiLSk8IQ3CRyWbItwpq20m0AgtFVIA2mRNyWeQMb > -h_WUJsrvmtSbtJROBvnxFUdm0-HW0MvTSHXxGxoFC-BA$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
