On Saturday, March 30, 2024 4:05:17 PM EDT Seth Blank wrote: > Section 4.6: DNS Tree Walk: > > The text is correct, but N is wrong. I've shared my notes with this list > but we never reached consensus: > https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/ > > tl;dr: N of 5 works for *org domain discovery* but falls short > *policy/reporting* discovery. The algorithm can stay the same, but N needs > to be increased and the text to match. > > I *strongly* believe that N needs to be 8 to meet operational use cases > we see today, and may still fall short in the future as this use case is > unlocked by the tree walk.
We started to discuss this in a different thread last week, before I got distracted. I'd like to pick this up taking a look at Seth's proposal and rationale directly, rather than as a side point from another discussion. I think that Seth's basic rationale is correct. N=5 works for org domain discovery. I am willing to accept that there is a need for different reporting addresses within an org and that this might require a different value of N. The problem I have is that this is outside the scope of the agreed design space. If there's consensus to expand the scope of what DMARCbis is taking on, I don't think the difference between 5 and 8 for N is operationally significant. In RFC 7489 DMARC, policy and reporting addresses can be discovered exactly two places: the RFC5322.From domain and the org domain. The DMARC records for any labels between those two domains are not assessed. As a result, any subdomain that needs a different reporting address than that specified in the org domain, needs to publish it's own DMARC record. As a side effect of the switch to the tree walk approach in DMARCbis, this is no longer true. For any subdomain without a DMARC record, the domains above it in the tree are also checked, so you can specify a different policy/ reporting address for groups of subdomains below the org domain (as long as you don't get past the max N value in length). This was never a design objective, just a side effect. As a result, I am skeptical of the claim that the thing we accidentally did, that DMARC (as defined by RFC 7489) does not do, is somehow critical. It's not at all clear to my why any organization with these long domain names can't continue to do whatever they are doing now. If we are going to change our design scope after WGLC, I think there should be a high bar for it. I think it would be an admission that there is not WG consensus to proceed and we may need another WGLC after this is sorted (but I'm happy to leave that to management to figure out). I can articulate that N=5 is based on the longest email relevant entry in the current PSL. Why N=8 and not N=7 or N=9? I think we need to have an articulable rationale for what ever number we end up with (even though that rationale probably doesn't go into DMARCbis). I suspect that once we work through it, most of the work here is about the "text to match" that Seth mentioned, I don't think the exact number is that important. Scott K P.S. Sorry for the delay, this email was more than I felt I could reasonably pull off writing from my phone. P.P.S I think I'm caught up on last call email now. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
