A cursory glance at the policies for domains under our purview indicates that there are more than a negligible number that'll return different results whether the evaluator performs the RFC7489 "hop" or proposed "tree walk" to determine the policy. To gauge true impact, we're spinning up a deeper analysis looking not just at the number of domains effected and considering the overall volume/type impact (i.e. not all domains operate equally). We should have a more solid data analysis soon.
Regardless of the outcome of that analysis, though, it does seem reasonable to ask the reporter to include a tag indicating the method they employed to discover the policy. They will know which method they use, it's reasonable to request they include it, and it'll significantly improve the utility of the reports. Further... while trouble-shooting authentication problems, it's useful to compare reports from multiple sources, and when doing so it'll be necessary to distinguish between discovery methods. In short, I am strongly in favor of including a tag within the RUA that indicates which discovery mechanism was employed. For all the reasons previously discussed, it may not be wise to key off of a version, but we could use some indicator of discovery. - Trent From: dmarc <[email protected]> on behalf of Scott Kitterman <[email protected]> Date: Tuesday, March 28, 2023 at 9:50 AM To: "[email protected]" <[email protected]> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-08.txt Since the version number (as far as I found) is optional, it's not useful as receivers have to be able to parse reports without the hint about the version. Given the extensibility of XML and the hooks in the document for extensions, I do see Since the version number (as far as I found) is optional, it's not useful as receivers have to be able to parse reports without the hint about the version. Given the extensibility of XML and the hooks in the document for extensions, I do see either a current or likely future need. I think the number of domains for which the difference between PSL and treewalk is going to differ an any relevant way is practically nil. I can imagine a case where it might be useful, but I would expect that any receiver knowledgeable enough to make use of the indication can probably figure it out for themselves. I don't think it needs to be in this draft at all. The XML structure is extensible, so it can be addressed later if it turns out to matter to enough domains to make it worth reporting. I can live with it since it's optional (I don't think it'll get a lot of traction), but I do think it's misplaced. I think it's metadata, not message data as it's about how the receiver processed the message, not about anything that was found in the message. I think the data consistency paragraph is unnecessary at best and actively harmful at worst. It should be removed. I think it's only potential use is to support blame allocation, which isn't really an IETF standards thing. Scott K On Tuesday, March 28, 2023 11:11:46 AM EDT Brotman, Alex wrote: > Ale, > Thanks for the notes, I'll try to get those sorted out. I'll check RE the > 7405/5234 to see what I can find. I only made one minor modification there > based on a ticket JohnL had submitted. > > Scott, > > There were two version fields in this document at one point. The second > originally came about when there was a thought that there might be a > "DMARC2' in the DNS record. I'm happy to remove all references to a > "version", as I agree with you that it doesn't have much utility at this > point. As for who would switch to BIS and use PSL, that was a separate > discussion perhaps three weeks ago > (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmarc/4jyF_FytKZ1tR7bknkMi23cLQYw/__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4cpoxt6pg$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/4jyF_FytKZ1tR7bknkMi23cLQYw/__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4cpoxt6pg$>). > Trent's point was that the reporter should not leave the policy domain > being discovered left to interpretation, and instead cleanly state which > method was used. > > I can change those references. I agree that it's probably more of a > RefNeeded sort of thing. > > The Data Consistency section was added based on a fairly old ticket (from a > conversation between Tomki and Seth IIRC). Do you believe it completely > unnecessary, or that it needs to elaborate a bit more? > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -----Original Message----- > > From: dmarc <[email protected]> On Behalf Of Scott Kitterman > > Sent: Monday, March 27, 2023 3:21 PM > > To: [email protected] > > Subject: Re: [dmarc-ietf] I-D Action: > > draft-ietf-dmarc-aggregate-reporting-08.txt> > > On Monday, March 27, 2023 12:29:03 PM EDT [email protected] wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This Internet-Draft is a work item of the Domain-based > > > Message Authentication, Reporting & Conformance (DMARC) WG of the IETF. > > > > > > Title : DMARC Aggregate Reporting > > > Author : Alex Brotman > > > Filename : draft-ietf-dmarc-aggregate-reporting-08.txt > > > Pages : 29 > > > Date : 2023-03-27 > > > > I'm not convinced we entirely made progress on this revision. > > > > It's likely I missed or have forgotten the list discussion on some of > > these items, sorry for any repetition. > > > > This revision removes the optional version field, adds a new optional > > field for discovery method, and adds a paragraph on data consistency in > > reporting. There are other changes that look to be editorial. > > > > I agree with the removal of the version field. It never made any sense to > > me. > > > > I see though that the version element is only removed from the text, not > > from Appendix A and Appendix B. Is it intended to be removed? Now I'm > > confused. > > > > I don't understand who is expected to implement DMRCbis and report using > > the PSL. If you want to keep using RFC 7489, nothing stops you, but it > > would be odd to decide not to upgrade your DMARC processing, but still > > expend engineering resources to upgrade your reporting. > > > > Also, this revision correctly drops the reference to RFC 7489 because it > > was no longer referenced in Section 2.1, but now it's referenced in the > > schema, so doesn't it need to be added back? Also, this is presumably > > published with DMARCbis, which will obsolete RFC 7489. Is it good IETF > > practice to reference historic documents? > > > > I'm not sure this really adds much. If we do keep it, I think it's in the > > wrong section. How you found the policy isn't the policy that was > > published. I think this goes in the metadata section. > > > > Regarding "Data Consistency in Reporting", I don't see the point. Who is > > going to read this section and do something different? Are we suggesting > > that recording the results and reporting them is not sufficient? Do > > receivers need to run a second DMARC check on the data before sending > > feedback to make sure it's consistent? I reads like a plea not to use > > buggy software. Who do we expect to read an RFC and then realize they > > should test before deploying to avoid sending inconsistent data? > > Seriously, what behavior are we trying to motivate here that fits within > > an RFC's scope? > > > > Scott K > > > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;%3e> ><https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;%3e>> > ! > > !CQl3mcHX2A!H8G5uZT5a1ton4- > > AnqD6LNYhIxe47F4MTcjsmU0XzJyGBFHD3tirxEwynV- > > vaG21KThPjTN7ZDUhabSiLht-$ > > _______________________________________________ > dmarc mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4flerVJrQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4flerVJrQ$> _______________________________________________ dmarc mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4flerVJrQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!vIzVD4MPjSy63KWwxAq-93iLId6iqGlQ0w4m99AB5EX3pV70nGE9jDjarOtRVEmuoWcQDkn8V4flerVJrQ$>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
