Hello folks, During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see today; ARC, PSD, and BIMI. And indeed we have tickets relating to the first two. The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF. When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses. The result is in section 4 of the -02 draft [1]. and I thought we'd enhance that as we progressed. At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call). I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle. I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body. A few things I'd like to see the group reach consensus on are:
1) Extensions in their own section (as it is now) or within each <row> element 2) Must extensions be IETF-approved 3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done) Thank you for your continued feedback 1: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4 -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
