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://www.ietf.org/mailman/listinfo/dmarc
