The primary key for aggregation is the SMTP domain (up to 255 characters), plus each DKIM domain (up to 255 characters) and its DKIM scope (up to 64 characters). For 100 DKIM domains to be included, the primary key becomes up to 201 fields with up to 25,919 characters. This is unmanageable with readily available tools like a SQL database.
I suggest that we start simplifying the scope, by limiting the items of interest to: (a) SPF whether pass or fail, (b) aligned DKIM domains, whether pass or fail, and (c) non-aligned DKIM domains that pass. I don't see any value in knowing about failed DKIM signatures for non-aligned domains. Perhaps someone with a sophisticated report parsing capability will be kind enough to correct me and explain. Then I suggest that the DKIM upper limit by 10, not 100. At some point, an excess of domains becomes a DDoS attack on the evaluator, and to a much lesser extent, the report recipient. Doug Foster On Mon, Oct 3, 2022 at 2:17 PM Alessandro Vesely <[email protected]> wrote: > On Mon 03/Oct/2022 18:01:06 +0200 Murray S. Kucherawy wrote: > > On Mon, Oct 3, 2022 at 10:26 AM Brotman, Alex <[email protected]> > wrote: > > > >> So we would likely need a section in the core document with a SHOULD for > >> evaluation (if it’s not already there), and then a section in the > aggregate > >> reporting for a MUST for reporting on evaluated information (if they > choose > >> to send reports at all), correct? > > > > [...] > > > > From the actual protocol standpoint, the filtering part of DMARC operates > > just fine if you make the shortcut Doug is proposing, so the first SHOULD > > is probably apt but the MUST is moot because it doesn't change > > interoperability. > > > Let me add that reporting /all/ identifiers can be unfeasible. (I, for > example, collect identifiers to be reported using SQL left join of various > copies of the table, which delivers results as just that many columns, > although > more might have been evaluated at reception time.) > > Reporting just the "most important" identifiers could be an option. > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
