Re: [dmarc-ietf] Version in aggregate report
Thanks folks, I’ll get this cleaned up for the next revision. I’m also trying to address the remaining tickets (most, if not all, have been addressed), and make sure they’re closed. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc On Behalf Of Steven M Jones Sent: Thursday, March 9, 2023 2:49 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Version in aggregate report On 3/9/23 11:45, Tomki Camp wrote: I think that's a good idea. Mike Jones from Fortra (ne Agari) also expressed concern during M3AAWG 57 about problems for data analysis to be able to determine how a specific receiver's result was achieved, with the discovery methodology doubling. An XML indication specifying the approach that the receiver used should help allay that concern. +1, including John's point about accommodating existing implementations. --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
On 3/9/23 11:45, Tomki Camp wrote: I think that's a good idea. Mike Jones from Fortra (ne Agari) also expressed concern during M3AAWG 57 about problems for data analysis to be able to determine how a specific receiver's result was achieved, with the discovery methodology doubling. An XML indication specifying the approach that the receiver used should help allay that concern. +1, including John's point about accommodating existing implementations. --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
I think that's a good idea. Mike Jones from Fortra (ne Agari) also expressed concern during M3AAWG 57 about problems for data analysis to be able to determine how a specific receiver's result was achieved, with the discovery methodology doubling. An XML indication specifying the approach that the receiver used should help allay that concern. On Wed, Mar 8, 2023 at 8:44 AM Trent Adams wrote: > > > Alex - > > > > Good catch... and yeah, if the DMARC-bis version won't be incremented, I > agree that the "version" field in the RUA should remain "1" for both > RFC7489 and DMARC-bis so there's no disconnect in meaning of "version". > > > > What about adding a field that'd expressly identifies which DMARC record > discovery mechanism was used? > > > > That way a report analyst would be able to handle differences in results > from different evaluators (some using the RFC7489 "hop", and others using > the -bis "tree walk") for the same set of published policies. > > > > Perhaps something like: > > > > > > > minOccurs="0" maxOccurs="1"/> > > > > The excepted values being the enumerated discovery mechanisms (e.g. > something like "hop", "treewalk"). > > > > Thoughts? > > > > - Trent > > > > > > > > *From: *dmarc on behalf of "Brotman, Alex" > > *Date: *Wednesday, March 8, 2023 at 9:25 AM > *To: *"dmarc@ietf.org" > *Subject: *[dmarc-ietf] Version in aggregate report > > > > While reviewing something in the aggregate doc, I came across this bit in > the XML specification. Unless I've missed something, we're not incrementing > the version in the DMARC DNS record. > > > minOccurs="0" maxOccurs="1"/> > > > > So, if we're not changing that DNS record, obviously this "version" string > has less meaning. The prose describing the field says this would be "1" or > "2". If we're going to stick to not incrementing the version string, I need > to update this to reflect that. Not a horrible task, just wanted to be clear > before I make work for myself. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$ > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$> > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
It appears that Trent Adams said: >-=-=-=-=-=- > > >Alex - > >I think that the difference comes down to an inference made by the report >analyst (and assuming enough data to make an >informed guess) vs. the report generator expressly stating the mechanism they >used. > >IMO, it makes sense to include the signal. I'd rather not rely on inference >when an a priori statement can be transmitted. > >But yeah... what do others think? So long as we make it clear that it's optional, sure, why not. It has to be optional because existing generators don't add it. R's, John PS: Perhaps we should set up a pool for how long it takes to start getting reports that claim they didn't use a tree walk, but only go to domains that a tree walk would find. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
I favor being explicit in the reporting. Michael Hammer On Thu, Mar 9, 2023 at 1:51 PM Trent Adams wrote: > > > Alex - > > > > I think that the difference comes down to an inference made by the report > analyst (and assuming enough data to make an informed guess) vs. the report > generator expressly stating the mechanism they used. > > > > IMO, it makes sense to include the signal. I'd rather not rely on > inference when an a priori statement can be transmitted. > > > > But yeah... what do others think? > > > > - Trent > > > > PS - I'm reminded of the scene in "Seinfeld" when Kramer is pretending to > be Movie Phone and asks, "Why don't you just tell me the movie you want to > see?" https://www.youtube.com/watch?v=XagGEi_n_ok=187s > > > > > > > > *From: *"Brotman, Alex" > *Date: *Thursday, March 9, 2023 at 11:37 AM > *To: *Trent Adams , "dmarc@ietf.org" < > dmarc@ietf.org> > *Subject: *RE: [dmarc-ietf] Version in aggregate report > > > > Trent, I’m not entirely opposed to the idea, though I wonder if it’s > necessary. It seems like if the old method is used vs the tree-walk, and if > the results are different, then the policy domain in the report would be > different and easily distinguishable? > > Trent, > > > > I’m not entirely opposed to the idea, though I wonder if it’s necessary. > It seems like if the old method is used vs the tree-walk, and if the > results are different, then the policy domain in the report would be > different and easily distinguishable? I guess if you want something in the > report to point at, we can create a field. > > > > Thoughts from others? > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:* Trent Adams > *Sent:* Wednesday, March 8, 2023 11:44 AM > *To:* Brotman, Alex ; dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Version in aggregate report > > > > > > Alex - > > > > Good catch... and yeah, if the DMARC-bis version won't be incremented, I > agree that the "version" field in the RUA should remain "1" for both > RFC7489 and DMARC-bis so there's no disconnect in meaning of "version". > > > > What about adding a field that'd expressly identifies which DMARC record > discovery mechanism was used? > > > > That way a report analyst would be able to handle differences in results > from different evaluators (some using the RFC7489 "hop", and others using > the -bis "tree walk") for the same set of published policies. > > > > Perhaps something like: > > > > > > > minOccurs="0" maxOccurs="1"/> > > > > The excepted values being the enumerated discovery mechanisms (e.g. > something like "hop", "treewalk"). > > > > Thoughts? > > > > - Trent > > > > > > > > *From: *dmarc on behalf of "Brotman, Alex" < > Alex_Brotman=40comcast@dmarc.ietf.org> > *Date: *Wednesday, March 8, 2023 at 9:25 AM > *To: *"dmarc@ietf.org" > *Subject: *[dmarc-ietf] Version in aggregate report > > > > While reviewing something in the aggregate doc, I came across this bit in > the XML specification. Unless I've missed something, we're not incrementing > the version in the DMARC DNS record. > > > minOccurs="0" maxOccurs="1"/> > > > > So, if we're not changing that DNS record, obviously this "version" string > has less meaning. The prose describing the field says this would be "1" or > "2". If we're going to stick to not incrementing the version string, I need > to update this to reflect that. Not a horrible task, just wanted to be clear > before I make work for myself. > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$ > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$> > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
Alex - I think that the difference comes down to an inference made by the report analyst (and assuming enough data to make an informed guess) vs. the report generator expressly stating the mechanism they used. IMO, it makes sense to include the signal. I'd rather not rely on inference when an a priori statement can be transmitted. But yeah... what do others think? - Trent PS - I'm reminded of the scene in "Seinfeld" when Kramer is pretending to be Movie Phone and asks, "Why don't you just tell me the movie you want to see?" https://www.youtube.com/watch?v=XagGEi_n_ok=187s From: "Brotman, Alex" Date: Thursday, March 9, 2023 at 11:37 AM To: Trent Adams , "dmarc@ietf.org" Subject: RE: [dmarc-ietf] Version in aggregate report Trent, I’m not entirely opposed to the idea, though I wonder if it’s necessary. It seems like if the old method is used vs the tree-walk, and if the results are different, then the policy domain in the report would be different and easily distinguishable? Trent, I’m not entirely opposed to the idea, though I wonder if it’s necessary. It seems like if the old method is used vs the tree-walk, and if the results are different, then the policy domain in the report would be different and easily distinguishable? I guess if you want something in the report to point at, we can create a field. Thoughts from others? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Trent Adams Sent: Wednesday, March 8, 2023 11:44 AM To: Brotman, Alex ; dmarc@ietf.org Subject: Re: [dmarc-ietf] Version in aggregate report Alex - Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree that the "version" field in the RUA should remain "1" for both RFC7489 and DMARC-bis so there's no disconnect in meaning of "version". What about adding a field that'd expressly identifies which DMARC record discovery mechanism was used? That way a report analyst would be able to handle differences in results from different evaluators (some using the RFC7489 "hop", and others using the -bis "tree walk") for the same set of published policies. Perhaps something like: The excepted values being the enumerated discovery mechanisms (e.g. something like "hop", "treewalk"). Thoughts? - Trent From: dmarc mailto:dmarc-boun...@ietf.org>> on behalf of "Brotman, Alex" mailto:Alex_Brotman=40comcast@dmarc.ietf.org>> Date: Wednesday, March 8, 2023 at 9:25 AM To: "dmarc@ietf.org<mailto:dmarc@ietf.org>" mailto:dmarc@ietf.org>> Subject: [dmarc-ietf] Version in aggregate report While reviewing something in the aggregate doc, I came across this bit in the XML specification. Unless I've missed something, we're not incrementing the version in the DMARC DNS record. So, if we're not changing that DNS record, obviously this "version" string has less meaning. The prose describing the field says this would be "1" or "2". If we're going to stick to not incrementing the version string, I need to update this to reflect that. Not a horrible task, just wanted to be clear before I make work for myself. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org<mailto:dmarc@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
Trent, I’m not entirely opposed to the idea, though I wonder if it’s necessary. It seems like if the old method is used vs the tree-walk, and if the results are different, then the policy domain in the report would be different and easily distinguishable? I guess if you want something in the report to point at, we can create a field. Thoughts from others? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Trent Adams Sent: Wednesday, March 8, 2023 11:44 AM To: Brotman, Alex ; dmarc@ietf.org Subject: Re: [dmarc-ietf] Version in aggregate report Alex - Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree that the "version" field in the RUA should remain "1" for both RFC7489 and DMARC-bis so there's no disconnect in meaning of "version". What about adding a field that'd expressly identifies which DMARC record discovery mechanism was used? That way a report analyst would be able to handle differences in results from different evaluators (some using the RFC7489 "hop", and others using the -bis "tree walk") for the same set of published policies. Perhaps something like: The excepted values being the enumerated discovery mechanisms (e.g. something like "hop", "treewalk"). Thoughts? - Trent From: dmarc mailto:dmarc-boun...@ietf.org>> on behalf of "Brotman, Alex" mailto:Alex_Brotman=40comcast@dmarc.ietf.org>> Date: Wednesday, March 8, 2023 at 9:25 AM To: "dmarc@ietf.org<mailto:dmarc@ietf.org>" mailto:dmarc@ietf.org>> Subject: [dmarc-ietf] Version in aggregate report While reviewing something in the aggregate doc, I came across this bit in the XML specification. Unless I've missed something, we're not incrementing the version in the DMARC DNS record. So, if we're not changing that DNS record, obviously this "version" string has less meaning. The prose describing the field says this would be "1" or "2". If we're going to stick to not incrementing the version string, I need to update this to reflect that. Not a horrible task, just wanted to be clear before I make work for myself. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org<mailto:dmarc@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Version in aggregate report
Alex - Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree that the "version" field in the RUA should remain "1" for both RFC7489 and DMARC-bis so there's no disconnect in meaning of "version". What about adding a field that'd expressly identifies which DMARC record discovery mechanism was used? That way a report analyst would be able to handle differences in results from different evaluators (some using the RFC7489 "hop", and others using the -bis "tree walk") for the same set of published policies. Perhaps something like: The excepted values being the enumerated discovery mechanisms (e.g. something like "hop", "treewalk"). Thoughts? - Trent From: dmarc on behalf of "Brotman, Alex" Date: Wednesday, March 8, 2023 at 9:25 AM To: "dmarc@ietf.org" Subject: [dmarc-ietf] Version in aggregate report While reviewing something in the aggregate doc, I came across this bit in the XML specification. Unless I've missed something, we're not incrementing the version in the DMARC DNS record. So, if we're not changing that DNS record, obviously this "version" string has less meaning. The prose describing the field says this would be "1" or "2". If we're going to stick to not incrementing the version string, I need to update this to reflect that. Not a horrible task, just wanted to be clear before I make work for myself. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Version in aggregate report
While reviewing something in the aggregate doc, I came across this bit in the XML specification. Unless I've missed something, we're not incrementing the version in the DMARC DNS record. So, if we're not changing that DNS record, obviously this "version" string has less meaning. The prose describing the field says this would be "1" or "2". If we're going to stick to not incrementing the version string, I need to update this to reflect that. Not a horrible task, just wanted to be clear before I make work for myself. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
