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&t=187s From: "Brotman, Alex" <Alex_Brotman=40comcast....@dmarc.ietf.org> Date: Thursday, March 9, 2023 at 11:37 AM To: Trent Adams <tad...@proofpoint.com>, "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 <tadams=40proofpoint....@dmarc.ietf.org> Sent: Wednesday, March 8, 2023 11:44 AM To: Brotman, Alex <alex_brot...@comcast.com>; 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 mechanism used for DMARC record discovery. --> <xs:element name="discovery_mechanism" type="xs:string" minOccurs="0" maxOccurs="1"/> The excepted values being the enumerated discovery mechanisms (e.g. something like "hop", "treewalk"). Thoughts? - Trent From: dmarc <dmarc-boun...@ietf.org<mailto:dmarc-boun...@ietf.org>> on behalf of "Brotman, Alex" <Alex_Brotman=40comcast....@dmarc.ietf.org<mailto:Alex_Brotman=40comcast....@dmarc.ietf.org>> Date: Wednesday, March 8, 2023 at 9:25 AM To: "dmarc@ietf.org<mailto:dmarc@ietf.org>" <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. <!-- The version declared in the DMARC record found. 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. <!-- The version declared in the DMARC record found. --> <xs:element name="version_published" type="xs:decimal" 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<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
