I favor being explicit in the reporting. Michael Hammer
On Thu, Mar 9, 2023 at 1:51 PM Trent Adams <tadams= 40proofpoint....@dmarc.ietf.org> 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&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> on behalf of "Brotman, Alex" < > Alex_Brotman=40comcast....@dmarc.ietf.org> > *Date: *Wednesday, March 8, 2023 at 9:25 AM > *To: *"dmarc@ietf.org" <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 > > 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
