Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Douglas Foster <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On 3 Oct 2022, at 23:31, Douglas Foster <
> [e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> [e-mail]
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>