I think I would prefer that we introduce a “z” tag into the DMARC record to allow specifying one of a handful of existing compression algorithms, and if absent, fall back to gzip. I realize that means Todd needs to alter the core document, and we need to come up with a handful of permitted compression algorithms. There would need to be language in the aggregate document that report receivers and generators MUST support gzip as the common compression as the fallback. If we do that, does everyone just end up using gzip anyway?
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Steven M Jones <[email protected]> Sent: Thursday, November 21, 2024 12:31 AM To: [email protected] Subject: [dmarc-ietf] Re: Publication has been requested for draft-ietf-dmarc-aggregate-reporting-21 On 11/21/24 12:41, Murray S. Kucherawy wrote: On Wed, Nov 20, 2024 at 6:48 PM Brotman, Alex <[email protected]<mailto:[email protected]>> wrote: * Section 2.6.2 requires gzip. What about other methods like zstd which can provide better compression? This is the first time that has been asked. I suppose it could be changed, though, it seems as though it would break existing report ingestion. Are zipped reports large enough to benefit? The reason I bring it up is because compression mechanisms more modern than gzip, such as Brotli and zstd, have been published as RFCs since RFC 7489, so I wonder if there would be any advantage to allowing those. If there's never been any need and we're satisfied with gzip, that's fine. I just figured I'd ask the question. I'd be happy not to lock everything into gzip for the next X years, but can we allow flexibility without creating an issue for existing code? We could add something like (completely off-the-cuff) "+zstd" or "+brotli" at the end of the "rua=" value, and if neither of those are present you stick to gzip? That'd have to go into the DMARCbis draft with the notation, allowed values, and RFC references... Worth the effort? --S.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
