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