On Mon 13/Jan/2025 16:36:43 +0100 Murray S. Kucherawy wrote:
Would these be more helpful submitted as PRs?  Seems like we're creating a
middle step here that blocks on Alex re-typing all of this.


I'm not sure what is going to be accepted.


On Mon, Jan 13, 2025 at 4:00 AM Alessandro Vesely <ves...@tana.it> wrote:

In Section 2.1.1.4, the criterion for defining periods is still not
defined.
I'd re-propose what I wrote last December:

     The start and end of reporting periods are chosen to obtain a partition
     of time, such that each instant of time belongs to exactly one period.
     Empty reports must not be sent.

This seems like a wordy way of saying "Reporting periods MUST NOT overlap,
and reports MUST NOT be empty."


Yes, and also that they should form a continuum (as opposite to be the min/max time of the reported messages).


In Section 2.1.1.11, *If validation is attempted for any DKIM signature,
the results MUST be included* is an excessive requirement.

Why?  Are you arguing for "SHOULD"?  If so, what's a situation where you
might not comply?


Even SHOULD is a bit too strong.

Depending on the method used, there can be practical limits to the number of signatures one can report. For example, I use a SQL statement that LEFT JOINs various queries, four of which are for DKIM signatures. I could put five or six of them, thereby slightly lengthening the overall query; anyway, the number of signature (columns) in the result is fixed[*]. (LEFT JOIN provides for NULL values if there are less signatures.)

To know if a signature verifies, one has to /attempt/ validation. Then, some signatures, especially failed ones, will be ordered after the max number of signatures.


Best
Ale
--

[*]https://dba.stackexchange.com/questions/289374/can-cte-simplify-repeated-and-possibly-recursive-joins



_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Reply via email to