On Mon 23/Dec/2024 16:50:03 +0100 Brotman, Alex wrote:
From: Alessandro Vesely<[email protected]>
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?
No, it's another flaw. That section says things like:
For a report period, there would now be two reports.
The first will be for bar.example.com, and contain only one "record",
for bar.example.com.
It will contain only one "identifier". Every different IP requires its own
record, and within a given IP there have to be separate records for different
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?
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?
That was the understanding with "ri". Then we thought it would be better if the
periods were decided by the report producer. We didn't want to say how the
report producer should decide the periods. But we still have to say that it
should decide them.
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.
It is not easy to compute the size the report will have after the data is
aggregated into XML and then compressed. If the only increase is the <count>,
the report won't grow. If the number of IPs grows steadily, as for a guy
trying all of his IPv6 numbers in turn, the report size will be unbearable.
My feeling is that even reports between gorillas don't suffer from an
unsendable size. However, I don't know. A report generator can decide to send
a report every 6 hours if that's convenient. Maybe we can say so:
The start and end of reporting periods are chosen to obtain a partition
of time, such that each instant of time belongs to exactly one period.
Empty reports must not be sent.
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?
_This_ was about that PR. Anyway, the wording above doesn't prevent it.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
