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

[Matthäus Wander <[e-mail]>]

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