On Wednesday, April 17, 2024 9:20:10 PM EDT John Levine wrote: > It appears that Todd Herr <[email protected]> said: > >When DMARC was first developed, there was concern about DNS load and > >needing to minimize DNS lookups. Operational expertise now shows that this > >is no longer cause for concern. > > > >Short circuiting a tree walk has led to many issues, like a reliance on the > >PSL, complicated algorithms for Org Domain discovery, ... > > I have to say I have some sympathy for just taking out the limit and > if you sometimes need to walk umpteen levels on stupid domains, so be > it. > > Or I suppose say if there's more than 8 components in the name, just stop > because no domain actually used for mail is that deep. Take out the skip > stuff.
I am not entirely unsympathetic, but I think what we have is reasonable and based on Todd's message that I just replied to, I think we can leave it as is with some additional discussion. I prefer we define the constraint (however we do it) so that record publishers can have some common expectation of what DMARC receivers will do. My experience with these kinds of things is that if we don't define the DOS constraints in the protocol where we've identified a potential issue there will be problems in implementation ranging between those the make an overly narrow constraint to those the believe that since the constraint isn't in the RFC, it's not allowed. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
