Huh? The design is fine: check the exact match domain and then move up to N if more than N labels.
The N applies to both original and secondary walks I have legitimate messages with exact match on 6 labels, so there is no reason to disavow the ability to put a policy at that level or to disavow finding an organization at all. On Sat, Apr 20, 2024, 10:55 PM John Levine <[email protected]> wrote: > It appears that Scott Kitterman <[email protected]> said: > >> 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. > > So how about we take out the tree walk and say that if a name has more > than 8 components, don't do the tree walk and you never find an org > domain. I suppose this means the bad guys would send mail from > [email protected], which would now have no policy > but there's other reasons to reject names like that, most notably that > the name doesn't exist in the DNS. > > If people really have seen mail domains with more than 8 components, > make it 10 or whatever. > > I don't think I've ever seen a useful domain with more than 8 > components other than IPv6 rDNS and DNSBL which don't count. > > 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
