I've already noted for DMARCbis On Thu, Jan 30, 2020 at 11:08 AM Brotman, Alex via dmarc-discuss < dmarc-discuss@dmarc.org> wrote:
> Yeah, I got a few private replies that stated roughly the same. We do log > the policy at evaluation time, but I’ve probably not noticed that someone > altered their policy mid-day. And yeah, I agree, it seems like something > that if we were going to have some revision to the spec that might be made > more clear. Thanks for the responses > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* Brandon Long <bl...@google.com> > *Sent:* Tuesday, January 28, 2020 8:18 PM > *To:* Brotman, Alex <alex_brot...@comcast.com> > *Cc:* dmarc-discuss@dmarc.org > *Subject:* [EXTERNAL] Re: [dmarc-discuss] PolicyOverride in Reporting > > > > Isn't the override in the RowType? So you can just have multiple > RecordTypes, each with different RowTypes? > > > Ultimately, it seems like the report is a bunch of fields with a count, > and so the composition is to make sure that the set of rows is a "unique" > key. Theoretically you should log even the published policy at eval time, > so you can report different counts even if the policy changes over that > period... even if you'd have to send separate reports. > > The schema doesn't really make that clear, to my mind, I wouldn't have > buried the count. > > > > Brandon > > > > On Tue, Jan 28, 2020 at 5:26 AM Brotman, Alex via dmarc-discuss < > dmarc-discuss@dmarc.org> wrote: > > What is to be done if only a portion of the messages from the reporting > period receive a policy override? Perhaps this is done based on IP, or > only applied part way through the day. It seems like in the specification, > the reporting definition assumes the entire set of reported messages has > the override. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > <https://urldefense.com/v3/__http:/www.dmarc.org/mailman/listinfo/dmarc-discuss__;!!CQl3mcHX2A!VCzzeZvccB7hTba4qFIhrnWysqr7rxWDS6v3M-fEfg1IFaG4i4QGldWP17K6Wmhw0BOm$> > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html > <https://urldefense.com/v3/__http:/www.dmarc.org/note_well.html__;!!CQl3mcHX2A!VCzzeZvccB7hTba4qFIhrnWysqr7rxWDS6v3M-fEfg1IFaG4i4QGldWP17K6WoKi1GzJ$> > ) > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
