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.


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?


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.

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 -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Reply via email to