Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

It appears that Brotman, Alex said: >To summarize, > >We'd like to see extensions available both below the "feedback" and "record" >elements. The -02 draft only has it below the "feedback" element. I agree >that all >elements, each time they are utilized, should mention a reference as to how

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

On Mon 14/Jun/2021 14:41:44 +0200 Brotman, Alex wrote: I agree that all elements, each time they are utilized, should mention a reference as to how they are to be utilized. [...] So, a sample report may look something like: 2.0 2 So why doesn't mention a

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

r at the domain level. Does this seem reasonable? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Matthäus Wander > Sent: Saturday, June 5, 2021 7:56 AM > To: dmarc@ietf.

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

s this seem reasonable? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: dmarc On Behalf Of Matthäus Wander > Sent: Saturday, June 5, 2021 7:56 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Extensions in Aggregat

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

Alessandro Vesely wrote on 2021-06-04 11:26: Second, I'm not sure we need an container. I'd go for an example like, say, so: [...]    xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0;> > [...]   xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0;> If we use an attribute for

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

ARC shows the need for extension data within elements: Example from RFC 8617: none fail fail local_policy arc=pass as[2].d=d2.example as[2].s=s2 as[1].d=d1.example as[1].s=s3 remote-ip[1]=2001:DB8::1A

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex wrote: > Hello folks, > > During our interim call last week the topic of extensions within the DMARC > aggregate report came up. There was a discussion about how to best > introduce these, but also how they might be best used. I noted three cases >

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

I agree with Alessandro's suggestions, and really like the flexibility of self-labeled elements so they can be located where appropriate rather than forcing all extensions into a single bucket. My $0.02, Trent On 6/4/21, 3:27 AM, "dmarc on behalf of Alessandro Vesely" wrote: On Thu

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote: During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see

[dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

Hello folks, During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see today; ARC, PSD, and BIMI. And indeed we