Hi Marc,
I currently run support at one of those largest DMARC aggregators (dmarcian), and I used to do the same for one of the others (agari). I can tell you that this is a problem which should be addressed.
I have not attempted to reach out to owners of individual IronPort implementations, because the problem is purely an implementation bug as far as I can see. The resolution you can apply is pretty limited, and there are still failure aspects.
Consider:
- if you have 6 ESAs, there is a good chance that you have some in at least one different timezone either for failsafe purposes, or for office differentiation. (I know this is commonly the case, I used to work at IronPort as well) You're likely using CCM, so your DMARC configuration is homogeneous. ESAs in varying timezones are usually set to use time settings for that timezone.. This company is based on East Coast of the USA, the configuration says to send DMARC data at 19:00 (your native time, equating to 23:00 UTC now, but will be 22:00 during DST). This means that the 3 ESAs in a datacenter on the West Coast of the USA will report DMARC data at 19:00 Pacific time, which is actually 03:00 on the following day. DMARC aggregate reports for traffic sent from one portion of the infrastructure will be offset from data from the other portion(s). This problem is publicly observable here: https://us.dmarcian.com/dmarc-data-providers/ Providers which show to have data on a given date long the end of that UTC day are usually reporting at an end time very early in the morning, and have skewed reporting for traffic into the wrong day. Since ESAs do not support the ri tag for varying report interval, that is not a factor for ESA based environments such as mmc.com or marriott.com. Plenty of variance in the 3800+ misconfigured IPHMX hosts in that list as well.
- a second factor in the lack of proper UTC alignment for the ESA reporting is that the time an admin configures for report generation simply kicks off a collation script, which iteratively collects data for domains in some sort of sequence. This means that maybe the first domain report generated has a report timespan of Mon, 05 Jul 2021 23:00:00 UTC to Tue, 06 Jul 2021 23:00:00 UTC.
The next report (or 10th) will be Mon, 05 Jul 2021 23:00:04 UTC to Tue, 06 Jul 2021 23:00:04 UTC
Once the ESA reaches its limit of 1000 reports the report window is quite different, something like this isn't a stretch based on some I've seen: Mon, 05 Jul 2021 23:15:38 UTC to Tue, 06 Jul 2021 23:15:38 UTC
There are some obvious and less obvious reporting problems attributable to the sliding report window, but my mention of it here is more to elaborate on the point that not having a stable and universal window that reports are generated *for* is problematic.
--Tomki
