Re: [dmarc-ietf] Thoughts on choosing N
> On Apr 17, 2024, at 6:20 PM, John Levine wrote: > > It appears that Todd Herr 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. Yeah, you aren’t designing for the perfect storm edge case. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Sun 21/Apr/2024 16:28:41 +0200 Douglas Foster wrote: 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. Is that 6-label thing the organizational domain? If not, whatever policy they put in it will be discarded, unless it's the exact From: domain. The N we're looking for is the max depth of org domains. That is, N-1 is the max depth of a public suffix domain. That's where we found 5. Best Ale On Sat, Apr 20, 2024, 10:55 PM John Levine wrote: It appears that Scott Kitterman 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 secur...@a.b.c.d.e.f.g.h.paypal.com, 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
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 wrote: > It appears that Scott Kitterman 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 > secur...@a.b.c.d.e.f.g.h.paypal.com, 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
It appears that Scott Kitterman 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 secur...@a.b.c.d.e.f.g.h.paypal.com, 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wednesday, April 17, 2024 9:20:10 PM EDT John Levine wrote: > It appears that Todd Herr 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wednesday, April 17, 2024 9:42:23 AM EDT Todd Herr wrote: > On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman > > wrote: > > I am confused. > > > > Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be > > found > > either in this case. Why do we need to support something that is > > currently > > unsupported? > > > > We picked n=5 to allow the current org level record to be detected by the > > tree > > walk. It's true that the tree walk provides some additional flexibility > > for > > subordinate organizations within what we would call a DMARC org domain > > based > > on RFC 7489, but that was by no means anything we ever described as a > > feature > > or a goal. > > I don't share your understanding here. I interpret some of the text of > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do > away with the PSL and Org Domain entirely; just walk the tree" to at least > imply that the tree walk was designed to provide this flexibility, to wit: > > 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, many types of domains > (PSDs, per https://tools.ietf.org/wg/dmarc/draft-ietf-dmarc-psd/) being > unable to utilize DMARC even though they wish to, and larger organizations > (such as universities and governments) that are comprised of > sub-organizations that use subdomains having material problems getting > everything authenticated. > > All these issues disappear, and DMARC becomes a lot simpler conceptually, > if DMARC simply walks the DNS hierarchy for the exact sending domain down > to the TLD until it finds a DMARC record, and stops. > > It's the second paragraph, specifically the "and larger organizations..." > bits to which I'm referring here. > > > Even if some organizations have very deep DNS trees, the fact that some > > entity > > uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level > > of > > their organization will still be found. > > > > In any case, any domain, at any depth in the tree can publish their own > > DMARC > > record if they need some special thing. The value of N does not affect > > that at > > all. > > Fair enough. You're correct that a DMARC policy can be published for any > specific domain used as the RFC5322.From domain, so perhaps a bit of text > in the Tree Walk section describing the really deep use case and > the solution for it might be a compromise. I'm fine with 5 (which we have an explanation for why 5) and additional explanation. I think the explanation should probably go in domain owner actions, since that's where I would focus my attention if I was trying to figure things out. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely wrote: > > On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: >>> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman >>> wrote: >>> I am confused. >>> >>> Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be >>> found either in this case. Why do we need to support something that is >>> currently unsupported? >> >>> We picked n=5 to allow the current org level record to be detected by the >>> tree walk. It's true that the tree walk provides some additional >>> flexibility for subordinate organizations within what we would call a DMARC >>> org domain based on RFC 7489, but that was by no means anything we ever >>> described as a feature or a goal. > >> I don't share your understanding here. I interpret some of the text of >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do >> away with the PSL and Org Domain entirely; just walk the tree" to at least >> imply that the tree walk was designed to provide this flexibility [...] > > > If we wanted to provide high flexibility, then we'd have designed an > inheritance system whereby, for example, policy or rua address can be > inherited from parent domains. John would 've called it mission gallop. > > >>> Even if some organizations have very deep DNS trees, the fact that some >>> entity uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top >>> level of their organization will still be found. >> >>> In any case, any domain, at any depth in the tree can publish their own >>> DMARC record if they need some special thing. The value of N does not >>> affect that at all > >> Fair enough. You're correct that a DMARC policy can be published for any >> specific domain used as the RFC5322.From domain, so perhaps a bit of text >> in the Tree Walk section describing the really deep use case and >> the solution for it might be a compromise. > > > We may say the system is harsh by design. You can rely on the org domain > settings or define your own in the From: domain. Flexibility to fetch values > from intermediate domains is not provided. I’m imagining a little chaos if such flexibility were shoe horned in. Rare, sure, but frantic, baffled stress for a few unlucky souls. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
It appears that Todd Herr 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. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: I am confused. Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found either in this case. Why do we need to support something that is currently unsupported? >> We picked n=5 to allow the current org level record to be detected by the tree walk. It's true that the tree walk provides some additional flexibility for subordinate organizations within what we would call a DMARC org domain based on RFC 7489, but that was by no means anything we ever described as a feature or a goal. > I don't share your understanding here. I interpret some of the text of https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do away with the PSL and Org Domain entirely; just walk the tree" to at least imply that the tree walk was designed to provide this flexibility [...] If we wanted to provide high flexibility, then we'd have designed an inheritance system whereby, for example, policy or rua address can be inherited from parent domains. John would 've called it mission gallop. Even if some organizations have very deep DNS trees, the fact that some entity uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level of their organization will still be found. >> In any case, any domain, at any depth in the tree can publish their own DMARC record if they need some special thing. The value of N does not affect that at all > Fair enough. You're correct that a DMARC policy can be published for any specific domain used as the RFC5322.From domain, so perhaps a bit of text in the Tree Walk section describing the really deep use case and the solution for it might be a compromise. We may say the system is harsh by design. You can rely on the org domain settings or define your own in the From: domain. Flexibility to fetch values from intermediate domains is not provided. Indeed, even if we had N=8, DMARC records at b.c.d.e.f.g and c.d.e.f.g would be discarded unless they contained psd=y or psd=n. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: > > I am confused. > > Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be > found > either in this case. Why do we need to support something that is > currently > unsupported? > > We picked n=5 to allow the current org level record to be detected by the > tree > walk. It's true that the tree walk provides some additional flexibility > for > subordinate organizations within what we would call a DMARC org domain > based > on RFC 7489, but that was by no means anything we ever described as a > feature > or a goal. > I don't share your understanding here. I interpret some of the text of https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do away with the PSL and Org Domain entirely; just walk the tree" to at least imply that the tree walk was designed to provide this flexibility, to wit: 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, many types of domains (PSDs, per https://tools.ietf.org/wg/dmarc/draft-ietf-dmarc-psd/) being unable to utilize DMARC even though they wish to, and larger organizations (such as universities and governments) that are comprised of sub-organizations that use subdomains having material problems getting everything authenticated. All these issues disappear, and DMARC becomes a lot simpler conceptually, if DMARC simply walks the DNS hierarchy for the exact sending domain down to the TLD until it finds a DMARC record, and stops. It's the second paragraph, specifically the "and larger organizations..." bits to which I'm referring here. > Even if some organizations have very deep DNS trees, the fact that some > entity > uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level > of > their organization will still be found. > > In any case, any domain, at any depth in the tree can publish their own > DMARC > record if they need some special thing. The value of N does not affect > that at > all. > > Fair enough. You're correct that a DMARC policy can be published for any specific domain used as the RFC5322.From domain, so perhaps a bit of text in the Tree Walk section describing the really deep use case and the solution for it might be a compromise. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote: > On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > Todd, can you clarify this? > > > > N is not concerned with maximum labels on a subdomain. We are interested > > in the maximum length of an org domain used for relaxed alignment. > > > > If this client wants to use level 7 as an org domain and apply relaxed > > alignment for 8-label domains, then N needs to be 7. If the client's > > lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. > > Similarly, if the7-label domain only needs strict authentication, then N=7 > > is not needed. > > > > Has this or another client genuinely chafed at the insufficient > > granularity of the old PSL? > > My understanding of the Tree Walk is that in DMARCbis it is the defined > method for performing two separate jobs: > >- Discover the controlling DMARC policy record for the RFC5322.From >domain in a given email message; this controlling DMARC policy will be >found at either the RFC5322.From domain, the organizational domain for > the RFC5322.From domain, or the PSD of the RFC5322.From domain. >- Determine the organizational domains for the SPF domain,and the DKIM >domain in a given email message, in order to determine whether the > domains are in relaxed alignment with the RFC5322.From domain > > As I wrote in an earlier message, we have data showing use of seven label > domains in the RFC5322.From domains; it's not a lot of data, but it's there. > > So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld, > DMARC Policy Discovery would be done by querying for these five (5) records: > >- _dmarc.a.b.c.d.e.f.tld >- _dmarc.d.e.f.tld >- _dmarc.e.f.tld >- _dmarc.f.tld >- _dmarc.tld > > Let's imagine that the Domain Owner for f.tld publishes this DMARC record: > >- v=DMARC1; p=none; psd=n; rua=mailto:f...@f.tld; > > but they allow for distributed, rather than central, administrative > control, and therefore those who manage c.d.e.f.tld publish a DMARC record > like this: > >- v=DMARC1; p=reject; psd=n; rua=mailto:f...@c.d.e.f.tld; > > Perfectly valid configurations as DMARCbis is currently written. The > plausibility of same is unknown, but because RFC 7489 didn't contemplate > organizational domains as anything other than domains one level below the > domains on the PSL, it's not likely anyone ever tried to publish a DMARC > record at c.d.e.f.tld. > > If we leave N at 5, the organizational domain and thus the intended DMARC > policy for a.b.c.d.e.f.tld won't be discovered, as it's published at > and that query will be skipped by the Tree Walk. > > My argument therefore for N=8 is to support distributed policy settings for > RFC5322.From domains with eight or more labels and therefore organizational > domains with seven or fewer labels, with 8 chosen to allow for one more > label than has been currently observed. > > I will post a separate thread about the meaning and usage of the 'n' value > for the 'psd' tag, because regardless of where we land on N for the tree > walk, I think the description of the value of 'n' for the 'psd' tag is > inadequate, a conclusion I've arrived at during the writing of this reply. I am confused. Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found either in this case. Why do we need to support something that is currently unsupported? We picked n=5 to allow the current org level record to be detected by the tree walk. It's true that the tree walk provides some additional flexibility for subordinate organizations within what we would call a DMARC org domain based on RFC 7489, but that was by no means anything we ever described as a feature or a goal. Even if some organizations have very deep DNS trees, the fact that some entity uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level of their organization will still be found. In any case, any domain, at any depth in the tree can publish their own DMARC record if they need some special thing. The value of N does not affect that at all. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Todd, can you clarify this? > > N is not concerned with maximum labels on a subdomain. We are interested > in the maximum length of an org domain used for relaxed alignment. > > If this client wants to use level 7 as an org domain and apply relaxed > alignment for 8-label domains, then N needs to be 7. If the client's > lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. > Similarly, if the7-label domain only needs strict authentication, then N=7 > is not needed. > > Has this or another client genuinely chafed at the insufficient > granularity of the old PSL? > My understanding of the Tree Walk is that in DMARCbis it is the defined method for performing two separate jobs: - Discover the controlling DMARC policy record for the RFC5322.From domain in a given email message; this controlling DMARC policy will be found at either the RFC5322.From domain, the organizational domain for the RFC5322.From domain, or the PSD of the RFC5322.From domain. - Determine the organizational domains for the SPF domain,and the DKIM domain in a given email message, in order to determine whether the domains are in relaxed alignment with the RFC5322.From domain As I wrote in an earlier message, we have data showing use of seven label domains in the RFC5322.From domains; it's not a lot of data, but it's there. So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld, DMARC Policy Discovery would be done by querying for these five (5) records: - _dmarc.a.b.c.d.e.f.tld - _dmarc.d.e.f.tld - _dmarc.e.f.tld - _dmarc.f.tld - _dmarc.tld Let's imagine that the Domain Owner for f.tld publishes this DMARC record: - v=DMARC1; p=none; psd=n; rua=mailto:f...@f.tld; but they allow for distributed, rather than central, administrative control, and therefore those who manage c.d.e.f.tld publish a DMARC record like this: - v=DMARC1; p=reject; psd=n; rua=mailto:f...@c.d.e.f.tld; Perfectly valid configurations as DMARCbis is currently written. The plausibility of same is unknown, but because RFC 7489 didn't contemplate organizational domains as anything other than domains one level below the domains on the PSL, it's not likely anyone ever tried to publish a DMARC record at c.d.e.f.tld. If we leave N at 5, the organizational domain and thus the intended DMARC policy for a.b.c.d.e.f.tld won't be discovered, as it's published at _dmarc.c.d.e.f.tld and that query will be skipped by the Tree Walk. My argument therefore for N=8 is to support distributed policy settings for RFC5322.From domains with eight or more labels and therefore organizational domains with seven or fewer labels, with 8 chosen to allow for one more label than has been currently observed. I will post a separate thread about the meaning and usage of the 'n' value for the 'psd' tag, because regardless of where we land on N for the tree walk, I think the description of the value of 'n' for the 'psd' tag is inadequate, a conclusion I've arrived at during the writing of this reply. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Tuesday, April 16, 2024 2:24:07 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >In the case of a.b.c.example.com and example.com is in the PSL, the DMARC > >records in a.b.c.example.com (if present) and example.com (otherwise) are > >consulted. The only way to get to b.c.example.com or c.example.com would > >be to add them to the PSL. These are what I meant by intermediate > >records. > > I get that but in fact there are lots of PSL records underneath .com, more > than 900 of them. > >I don't find cases where it looks like such things have been added to the > >PSL, ... > We know there aren't any in the PSL more than 5 levels deep but there > are plenty shallower than that. I have no idea how many of them are > used for mail but a lot of them look plausible. ... Yes. I think there's a clear argument for n=5. The claim is we need a bigger number. If that were true, I would expect to see longer PSL entries that are plausibly related to email. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N (choose 6)
A look at my data was helpful. Organizational alignment means that N labels match exactly. Relaxed alignment means that at least one of the names is longer than N. Those rules are easy to check on my historical data. I have examples of mismatched domains with 4 matching labels. I also have examples of exact-match domains with 5 matching labels. Strict alignment does not matter for N, because it will produce PASS on any detected policy. So my data suggests a maximum possible N of 4. My message volume is almost exclusively 2LD domains, so a 4-label match represents a partitioned organization at Org+2. This has parallels in the known private registry structure, where Private Registry clients are mostly at Registered Org +1 and sometimes at Registered Org + 2. If we choose N=6, we provide Org+2 partitioning to organizations with 4-label domains. Based on this, I don't see any reason to go higher, and limiting partitions to Org+2 seems easy to defend conceptually. (As an aside, my longest From address was 10 labels, from a spammer, and it aligned with a 3-label Mail From address.My longest Mail From addresses were from *.bnc.salesforce.com, but I stopped counting at 9 because the salesforce Mail From addresses do not align with the From address at all.) Doug Foster On Tue, Apr 16, 2024 at 12:03 AM Scott Kitterman wrote: > > > On April 16, 2024 2:36:53 AM UTC, John Levine wrote: > >It appears that Scott Kitterman said: > >>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. > >>> > >>Modulo we do need to explain why 8. Related, I think we also need to > explain why the reporting address thing is important for DMARCbis since > having an intermediate level record isn't > >>currently supported by DMARC. > > > >What do you mean by intermediate level record? Whatever the tree walk > finds is > >by definition the org domain. > > > >There are some PSL entries with one below another so it's not > unprecedented. > > That's true, although that pattern in the PSL doesn't seem very relevant > to email. > > In the case of a.b.c.example.com and example.com is in the PSL, the DMARC > records in a.b.c.example.com (if present) and example.com (otherwise) are > consulted. The only way to get to b.c.example.com or c.example.com would > be to add them to the PSL. These are what I meant by intermediate records. > > It's, of course, different for DMARCbis. There we walk up the tree, so > those get checked and as you say, the first one we find is the org domain. > > The claim, as I understand it, is that for big orgs that go deeper than 5 > levels (in fact up to 8), it is somehow critical to have different > reporting addresses (which leads to a need for org domains 6, 7, and 8 > levels deep). > > I don't find cases where it looks like such things have been added to the > PSL, so I'm skeptical that this is really critical. It might be helpful > and it might even be a good idea, but I fail to find the evidence I'd > expect to find if it were actually critical for a domain operator to be > able to do this. > > I agree that we ought to just get this done, but without a rationale for 8 > that holds water, I think we're better off deciding to stick to the number > (5) that we have an articulable rationale for. > > I'm sure it will take some time to get through the last call comments, so > I imagine that we can wait a bit for more information before deciding > without delaying the overall progress. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On April 16, 2024 2:36:53 AM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. >>> >>Modulo we do need to explain why 8. Related, I think we also need to explain >>why the reporting address thing is important for DMARCbis since having an >>intermediate level record isn't >>currently supported by DMARC. > >What do you mean by intermediate level record? Whatever the tree walk finds is >by definition the org domain. > >There are some PSL entries with one below another so it's not unprecedented. That's true, although that pattern in the PSL doesn't seem very relevant to email. In the case of a.b.c.example.com and example.com is in the PSL, the DMARC records in a.b.c.example.com (if present) and example.com (otherwise) are consulted. The only way to get to b.c.example.com or c.example.com would be to add them to the PSL. These are what I meant by intermediate records. It's, of course, different for DMARCbis. There we walk up the tree, so those get checked and as you say, the first one we find is the org domain. The claim, as I understand it, is that for big orgs that go deeper than 5 levels (in fact up to 8), it is somehow critical to have different reporting addresses (which leads to a need for org domains 6, 7, and 8 levels deep). I don't find cases where it looks like such things have been added to the PSL, so I'm skeptical that this is really critical. It might be helpful and it might even be a good idea, but I fail to find the evidence I'd expect to find if it were actually critical for a domain operator to be able to do this. I agree that we ought to just get this done, but without a rationale for 8 that holds water, I think we're better off deciding to stick to the number (5) that we have an articulable rationale for. I'm sure it will take some time to get through the last call comments, so I imagine that we can wait a bit for more information before deciding without delaying the overall progress. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
It appears that Scott Kitterman said: >>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. >> >Modulo we do need to explain why 8. Related, I think we also need to explain >why the reporting address thing is important for DMARCbis since having an >intermediate level record isn't >currently supported by DMARC. What do you mean by intermediate level record? Whatever the tree walk finds is by definition the org domain. There are some PSL entries with one below another so it's not unprecedented. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
Todd, can you clarify this? N is not concerned with maximum labels on a subdomain. We are interested in the maximum length of an org domain used for relaxed alignment. If this client wants to use level 7 as an org domain and apply relaxed alignment for 8-label domains, then N needs to be 7. If the client's lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. Similarly, if the7-label domain only needs strict authentication, then N=7 is not needed. Has this or another client genuinely chafed at the insufficient granularity of the old PSL? On Mon, Apr 15, 2024, 10:02 AM Todd Herr wrote: > On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman > wrote: > >> >> >> On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely >> wrote: >> >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: >> >> Our original choice of N was based on the PSL.The PSL could not >> detect organizational boundaries could not boundaries below level 5, >> because it had no entries longer than 5 labels, and we determined that the >> 5-label entries were not used for mail.Therefore, any increase in N is >> new capability. That new capability is probably desirable, but need not >> be limitless. Using an N of 8 introduces a lot of new capability. >> > >> > >> >8 is not needed and not justified. A mail site using 8 labels would >> have troubles with the RFC 7489 version, which uses the PSL. They'd have >> to ask for PSL upgrades, right? >> > >> >Now, we can relax our ambition to be PSL-free and state N=max number of >> labels of public suffixes used by mail. Or we could put N in an IANA >> registry that can be updated by expert review. Such methods allow to have >> N low enough, yet upgradable and equal for all (compliant) implementations. >> > >> >Otherwise we can drop the requirement that N be equal for all >> implementations, and just make it configurable. After all, it is an >> anti-abuse measure, akin to SPF lookup limit. We can also keep it fixed at >> 5 and be sure that implementations will differ anyway. >> > >> Whatever we decide, I think it needs to be specified. If N is whatever, >> you will end up with difficult to troubleshoot interoperability issues when >> various sites pick different values. >> >> I don't think we need to worry about revising it later. In general, DNS >> is getting wider (new TLDs), not deeper. >> >> > An inspection of data collected by my employer reveals the longest > observed RFC5322.From address to include seven labels in the domain part. I > am not at liberty to reveal the specific domains due to customer privacy, > but they're there. > > For a domain with seven labels, a.b.c.d.e.f.g, the Tree Walk as currently > described would miss any DMARC policy records published at b.c.d.e.f.g and > c.d.e.f.g. > > I would propose the following first draft of expository text regarding > setting N at 8: > > The point of the Tree Walk is to allow for the publishing and discovery of > DMARC policy records at any level in the DNS hierarchy that strikes a > balance between what the domain registrant deems reasonable and what > operational needs deem reasonable. The setting of N is done with an eye to > putting a thumb on the scale on the side of operational needs, to guard > against the truly silly or abusive cases with domain names with label > counts in the dozens or even triple digits. Based on an observation at the > time of publishing that RFC5322.From domains with seven labels were in > active but uncommon use, eight was chosen as the value of N in order to not > only accommodate for current usage but also to allow for a bit of future > expansion of the depth of the name space used for RFC5322.From domains. > > > > -- > > Todd Herr | Technical Director, Standards & Ecosystem > Email: todd.h...@valimail.com > Phone: 703-220-4153 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On April 15, 2024 4:34:40 PM UTC, John Levine wrote: >It appears that Alessandro Vesely said: >>8 is not needed and not justified. A mail site using 8 labels would have >>troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >>for >>PSL upgrades, right? > >No, they would not. They might ask to have their pseudo-TLDs added to >the PSL but there's a process for that and it is definitely not our >problem. > >>Now, we can relax our ambition to be PSL-free and state N=max number of >>labels >>of public suffixes used by mail. Or we could put N in an IANA registry that >>can be updated by expert review. Such methods allow to have N low enough, >>yet >>upgradable and equal for all (compliant) implementations. > >That is a great deal of complication for no benefit whatever. > >I'm with Scott, pick a number, 5, 8, whatever, and be done with it. > Modulo we do need to explain why 8. Related, I think we also need to explain why the reporting address thing is important for DMARCbis since having an intermediate level record isn't currently supported by DMARC. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
It appears that Alessandro Vesely said: >8 is not needed and not justified. A mail site using 8 labels would have >troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >for >PSL upgrades, right? No, they would not. They might ask to have their pseudo-TLDs added to the PSL but there's a process for that and it is definitely not our problem. >Now, we can relax our ambition to be PSL-free and state N=max number of labels >of public suffixes used by mail. Or we could put N in an IANA registry that >can be updated by expert review. Such methods allow to have N low enough, yet >upgradable and equal for all (compliant) implementations. That is a great deal of complication for no benefit whatever. I'm with Scott, pick a number, 5, 8, whatever, and be done with it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 7:02 AM Todd Herr wrote: > > I would propose the following first draft of expository text regarding > setting N at 8: > > The point of the Tree Walk is to allow for the publishing and discovery of > DMARC policy records at any level in the DNS hierarchy that strikes a > balance between what the domain registrant deems reasonable and what > operational needs deem reasonable. The setting of N is done with an eye to > putting a thumb on the scale on the side of operational needs, to guard > against the truly silly or abusive cases with domain names with label > counts in the dozens or even triple digits. Based on an observation at the > time of publishing that RFC5322.From domains with seven labels were in > active but uncommon use, eight was chosen as the value of N in order to not > only accommodate for current usage but also to allow for a bit of future > expansion of the depth of the name space used for RFC5322.From domains. > > If it's not already there someplace, maybe a sentence or two about the impact of higher and lower values would be helpful (e.g., lower cost/better speed vs. accuracy). -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 7:58 AM Scott Kitterman wrote: > > > On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely > wrote: > >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: > >> Our original choice of N was based on the PSL.The PSL could not > detect organizational boundaries could not boundaries below level 5, > because it had no entries longer than 5 labels, and we determined that the > 5-label entries were not used for mail.Therefore, any increase in N is > new capability. That new capability is probably desirable, but need not > be limitless. Using an N of 8 introduces a lot of new capability. > > > > > >8 is not needed and not justified. A mail site using 8 labels would have > troubles with the RFC 7489 version, which uses the PSL. They'd have to ask > for PSL upgrades, right? > > > >Now, we can relax our ambition to be PSL-free and state N=max number of > labels of public suffixes used by mail. Or we could put N in an IANA > registry that can be updated by expert review. Such methods allow to have > N low enough, yet upgradable and equal for all (compliant) implementations. > > > >Otherwise we can drop the requirement that N be equal for all > implementations, and just make it configurable. After all, it is an > anti-abuse measure, akin to SPF lookup limit. We can also keep it fixed at > 5 and be sure that implementations will differ anyway. > > > Whatever we decide, I think it needs to be specified. If N is whatever, > you will end up with difficult to troubleshoot interoperability issues when > various sites pick different values. > > I don't think we need to worry about revising it later. In general, DNS > is getting wider (new TLDs), not deeper. > > An inspection of data collected by my employer reveals the longest observed RFC5322.From address to include seven labels in the domain part. I am not at liberty to reveal the specific domains due to customer privacy, but they're there. For a domain with seven labels, a.b.c.d.e.f.g, the Tree Walk as currently described would miss any DMARC policy records published at b.c.d.e.f.g and c.d.e.f.g. I would propose the following first draft of expository text regarding setting N at 8: The point of the Tree Walk is to allow for the publishing and discovery of DMARC policy records at any level in the DNS hierarchy that strikes a balance between what the domain registrant deems reasonable and what operational needs deem reasonable. The setting of N is done with an eye to putting a thumb on the scale on the side of operational needs, to guard against the truly silly or abusive cases with domain names with label counts in the dozens or even triple digits. Based on an observation at the time of publishing that RFC5322.From domains with seven labels were in active but uncommon use, eight was chosen as the value of N in order to not only accommodate for current usage but also to allow for a bit of future expansion of the depth of the name space used for RFC5322.From domains. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 703-220-4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
We have a request for 8, however weakly documented We set N to prevent using long names as. DoS attack. I am doubtful that such attacks would appear beneficial to an attacker, but a limit is appropriate. I do not see 8 as a significant incremental performance problem, over 5, so not a DoS issue. On the other hand, we created the ability to have partitioned organizations, so equity considerations come to mind. If any org is to have ability to partition at org+2,:then rhee number should be at least 6, right? On Mon, Apr 15, 2024, 7:43 AM Alessandro Vesely wrote: > On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: > > Our original choice of N was based on the PSL.The PSL could not > detect > > organizational boundaries could not boundaries below level 5, because it > had no > > entries longer than 5 labels, and we determined that the 5-label entries > were > > not used for mail.Therefore, any increase in N is new capability. > That > > new capability is probably desirable, but need not be limitless. Using > an N of > > 8 introduces a lot of new capability. > > > 8 is not needed and not justified. A mail site using 8 labels would have > troubles with the RFC 7489 version, which uses the PSL. They'd have to > ask for > PSL upgrades, right? > > Now, we can relax our ambition to be PSL-free and state N=max number of > labels > of public suffixes used by mail. Or we could put N in an IANA registry > that > can be updated by expert review. Such methods allow to have N low enough, > yet > upgradable and equal for all (compliant) implementations. > > Otherwise we can drop the requirement that N be equal for all > implementations, > and just make it configurable. After all, it is an anti-abuse measure, > akin to > SPF lookup limit. We can also keep it fixed at 5 and be sure that > implementations will differ anyway. > > > Best > Ale > -- > > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely wrote: >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: >> Our original choice of N was based on the PSL. The PSL could not detect >> organizational boundaries could not boundaries below level 5, because it had >> no entries longer than 5 labels, and we determined that the 5-label entries >> were not used for mail. Therefore, any increase in N is new capability. >> That new capability is probably desirable, but need not be limitless. Using >> an N of 8 introduces a lot of new capability. > > >8 is not needed and not justified. A mail site using 8 labels would have >troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >for PSL upgrades, right? > >Now, we can relax our ambition to be PSL-free and state N=max number of labels >of public suffixes used by mail. Or we could put N in an IANA registry that >can be updated by expert review. Such methods allow to have N low enough, yet >upgradable and equal for all (compliant) implementations. > >Otherwise we can drop the requirement that N be equal for all implementations, >and just make it configurable. After all, it is an anti-abuse measure, akin >to SPF lookup limit. We can also keep it fixed at 5 and be sure that >implementations will differ anyway. > Whatever we decide, I think it needs to be specified. If N is whatever, you will end up with difficult to troubleshoot interoperability issues when various sites pick different values. I don't think we need to worry about revising it later. In general, DNS is getting wider (new TLDs), not deeper. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: Our original choice of N was based on the PSL. The PSL could not detect organizational boundaries could not boundaries below level 5, because it had no entries longer than 5 labels, and we determined that the 5-label entries were not used for mail. Therefore, any increase in N is new capability. That new capability is probably desirable, but need not be limitless. Using an N of 8 introduces a lot of new capability. 8 is not needed and not justified. A mail site using 8 labels would have troubles with the RFC 7489 version, which uses the PSL. They'd have to ask for PSL upgrades, right? Now, we can relax our ambition to be PSL-free and state N=max number of labels of public suffixes used by mail. Or we could put N in an IANA registry that can be updated by expert review. Such methods allow to have N low enough, yet upgradable and equal for all (compliant) implementations. Otherwise we can drop the requirement that N be equal for all implementations, and just make it configurable. After all, it is an anti-abuse measure, akin to SPF lookup limit. We can also keep it fixed at 5 and be sure that implementations will differ anyway. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
Our original choice of N was based on the PSL.The PSL could not detect organizational boundaries could not boundaries below level 5, because it had no entries longer than 5 labels, and we determined that the 5-label entries were not used for mail.Therefore, any increase in N is new capability. That new capability is probably desirable, but need not be limitless. Using an N of 8 introduces a lot of new capability. As the number of labels increases, the probability of abuse increases -- either malicious use of non-existent subdomains, or malicious creation of meaningless subdomains. This provides strong incentive to limit N to a small number. I don't have any objection to 8. There are two defenses available to evaluators who fear malicious use of maximum N: - Test for From domain existence first. If the domain does not exist, do a top-down search for the first domain that does exist. Mail From and DKIM domains do not need to be tested separately for existence, as they cannot verify unless the domain exists. - Use result caching so that domains with a high number of labels are not researched multiple times. DF On Sun, Apr 14, 2024 at 7:23 PM Murray S. Kucherawy wrote: > On Sun, Apr 7, 2024 at 10:33 AM Scott Kitterman > wrote: > >> >Seth says there are people who need N=8 but for business reasons he >> can't tell us who they are. I'm not thrilled about that but I see little >> downside to bumping the number up to 8. >> >> I expect that's where we end up, but I think we need something more than >> one of the chairs said there are secret reasons. >> > > I agree, "Why 8?" is a very reasonable question for any reviewer to ask. > > -MSK, p11g > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
