Below Barring more discussion, I'll get it uploaded in the next 24 hours. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Martin Thomson via Datatracker <noreply@xxxxxxxx> > Sent: Tuesday, January 28, 2025 8:45 PM > To: art@xxxxxxxx > Cc: dmarc@xxxxxxxx; draft-ietf-dmarc-aggregate-reporting.all@xxxxxxxx; last- > call@xxxxxxxx > Subject: Artart telechat review of draft-ietf-dmarc-aggregate-reporting-26 > > Reviewer: Martin Thomson > Review result: Ready with Nits > > Thanks for the new sections describing the format. I found them very helpful. > I don't know what your alternatives look like, but I found this quite > comprehensible. > > > S2.5 says "the Mail Receiver MAY send a short report indicating that a > > report is available but could not be sent" - how? > > This issue remains. The text is expanded, but it still includes "the URI refers to > a service that is unreachable". A short report won't get there any better than a > fully one. I get size limits, but not that part. Consider rephrasing. > I'm okay to remove this blurb. I'd be curious to know if any report generator has a mechanism to generate a message in some automated fashion. I would suspect upon noticing failures to an important destination, one would try to reach out via other channels. And if it's not an important destination, I'd think that folks just shrug and move on. I haven't removed it yet, but if no objections, I'll do so as part of the next upload. > > It's not clear to me that the strict rules regarding the construction > > of > filenames and subjects is justified, especially when the report contains the > same information. > > We discussed this and it seems to overly proscribe behaviour, beyond what > interop calls for. ¯\_(ツ)_/¯ I think operationally, while this is a bit on the strict side, this can help report receivers understand if there is a duplicate without having to unpack a potentially large XML/zip file. Not sure if others have a different take. > > > S3 defines a validation process that involves querying DNS at > > "<provider > > name>._report._dmarc.<target name>". This will fail when this string > > name>is too > > long [...] > > Discussed and I'm satisfied with the response. However, it is definitely worth > noting that owners of long domains will need to find owners of short domains > to outsource to, or do it for themselves. Add a short paragraph for this note > > > The schema [...] > > NEW: I completely missed that this replaces RFC 7489. It's mentioned only in > the document header and acknowledgments. Please add notes to the > abstract and consider including a section that explains the differences. > Added some bits in Abstract and Appendix. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
