Doug, I believe I have asked you before to provide specific examples of current domains with records that will cause a problem if assessed via the DMARCbis approach. If there's a real problem that needs solving, then surely there are examples of it. If they're none, then how about moving on.
I think you're misreading the thread. Let's have an example of a real domain, with a real DMARC record, that would be negatively impacted by being assessed using the DMARCbis design. I haven't found any I think are problematic, but if you have, I'm all ears? Scott K On June 12, 2022 8:08:13 PM UTC, Douglas Foster <[email protected]> wrote: >Les' question has returned us to the problem of justifying the tree walk. > We need to document the problems with PSL, but we also need to demonstrate >that the tree walk solves those problems without creating others. > >In most cases, the tree walk and PSL will produce the same results, because >they will both find the top-most DMARC policy in a structure with neither a >private registrar nor a PSD policy. So the justification is really >limited to those exceptions. > >We assume that most PSL errors will cause organization fragmentation, >because of identifying a private registry for XSS purposes which is not a >private registry for email purposes. We also know that the current DNS >has no information about private registries, so if we apply the tree walk >to the current DNS, we may sometimes error by landing too high and causing >inappropriate organization consolidations. > >In the case that the tree walk stops lower than the PSL target, the most >secure solution is to believe the DNS policy. This can only occur if the >policy has a DMARCbis token which explicitly says that a policy has the >Organizational Domain role. > >In the case that the tree walk stops higher than the PSL target, which do >we believe? To tilt the decision in favor of the tree walk, we need a >token which indicates that the tree walk did not pass over an undocumented >private registry. This will also require a new token on the >organizational domain, which is not yet defined. I see these possible >informational signals: >- No private registries or organizational boundaries underneath this >organizational domain. >- All sub-organizations underneath this organizational domain are also >documented with organizational domain DMARC policies. >- A private registry exists underneath this organizational domain and is >documented with a PSD policy. > >This means that for either exception, a new DMARCbis token is required on >the organizational domain. Consequently, a domain which has not published >an applicable DMARCbis token should be evaluated using the PSL, and a >domain which has published a sufficient set of DMARCbis tokens should be >evaluated using the Tree Walk. This approach also satisfies our other >requirement, which is that the tree walk requires an organizational domain >policy. > >I know this is discouraging, because John's original hope was to avoid >placing a change requirement on domain owners, but I do not see that it can >be helped. > >Doug Foster > > >On Thu, Jun 9, 2022 at 3:18 PM Les Barstow <lbarstow= >[email protected]> wrote: > >> Thank you for the history fill-in, John. That does at least explain why >> we’re here and not somewhere else. >> >> >> >> I will respectfully disagree that the “psd” tree walk standard is >> well-defined based on the remainder of my response – that the use of the >> “psd” TLA for the tag is unfortunate/misleading and that more specificity >> is desirable. But having the alternatives eliminated at least gets me to >> “it should be in this spec”. >> >> >> >> On Thursday, June 9, 2022, John Levine wrote: >> >> >> >> It appears that Les Barstow <[email protected]> said: >> >> >-=-=-=-=-=- >> >> >[Strong opinion follows] >> >> > >> >> >IMO [from April], determination of a DMARC authority boundary (registrar, >> >PSD+1, private registry (+1), or internal subdomain >> >> >boundary) should really be done outside of the DMARC standard altogether – >> >a separate DNS lookup not dependent or centered >> >> >around DMARC, and one flexible enough to respond with indications of >> >various levels of authority. It is useful for >> >> >decentralizing other queries beyond just DMARC (e.g. determining an >> >appropriate WHOIS TLD for lookup). Unfortunately, here we >> >> >are at draft 8 of the new DMARC standard and we have nothing to use as a >> >sidecar mechanism. >> >> >> >> The DBOUND working group already tried and failed to come up with a >> >> general way to publish DNS boundaries, so we're not going back there. >> >> >> >> >Is there a driving need to have this in the standard NOW? >> >> >> >> Yes, of course. The point of writing a standard is to tell people what >> >> to do to interoperate. The current underspecified fudge which winks at >> >> the PSL has well known issues since, among other things, the people >> >> who run the PSL have made it quite clear that it's not designed to >> >> make DMARC work. It contains plenty of entries which make sense for >> >> web cookies but not for DMARC. >> >> >> >> The tree walk is well specified and doesn't depend on third parties >> >> who aren't interested in what we want or need. >> >> >> >> R's, >> >> John >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
