Waiting to see if we get anything else before tomorrow to do a merge/release.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Alessandro Vesely <[email protected]> > Sent: Tuesday, December 17, 2024 1:19 PM > To: John R Levine <[email protected]>; [email protected] > Subject: [dmarc-ietf] Re: Aggregate reports in the face of changing > configurations > > On Mon 16/Dec/2024 20:12:43 +0100 John R Levine wrote: > >>>>> That's easy. Delete that sentence and put back the language in > >>>>> RFC 7489 sec 7.2 that explains why it's impossible and report > >>>>> receivers need to deal with it. > >>>> > >>>> The language in RFC 7489 is rather lengthy: > >>> > >>> Indeed it is but why is that a problem? It explains the situation well. > >> > >> Agreed. Should it be a new 2.1.x subsection? > > > > Since it's so long that makes sense. > > > Looking closer, that subsection already exists, it's 2.3. Changes in Policy > During > Reporting Period. It looks the same as in RFC 7489, except that the third > possibility, "generate a report whose end time occurs when the updated policy > was detected" is omitted. It was removed in release -15 in April this year; I > cannot find a discussion about it. I'd put it back in; it is the cleanest > solution > after all. > > I created a pull request (with some difficulty :-/ > > > Best > Ale > -- > > > > > > > > _______________________________________________ > 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]
