-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> -----Original Message----- > From: Alessandro Vesely <[email protected]> > Sent: Monday, January 13, 2025 1:58 PM > To: Murray S. Kucherawy <[email protected]> > Cc: [email protected] > Subject: [dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting- > 25.txt > > 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 <[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. > > > >> 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? > > 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://urldefense.com/v3/__https://dba.stackexchange.com/questions/2 > 89374/can-cte-simplify-repeated-and-possibly-recursive- > joins__;!!CQl3mcHX2A!FAuTDmxkaMle6dueyCM- > V7PiknoYC7f1wUcwesEykeEUu4GbYvSuMCsekXljn97FWHGpTwBTLehE- > b7QR9ibriT0$ > > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
