> On 3 Oct 2022, at 23:31, Douglas Foster <dougfoster.emailstanda...@gmail.com> > wrote: > > 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.
Knowing what domain is signing is important if you think things should be signed but they’re not aligning. Knowing what they’re being signed with helps treat the problem. A very simple case is: if you have 2 domains you’re using at Google Workspace sometimes Google will pick the wrong one to sign. So your mail fails DKIM alignment. Without knowing the domain, it’s impossible to troubleshoot what’s going on here. > 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. This is the type of suggestion that has broken SPF. I do not support it. laura > > Doug Foster > > > On Mon, Oct 3, 2022 at 2:17 PM Alessandro Vesely <ves...@tana.it > <mailto:ves...@tana.it>> 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 <alex_brot...@comcast.com > > <mailto:alex_brot...@comcast.com>> 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 > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc > <https://www.ietf.org/mailman/listinfo/dmarc> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
