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 <alex_brotman= [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/ > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > > -----Original Message----- > > From: [email protected] <[email protected]> > > Sent: Monday, August 19, 2024 9:13 AM > > To: Brotman, Alex <[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- > > 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- > > 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- > > 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- > > dmarc-aggregate-reporting__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b- > > TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf- > > AqsBks7RxmB8PBP1KBLaGcSXfKkQ$ > > Diff: https://urldefense.com/v3/__https://author- > > tools.ietf.org/iddiff?url2=draft-ietf-dmarc-aggregate-reporting- > > 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
