On Monday, October 25, 2021 3:30:19 PM EDT Todd Herr wrote: > Greetings. > > There are, by my count, eleven tickets that are primarily focused on or at > least touch on the issue of policy discovery. A specialized query for them > is at this URL - https://trac.ietf.org/trac/dmarc/report/15 > > The question of policy discovery has a few options as its answer: > > - Leave things as they are (meaning look up the policy for the > RFC5322.From domain and the organizational domain of that domain if > different) > - Add a third lookup for a public suffix domain > - Walk the DNS tree from the RFC5322.From domain all the way to an > agreed-upon level in the DNS hierarchy > - Something other than what's listed here > > The topic of policy discovery has been proposed for the agenda for the > upcoming DMARC session at IETF 112, and so this message should serve to > kick off a discussion of the topic now, so that we can have a most > productive discussion on the 9th.
I think you are getting ahead of yourself as I think we would need to understand a number of other things first. Here's some immediate things that I think would need to be considered. It wouldn't surprise me if I think of more later. What does "an agreed-upon level in the DNS hierarchy" mean? The organizational domain is the current "agreed-upon level". Is this the same or something different? We know you can't do this by counting dots in a domain name. If it's the same level as the current organizational domain, then I'm not sure why we would want to add more lookups. I'm not aware of a problem that would solve. If it's all the way to the top of the hierarchy, then I'm confident the answer is no. Regardless of exactly how the PSD experiment lands, the rules for a PSD level lookup need to be different than for an individual organization, so we still need to know where the break between the organizational level and the top level is (so still not sure why you would want to do more lookups). Before we have results from the PSD experiment it would be premature to decide either to included (add the third lookup) or exclude it (decide not to add the third lookup). I recall a strong preference to do away with the PSL to define the org domain, but we've continually foundered on coming up with a suitable replacement that can achieve consensus. I'd suggest coming to some agreement on an alternate method to define the org domain or that we don't care and we can identical policy discovery to the top of the hierarchy would be the first questions to answer. Once we know the answers to those questions, then I think the actual policy discovery question will be relatively simple. My prediction is that we will pretty quickly conclude that the org domain construct is essential and then flounder for some time again about how to replace the PSL. As a thought experiment, if the PSD is always consulted when an org doesn't have a DMARC record (because we're just walking up the tree), how does everyone feel about _dmarc.com publishing sp=reject with a reporting address so that the .com operator gets feedback reports for every single .com domain that hasn't deployed DMARC yet? Unless the group consensus is that we're comfortable with that, then ditching the org domain isn't an option. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
