On 12/1/24 02:26, John Levine wrote:
> People have been generating aggregate reports for at least 12 years. Many do
> it
> daily, some do it more often, some at 0000 UTC, most at some other time. They
> do
> what they do, and we have built systems that receive and process the reports
> that they send. I have trouble imagining what problem we think we'd solve by
> trying to tell people now, 12 years later, what schedule to use.
RFC 7489 had this:
Report generators SHOULD, wherever possible, adhere to hour
boundaries for the reporting period they are using. For
example, starting a per-day report at 00:00; starting
per-hour reports at 00:00, 01:00, 02:00; etc. Report
generators using a 24-hour report period are strongly
encouraged to begin that period at 00:00 UTC, regardless
of local timezone or time of report production, in order
to facilitate correlation.
According to data, see below, it looks like most reporters adhere to it.
> One thing I am quite sure we do not want to say is that everyone should
> generate their
> reports at 0000 UTC since that means there would be an enormous spike of mail
> from
> about 0001 to 0015 rather than being spread through the day it is now.
Absolutely agreed, the actual generation does not need to happen at the
period cut-off time, it can wait, and - as you say, and I observe the
same thing - no one seem to be in a hurry to *send* the reports at
exactly the time the reporting period ends. The reports trickle in
throughout the day.
> I agree that taking that paragraph out was the right thing to do, and there is
> nothing to change now.
I suggest that we do not drop it by the wayside and stay silent on the
matter this time, leaving any new implementer to figure it out by
themselves.
> PS: I have over 500,000 aggregate reports receeived by my small private mail
> system so I'm speaking from personal experience here.
Let's not compare the size of our stash of aggregate reports. Instead,
we can put it to good use, and get some numbers out of it.
Our data show that most reports claim to be from a 24 hour period of UTC
midnight to UTC midnight, I've extracted the begin value and grouped by
HH:MM. We mostly send to customers in Europe; CET/CEST and, to a lesser
degree, EET/EEST. The majority of the reporting periods start at
midnight UTC, the second and third most popular starting time looks to
be at local midnight CET/CEST.
10784 | 12:00 AM UTC
2864 | 10:00 PM UTC
960 | 11:00 PM UTC
149 | 02:00 AM UTC
133 | 07:00 AM UTC
89 | 03:00 AM UTC
71 | 08:00 AM UTC
48 | 10:00 AM UTC
45 | 11:00 AM UTC
41 | 10:15 PM UTC
35 | 03:00 PM UTC
32 | 02:00 PM UTC
31 | 12:00 PM UTC
26 | 01:00 PM UTC
21 | 05:00 AM UTC
Looking at interval length, rounded to the nearest minute:
15877 | 24:00
660 | 01:00
46 | 23:00
8 | 25:00
The 24 hour reporting period is overwhelming, followed by the 1 hour
reporting period orders of magnitude behind.
The cases of 23:00 and 25:00 probably come from the twice yearly DST
transition, and the sender basing its period on local midnight.
I also see every whole hour reporting period from 2 hrs .. 22 hrs, but
that is in the noise, between 1 and 21 reports, each.
Based on this data I have no qualms about recommending a 24 hour
reporting period starting at UTC midnight, as in RFC 7489.
Daniel K.
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
