On Tue 14/Jan/2025 13:53:58 +0100 Brotman, Alex wrote:
From: Alessandro Vesely<[email protected]>
On Mon 13/Jan/2025 16:36:43 +0100 Murray S. Kucherawy wrote:
On Mon, Jan 13, 2025 at 4:00 AM Alessandro Vesely<[email protected]> 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).
There was a PR for this, and not everyone agreed with your PR. If you want to
re-open that, please create a new thread on the list for discussion, pointing
at your PR.
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/31
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.)
This sounds like an implementation concern? If someone else makes a design
choice and can only retrieve aligned signatures, should we say that only those
should be reported?
The problem is not the kind of signatures, but the requirement to report _all_
the ones for which one attempted authentication. If you use a relational DB,
you'd need transitive closure to retrieve them all, which is an objective
implementation problem.
Besides, you can obviously retrieve only the ones you saved. The passive
wording in the draft implies that if anyone else at yours attempted validation,
you must still report it.
Finally, discussion in Section 2.1.3 (which for unknown reasons is separated
from Section 2.1.1.11) draws a preference list which is totally martian since
you MUST report all. And anyway it limits the number to 100, so what if you
attempted 1000?
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
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
