Re: [dmarc-ietf] Figuring out the tree walk

2022-02-14 Thread John Levine
It appears that Scott Kitterman quoted: >>- If there's evidence of intent, then the argument is "The >> definition of alignment needs to change, because the current >> definition isn't what the authors intended and it exposes domains to >> security/abuse risks." >>- If not, then the

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-14 Thread Dotzero
On Mon, Feb 14, 2022 at 10:46 AM Todd Herr wrote: > On Sun, Feb 13, 2022 at 5:16 PM Dotzero wrote: > >> >> >> On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman >> wrote: >> >> >>> >>> I think "a" would be cleanest, but I think it would cause too much >>> backward >>> compatibility trouble and

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-14 Thread Scott Kitterman
On Monday, February 14, 2022 10:45:39 AM EST Todd Herr wrote: > On Sun, Feb 13, 2022 at 5:16 PM Dotzero wrote: > > On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman > > > > wrote: > >> I think "a" would be cleanest, but I think it would cause too much > >> backward > >> compatibility trouble and

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-14 Thread Todd Herr
On Sun, Feb 13, 2022 at 5:16 PM Dotzero wrote: > > > On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman > wrote: > > >> >> I think "a" would be cleanest, but I think it would cause too much >> backward >> compatibility trouble and should not be further considered. In previous >> working group

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread John Levine
It appears that Scott Kitterman said: >> b. walk up from both, stop at the first DMARC record. If they're at >> the same name and it's not a PSD, they are aligned and that's the org domain >> >> b+. walk up from both, if the DMARC records are at the same name, it has >> psd=y, and they have

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread Dotzero
On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman wrote: > > I think "a" would be cleanest, but I think it would cause too much > backward > compatibility trouble and should not be further considered. In previous > working group discussions on this I recall specific suggestions that this > would

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread Scott Kitterman
On Friday, February 11, 2022 1:25:15 PM EST John Levine wrote: > It appears that Alessandro Vesely said: > >I think it is already clear to the WG that the tree walk is screwed up. > > Yes, we know we have to rewrite sections 4.5 and 4.6. > > I think there are 2 1/2 situations we need to look

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread Douglas Foster
I have been proceeding on the assumption that we can and should implement support for independent subdomains. This is a difference with RFC 7489 which recognizes the additional complexities in the deployed ecosystem. The tree walk must find an organizational domain to act as an upper bound on

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread John R Levine
When I proposed the tree walk, I saw three self-evident conditions that any tree walk has to meet: 1. The result of the tree walk is the same as the current scheme in nearly every case. 2. The tree walk uses only the results of the DNS queries, not any external reference maintained by

Re: [dmarc-ietf] Figuring out the tree walk

2022-02-13 Thread Alessandro Vesely
On Fri 11/Feb/2022 19:25:15 +0100 John Levine wrote: It appears that Alessandro Vesely said: I think it is already clear to the WG that the tree walk is screwed up. Yes, we know we have to rewrite sections 4.5 and 4.6. I think there are 2 1/2 situations we need to look at. The first is