Time for some data collection: Who has a reporting implementation in use which is designed and tested to support at least 100 DKIM signatures?
What are the maximum number of signatures ever observed on a single message? What can you tell us about the curve of signature count vs. message volume? How common are messages with 5, 10, 25, or 50+ signatures? Doug Doug On Tue, Oct 4, 2022 at 5:23 AM Laura Atkins <[email protected]> wrote: > > > On 3 Oct 2022, at 23:31, Douglas Foster < > [email protected]> 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 <[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 > > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > [email protected] > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
