I believe this also means I need to alter: 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<https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-17.html#RFC5321>], Section 4.5.5).
The main document says that only the 5321.From will be used in SPF evaluations as it relates to DMARC. I believe to match the “may use SPF” portion, I need to change: The "dkim" sub-element is optional as not all messages are signed, while there MUST be at least one "spf" sub-element. To be: The "dkim" sub-element is optional as not all messages are signed, while there MAY be at least one "spf" sub-element. And also alter the XSL: <xs:element name="spf" type="SPFAuthResultType" minOccurs="1" maxOccurs="unbounded"/> To be: <xs:element name="spf" type="SPFAuthResultType" minOccurs="0" maxOccurs="unbounded"/> Does that sound reasonable? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Barry Leiba <[email protected]> Sent: Monday, August 19, 2024 11:08 PM To: Brotman, Alex <[email protected]> Cc: [email protected] Subject: Re: New Version Notification for draft-ietf-dmarc-aggregate-reporting-17.txt Thanks, Alex! This does address all but one comment/question/discussion from my review, and thanks for dealing with all that. The one that’s left might need a brief discussion before we decide on a change (and whether to change). It’s this one: The “dkim” sub-element is optional as not all messages are signed, while there MUST be at least one “spf” sub-element. As I read DMARCbis, I think it requires the use of SPF *or* DKIM, but does not *require* SPF. A sender doesn’t have to supply an SPF record, and a receiver doesn’t have to check SPF if there is aligned DKIM. What do I put in the spf sub-element if your domain doesn’t use SPF or if I didn’t check it? (And I agree that removing “forwarded” in 2.1.5 seems right.) Barry On Mon, Aug 19, 2024 at 9:20 AM Brotman, Alex <[email protected]<mailto:[email protected]>> wrote: Hey folks I believe I have mostly addressed Barry's concerns that he sent to the list last week. There was a note about two of the policy override options (section 2.1.5), "forwarded", and "trusted_forwarder". They are currently next to each other in the draft, though, I don't believe we need both. If someone else believes there is some difference that can be more properly illustrated, I'm happy to take that language. Otherwise, I'd likely remove "forwarded", and just leave the other with its current description. https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!HQEOX2UUPmgPJWhCzH9htMiPMJcpypEknHAVsTpBQG7VIqyZfqqSe4R5BmQJYKbX9zxsaNfMvGjYksW_tfE0BPGfQg$> -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>> > Sent: Monday, August 19, 2024 9:13 AM > To: Brotman, Alex <[email protected]<mailto:[email protected]>> > Subject: New Version Notification for draft-ietf-dmarc-aggregate-reporting- > 17.txt > > A new version of Internet-Draft draft-ietf-dmarc-aggregate-reporting-17.txt > has been successfully submitted by Alex Brotman and posted to the IETF > repository. > > Name: draft-ietf-dmarc-aggregate-reporting > Revision: 17 > Title: DMARC Aggregate Reporting > Date: 2024-08-19 > Group: dmarc > Pages: 29 > URL: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-> > ietf-dmarc-aggregate-reporting- > 17.txt__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf- > AqsBks7RxmB8PBP1KBLaECKDuPWQ$ > Status: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-> > ietf-dmarc-aggregate- > reporting/__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf- > AqsBks7RxmB8PBP1KBLaGlx0_4vg$ > HTML: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-> > ietf-dmarc-aggregate-reporting- > 17.html__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf- > AqsBks7RxmB8PBP1KBLaFZ4LWFXw$ > HTMLized: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-> > dmarc-aggregate-reporting__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf- > AqsBks7RxmB8PBP1KBLaGcSXfKkQ$ > Diff: > https://urldefense.com/v3/__https://author-<https://urldefense.com/v3/__https:/author-> > tools.ietf.org/iddiff?url2=draft-ietf-dmarc-aggregate-reporting-<https://urldefense.com/v3/__http:/tools.ietf.org/iddiff?url2=draft-ietf-dmarc-aggregate-reporting-__;!!CQl3mcHX2A!HQEOX2UUPmgPJWhCzH9htMiPMJcpypEknHAVsTpBQG7VIqyZfqqSe4R5BmQJYKbX9zxsaNfMvGjYksW_tfEQBbVpng$> > 17__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-AqsBks7RxmB8PBP1KBLaH_u- > OAFw$ > > Abstract: > > DMARC allows for domain holders to request aggregate reports from > receivers. This report is an XML document, and contains extensible > elements that allow for other types of data to be specified later. > The aggregate reports can be submitted to the domain holder's > specified destination as supported by the receiver. > > This document (along with others) obsoletes RFC7489. > > > > The IETF Secretariat > _______________________________________________ dmarc mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
