Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14

["Brotman, Alex" <[e-mail]>]

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 <[e-mail]> On Behalf Of Matthäus Wander
> Sent: Thursday, March 21, 2024 6:23 PM
> To: [e-mail]
> 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
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!Bnuiz20ACdarSauiLSk8IQ3CRyWbItwpq20m0AgtFVIA2mRNyWeQMb
> -h_WUJsrvmtSbtJROBvnxFUdm0-HW0MvTSHXxGxoFC-BA$