Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14
Brotman, Alex wrote on 2024-03-23 19:17: 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? Sure, sample follows. It's a rare sighting, but I believe it's valid. 195.201.14.36 3 none pass pass wander.science wander.science wander.science 2023-05-rsa pass pass wander.science 2023-05-ed25519 neutral invalid (unsupported algorithm ed25519-sha256) mail.swznet.de helo pass wander.science mfrom pass Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14
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 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 pass, > but still results in quarantine. Is that an > adequate > example? > Suggestion: change to pass. > > 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
Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14
Matthäus Wander wrote on 2024-03-21 23:23: - 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." This paragraph could use some more explanation. The following text proposal is consistent with the XML schema in the appendix and with actual reports received. OLD: Within the identifiers element, there MUST exist the data that was used to apply policy for the given IP. In most cases, this will be a header_from element, which will contain the 5322.From domain from the message. NEW: Within the identifiers element, there MUST exist the data that was used to apply policy for the given IP address. There MUST be a header_from element, which will contain the RFC5322.From domain from the message. There MAY be an optional envelope_from element, which contains the RFC5321.MailFrom domain or the RFC5321.Helo domain that the SPF check has been applied to. This element MAY be existing but empty if the message had a null reverse-path ([RFC5321], Section 4.5.5). There MAY be an optional envelope_to element, which contains the RFC5321.RcptTo domain from the message. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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 pass, but still results in quarantine. Is that an adequate example? Suggestion: change to pass. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
