Below -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
From: Murray S. Kucherawy <[email protected]> Sent: Wednesday, November 20, 2024 10:42 PM To: Brotman, Alex <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [dmarc-ietf] Re: Publication has been requested for draft-ietf-dmarc-aggregate-reporting-21 Trimmed to the remaining things worth mentioning. We don't need to spend much time on them; they're just more of a "Did we consider this?" sort of deal. On Wed, Nov 20, 2024 at 6:48 PM Brotman, Alex <[email protected]<mailto:[email protected]>> wrote: * What's the normative SHOULD in Section 2.4 for? When might an implementer decide to do something else? What breaks if you do? I altered to no longer be normative. I also wonder if we should remove this section as “ri” is no longer part of the core document. Or instead alter the paragraph to suggest that all reports run 24hr and use 0000UTC as the boundary. I think the real issue I have with the constraint is why it's there at all. What's the advantage of stipulating a recommended time boundary? Has anyone tried this with arbitrary boundaries and it's worse? I realize this is copied forward from RFC 7489, so really this text is at least partly my fault. :-). I think I remember we added it in RFC 7489 just because we found it easier for everyone to agree that chunks of the report would always be on hour boundaries so consumers could simplify their math and their de-duping, but I wonder if that's still appropriate or was ever necessary. (I've never put much effort into supporting anything else.) I’ll just remove the section. “ri” is historical, and if someone were going to be a PITA and generate reports every minute, no language in an IETF document is going to stop them. * Section 2.6.2 says the message has to comply with both RFC5322 and RFC2045. What's going on here? Why is it required to be MIME? Could it not be a plain message that happens to contain XML? Or are we trying to say there has to be a text/xml part that contains the report, and maybe other parts that provide additional information for humans? This question might be answered by the next paragraph, in which case this might just need some copy editing. I feel like I’m reading this is meant to be an attachment with that specified type, but isn’t explicitly stated. I’m not sure if that’s the expectation of others on the list. This is what I thought, but it's not really stated clearly. If we're both right, I think we should be explicit that the report is expected to be in a MIME-encoded text/xml part (if uncompressed) or application/gzip (if compressed), and the remaining MIME structure of the message is at the discretion of the generator; the only thing the receiver cares about is that one part. I’ll make this more explicit as being expected to be an attachment. * 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 replied to Steve’s comments. We’ll continue there. * Section 2.6.2: The "dmarc-subject" ABNF needs some wrapping (or at least the text rendering is kinda messy). Added some “formatting”, which should help there. Thanks, it looks way better. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
