On Sat, Nov 21, 2020 at 5:32 PM Douglas E. Foster <fosterd= [email protected]> wrote:
> On tree walk, I was working from John Levine's proposal, which assumes > that a tree walk has to be distance limited for performance reasons. He > tentatively proposed four levels. If you walk up the tree and find no > DMARC entry, the walk stops with the conclusion that no policy has been > issued. This approach works if (and only if) the tree exists, so that the > organization can place a policy at every fourth level. The approach > cannot work if the tree can be extended with non-existent domains. It > also conflicts with the PSD proposal which requires checking the top of the > tree structure. > What does "extended with non-existent domains" mean in the context of a tree walk? You're going to have to give an example. I had considered the top-down approach also, for the same reasons as you > mentioned. I assumed that it would be rejected because of the load placed > on upper levels of the DNS hierarchy. > It strikes me that the infrastructure near the root of the tree is likely very robust compared to that at many leaf nodes. For the moment, it is a DMARC issue to me because DMARC has accepted the > notion that unregistered domains are acceptable by default. If that can > be changed, I agree that there are other documents that need to be updated > as well. > I think that assertion goes too far. As I recall, DMARC doesn't claim that unregistered domains are acceptable by default. Rather, it cannot make an assertion about a domain for which a policy cannot be found. That's certainly true of an unregistered domain. DMARC follows DKIM and SPF in this regard; they can only make assertions about a message when the parts fall into place. When they don't, none of those protocols can form a conclusion. That's different from deciding something is "acceptable". In any case, it's unclear to me whether "bounce/discard anything from a domain that appears not to exist" fits inside DMARC. If you believe the entire ecosystem should be doing this, not just DMARC-aware operators, then I suggest these are the wrong documents in which to push for it. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
