Below -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> -----Original Message----- > From: Alessandro Vesely <[email protected]> > Sent: Sunday, December 22, 2024 8:07 AM > To: dmarc-ietf <[email protected]> > Subject: [dmarc-ietf] Aggregate reports periods > > Hi, > I have three points on this subject. > > The first is Section 2.1.1. *Handling Domains in Reports*, which correctly > explains > the number of /reports/ due for one organizational domain. However, it seems > to > assume that a report has a single /record/ for each DMARC Policy Record, which > is only true if all the reported messages, besides having the same > identifiers, also > have the same row, and the same auth_results. Isn't this the same PR that you have open now? > > > The second point is about the very concept of period. Dmarcbis says: > > Mail Receivers SHOULD generate and send aggregate reports with a > frequency of at least once every 24 hours. > > Then aggregate-reporting only adds that begin and end are timestamps > indicating > respectively the start and the end /of the time range contained in the > report/. > To a newcomer who wasn't exposed to the "ri" tag, that may mean the > timestamps of the first and last messages contained in the report. If the > sending > domain only sent one message during the relevant 24 hours, for example, begin > and end would be equal under such meaning. Under the "ri" concept, instead, > begin would start a second after the end of the previous period, so as to > obtain a > covering of time, except that periods with no messages don't have to be > reported. > Should we specify this? > Sounds like we should clarify the definition of report start/end as being the start/end of the reporting period, not the message receipt times? Do I understand that correctly? > > The third point is about when reporting periods start and end. We could say > that > a new report could be issued when there is enough data, so as to avoid reports > that would bounce because of size limits. Or we could say to use 24, 12, or > 6 hour > tiles according to experienced sizes. Or we could say nothing and see what > happens. Define "enough", and make it work for MBPs of all sizes. > > RFC 7489 also allowed issuing a new report when a policy change is detected, > an > option that the current draft has removed. Did anyone actually implement that > option? > > > Best > Ale > -- > > > > > > > > > _______________________________________________ > 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]
