Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Mon 01/Aug/2022 21:15:36 +0200 John Levine wrote: It appears that Alessandro Vesely said: You could make the argument that you "usually" find DMARC records at zone cuts, but that's relying on convention or happenstance rather than a standards-quality framework. I'd agree, except that our definition of Organizational Domain as one label beyond a PSD (PSD+1) poses a semantic limit on that. Sorry, but this is beyond wrong. A) Org domains are defined by what is in the draft, and that is not what the draft says. Some org domains will found below a PSD, most won't since most PSDs do not and will not publish DMARC records. Oops, you're right. The PSD+1 sentence was removed in version -13. B) PSDs have nothing to do with zone cuts. Some are at zone cuts, some are not. For example, .uk .co.uk and .org.uk are all in the PSL, and they are all in the same zone. But those are PSDs, not org domains... While we concentrate on existing scenarios, it may well happen that, if DMARC algorithm sees widespread adoption, people will define organizational boundaries that way, irrespective of actual DNS control, as in your example. You appear to be saying that people will ignore the spec and do something else because they somehow imagine that we didn't mean what we said and really meant something else. Aw, come on. Eh? I don't know how you could extrapolate that meaning from what I said. I didn't say people will ignore the spec. I said "if DMARC algorithm sees widespread adoption" because that is what can make the spec come true. In that case, I said, "define organizational boundaries that way" can become a practice. "That way" refers to the way Murray exemplified, what else?. That is, following the spec. The "while we concentrate on existing scenarios" was meant to criticize our dismissing arguments because no case currently exist that matches. For example, we fix the max depth at 5. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
It appears that Alessandro Vesely said: >> You could make the argument that you "usually" find DMARC records at zone >> cuts, but that's relying on convention or happenstance rather than a >> standards-quality framework. > >I'd agree, except that our definition of Organizational Domain as one >label beyond a PSD (PSD+1) poses a semantic limit on that. Sorry, but this is beyond wrong. A) Org domains are defined by what is in the draft, and that is not what the draft says. Some org domains will found below a PSD, most won't since most PSDs do not and will not publish DMARC records. B) PSDs have nothing to do with zone cuts. Some are at zone cuts, some are not. For example, .uk .co.uk and .org.uk are all in the PSL, and they are all in the same zone. >While we concentrate on existing scenarios, it may well happen that, >if DMARC algorithm sees widespread adoption, people will define >organizational boundaries that way, irrespective of actual DNS >control, as in your example. You appear to be saying that people will ignore the spec and do something else because they somehow imagine that we didn't mean what we said and really meant something else. Aw, come on. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Mon 01/Aug/2022 00:12:45 +0200 Murray S. Kucherawy wrote: On Sat, Jul 30, 2022 at 4:29 AM Alessandro Vesely wrote: On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote: It appears that Alessandro Vesely said: In general, it is not possible to determine DNS zone cuts by querying various subdomains. However, DMARC users define DMARC records at their Organizational Domain, so it is possible to discover them based on that. Sorry, but this is just wrong. DMARC and the tree walk have nothing, and I emphasize nothing, to do with zone cuts. I thought a zone cut marked the boundary where an organization delegates control to another one. In many cases, that would be the org domain, no? Assume you have this zone file for "example.com": example.com. IN NS ... IN NS ... _dmarc.marketing IN TXT ... product.marketing IN TXT [SPF record here] Now I send mail using the domain "product.marketing.example.com." It has an SPF record, but no DMARC record. If we do the tree walk up one to " marketing.example.com" and then prepend "_dmarc", we find a record. But note that there are no NS records here, and hence no zone cut. There is, however, a zone cut at "example.com" itself (naturally, since that's where the registration occurs). So this is an example of a DMARC record not coincident with a zone cut, plus a zone cut with no coincident DMARC record. There is, therefore, no guaranteed relationship. Yes. You could make the argument that you "usually" find DMARC records at zone cuts, but that's relying on convention or happenstance rather than a standards-quality framework. I'd agree, except that our definition of Organizational Domain as one label beyond a PSD (PSD+1) poses a semantic limit on that. While we concentrate on existing scenarios, it may well happen that, if DMARC algorithm sees widespread adoption, people will define organizational boundaries that way, irrespective of actual DNS control, as in your example. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Sun, 31 Jul 2022, Murray S. Kucherawy wrote: You could make the argument that you "usually" find DMARC records at zone cuts, but that's relying on convention or happenstance rather than a standards-quality framework. Right, we went through all of this in the failed DBOUND discussion. If it were true, which it is not, that zone cuts always indicate different management, and that every change of mangagement has a zone cut, we would not be having this discussion because it is trivial to find the zone cuts. But since it is not, we have to do it other ways like the PSL for web cookies and the tree walk for DMARC. I have to say I am somewhat concerned that people are trying to design the way DMARC uses the DNS but do not appear to understand some fairly basic things about the way the DNS works. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Sat, Jul 30, 2022 at 4:29 AM Alessandro Vesely wrote: > On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote: > > It appears that Alessandro Vesely said: > >> In general, it is not possible to determine DNS zone cuts by > querying > >> various subdomains. However, DMARC users define DMARC records at > their > >> Organizational Domain, so it is possible to discover them based on > that. > > > > Sorry, but this is just wrong. DMARC and the tree walk have nothing, > and I emphasize > > nothing, to do with zone cuts. > > > I thought a zone cut marked the boundary where an organization > delegates control to another one. In many cases, that would be the > org domain, no? > Assume you have this zone file for "example.com": example.com. IN NS ... IN NS ... _dmarc.marketing IN TXT ... product.marketing IN TXT [SPF record here] Now I send mail using the domain "product.marketing.example.com." It has an SPF record, but no DMARC record. If we do the tree walk up one to " marketing.example.com" and then prepend "_dmarc", we find a record. But note that there are no NS records here, and hence no zone cut. There is, however, a zone cut at "example.com" itself (naturally, since that's where the registration occurs). So this is an example of a DMARC record not coincident with a zone cut, plus a zone cut with no coincident DMARC record. There is, therefore, no guaranteed relationship. You could make the argument that you "usually" find DMARC records at zone cuts, but that's relying on convention or happenstance rather than a standards-quality framework. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Fri 29/Jul/2022 19:44:28 +0200 John Levine wrote: It appears that Alessandro Vesely said: In general, it is not possible to determine DNS zone cuts by querying various subdomains. However, DMARC users define DMARC records at their Organizational Domain, so it is possible to discover them based on that. Sorry, but this is just wrong. DMARC and the tree walk have nothing, and I emphasize nothing, to do with zone cuts. I thought a zone cut marked the boundary where an organization delegates control to another one. In many cases, that would be the org domain, no? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
It appears that Alessandro Vesely said: > In general, it is not possible to determine DNS zone cuts by querying > various subdomains. However, DMARC users define DMARC records at their > Organizational Domain, so it is possible to discover them based on that. Sorry, but this is just wrong. DMARC and the tree walk have nothing, and I emphasize nothing, to do with zone cuts. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu 28/Jul/2022 20:19:36 +0200 Scott Kitterman wrote: On July 28, 2022 3:26:45 PM UTC, Todd Herr wrote: On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy wrote: A couple of tweaks to suggest, edited in-place: On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman wrote: For Organizational Domain discovery, it will be necessary to perform one or more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in alignment. This means that each DNS Tree Walk to discover an Organizational Domain will start at one of the following locations: * The domain in the RFC5322.From header field of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain for which there is a DKIM pass result on the message. To determine the Organizational Domain for any of these domains, perform the DNS Tree Walk as needed the selected domain. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: I just corrected a couple of typos, changed "header" to "header field", and accounted for the fact that a message might have multiple signatures in varying result combinations. It's not clear to me from the thread whether or not the Note parts (see below) should be kept, and if so where they should be located (end of section 4.8?) Note: There is no need to perform Tree Walk searches for Organizational Domains under any of the following conditions: <#section-4.8-3> - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated), are all the same and that domain has a DMARC record. In this case, this common domain is treated as the Organizational Domain. <#section-4.8-4.1> - No applicable DMARC policy is discovered for the RFC5322.From domain during the tree walk for that domain. In this case, the DMARC mechanism does not apply to the message in question. <#section-4.8-4.2> - The record for the RFC5322.From domain indicates strict alignment. In this case, a simple string compare between the RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated) is all that is required. My view is kept and moved to the end of the section. I actually prefer it where it is, but in the interest of moving forward, I can live with it at the end. It is a question of taste. On the opposite, it is possible to specify the org domain without referencing alignment, like so, say: In general, it is not possible to determine DNS zone cuts by querying various subdomains. However, DMARC users define DMARC records at their Organizational Domain, so it is possible to discover them based on that. Given a DNS Tree Walk (#dns-tree-walk) which retrieved at least one DMARC record, determine the Organizational Domain by applying the following rules, from the longest domain toward the shortest one: 1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n), this is the Organizational Domain and the selection process is complete. 2. If a valid DMARC record, other than the one for the domain where the tree walk started, contains the psd= tag set to 'y' (psd=y), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete. 3. Otherwise select the record for the domain with the fewest number of labels. This is the Organizational Domain and the selection process is complete. Clean, precise, foolproof, isn't it? After that we can discuss when it is necessary to do discover the org domain, etcetera. One thing at a time. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 9:10:06 PM UTC, Alessandro Vesely wrote: >On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote: >>>If this process does not determine the Organizational Domain, then >>>the Organizational Domain is the starting domain. >>> >>> >>> The last paragraph is a puzzle. If a tree walk retrieved a DMARC record, >>> then there must exist a domain with a record with the fewest number of >>> labels. It is not needed any more. Let's replace it with: >>> >>> >>>For Tree Walks that retrieved no DMARC record, the Organizational Domain >>> is >>>undefined. No alignment can be established in such cases. >>> >> No. That's incorrect. We have discussed this exact point multiple times in >> the last several weeks. I conclude that I'm incapable of communicating this >> adequately and will leave it to someone else. > > >Yes, I remember the discussions, and some example cases where it happened. >Yet, reading again step 3: > > 3. Otherwise select the record for the domain with the fewest number > of labels. This is the Organizational Domain and the selection > process is complete. > >How can it possibly happen, in real or imaginary cases, that the org domain is >not selected after this step? > >The examples were something like psd.example.com, whose record with psd=y was >discarded on step 2. If example.com and com have no records, the record for >the domain with the fewest number of labels is still psd.example.com, so the >process concludes by step 3. > >I don't recall other examples, except the invalid ones, like .com, which I >imagined before getting that having retrieved a DMARC record was a requirement >for the input tree walk. Okay. I see what you are saying and I think it's correct, but I think it's still a good idea to keep it there to cover anything we didn't think of. I could live with removing it if that's the group's preference. This was more clearly needed before "other than the one for the domain where the tree walk started" was added in -11. I think that addressed the specific use case I had in mind. My apologies for letting my personal frustrations over the pace of the work spill over on you. Thank you for taking another shot at it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu 28/Jul/2022 20:24:35 +0200 Scott Kitterman wrote: If this process does not determine the Organizational Domain, then the Organizational Domain is the starting domain. The last paragraph is a puzzle. If a tree walk retrieved a DMARC record, then there must exist a domain with a record with the fewest number of labels. It is not needed any more. Let's replace it with: For Tree Walks that retrieved no DMARC record, the Organizational Domain is undefined. No alignment can be established in such cases. No. That's incorrect. We have discussed this exact point multiple times in the last several weeks. I conclude that I'm incapable of communicating this adequately and will leave it to someone else. Yes, I remember the discussions, and some example cases where it happened. Yet, reading again step 3: 3. Otherwise select the record for the domain with the fewest number of labels. This is the Organizational Domain and the selection process is complete. How can it possibly happen, in real or imaginary cases, that the org domain is not selected after this step? The examples were something like psd.example.com, whose record with psd=y was discarded on step 2. If example.com and com have no records, the record for the domain with the fewest number of labels is still psd.example.com, so the process concludes by step 3. I don't recall other examples, except the invalid ones, like .com, which I imagined before getting that having retrieved a DMARC record was a requirement for the input tree walk. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 4:03:12 PM UTC, Alessandro Vesely wrote: >On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote: >> On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: >>> On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: >> ... >> Here's what's currently in Git between the shortcuts and the numbered steps (it's in Markdown, vice final RFC text, but I think it's clear enough): > To discover the Organizational Domain for a domain, perform the DNS Tree > Walk described in (#dns-tree-walk) as needed for any of the domains in > question. >>> >>> What are the "domains in question"? >>> > For each Tree Walk that retrieved valid DMARC records, select the > Organizational Domain from the domains for which valid DMARC records were > retrieved from the longest to the shortest: If we change this to: > To discover the Organizational Domain for these domains, perform the DNS > Tree Walk described in (#dns-tree-walk) as needed for the domains in > question. For each Tree Walk that retrieved valid DMARC records, select > the Organizational Domain from the domains for which valid DMARC records > were retrieved from the longest to the shortest: Does that resolve your concern? I changed "for a domain" to "for these domains" to address your concern about relaxing requirements. I think you're wrong and it makes absolutely no difference, but if you think it's better, believe it would do. I do think the two sentences would better be in one paragraph as they are not really separate ideas. >>> >>> How about moving the reference to the Tree Walk right to the first >>> sentence at the beginning of the section, for example like so: >>> >>> >>> For Organizational Domain discovery, in general it is necessary to >>> perform two DNS Tree Walks (#dns-tree-walk)" in order to determine >>> if any two domains are in alignment. Noteworthy exceptions are >>> described in (#shortcuts). A DNS Tree Walk to discover an >>> Organizational Domain can start only at one of the following >>> locations: >>> >>> * The domain in the RFC5322.From header of the message. >>> * The RFC5321.MailFrom domain if there is an SPF pass result for >>>the message. >>> * Any DKIM d= domain if there is a DKIM pass result for the >>>message for that domain. >>> >>> For each Tree Walk that retrieved valid DMARC records, select the >>> Organizational Domain from the domains for which valid DMARC >>> records were retrieved from the longest to the shortest: >>> >>> 1 ... >> >> Let's focus on this part, as I think it's most important. >> >> In general, I think that's reasonable, but I think it needs work yet. How >> about this (and I'm fine with moving the note to the end): >> >>> For Organizational Domain discovery, it will be necessary to perform one or >>> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in >>> alignment. This means that a DNS Tree Walk to discover an Organizational >>> Domain will start at one of the following locations: > > >We are trying to stuff two sentences in one. It is not clear if we're >discovering the org domain or establishing alignment. > > >>> * The domain in the RFC5322.From header of the message. >>> * The RFC5321.MailFrom domain if there is an SPF pass result for the >>> message. >>> * Any DKIM d= domain if there is a DKIM pass result for the message for >>> that domain. >> >>> To determine the Organizational Domain for any of these domains, perform the >>> DNS Tree Walk as needed the selected domain. > > >Splitting the first sentence, this becomes one of its parts. > > >>> For each Tree Walk that >>> retrieved valid DMARC records, select the Organizational Domain from the >>> domains for which valid DMARC records were retrieved from the longest to the >>> shortest: > > >Could that be shortened? Each step requires a DMARC record, so the domains >w/o record don't play. > >Here's another wording. I repeat the numbered steps but only change the >paragraph after them: > > >To discover the Organizational Domain of a domain, it is necessary to >analyze the DNS Tree Walk (#dns-tree-walk)" which starts from it. That may >be necessary in order to establish alignment between two domains. This >means that the starting domain is one of the following: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for >the message. > * Any DKIM d= domain if there is a DKIM pass result for the >message for that domain. > >For a Tree Walk that retrieved a valid DMARC record, select the >Organizational Domain from its domains, from the longest toward the >shortest: > > 1. If a valid
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 28, 2022 3:26:45 PM UTC, Todd Herr wrote: >On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy >wrote: > >> A couple of tweaks to suggest, edited in-place: >> >> On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman >> wrote: >> >>> For Organizational Domain discovery, it will be necessary to perform one >>> or >>> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are >>> in >>> alignment. This means that each DNS Tree Walk to discover an >>> Organizational >>> Domain will start at one of the following locations: >>> >>> > * The domain in the RFC5322.From header field of the message. >>> > * The RFC5321.MailFrom domain if there is an SPF pass result for the >>> > message. >>> > * Any DKIM d= domain for which there is a DKIM pass result on the >>> message. >>> >>> > To determine the Organizational Domain for any of these domains, >>> perform the >>> > DNS Tree Walk as needed the selected domain. For each Tree Walk that >>> > retrieved valid DMARC records, select the Organizational Domain from the >>> > domains for which valid DMARC records were retrieved from the longest >>> to the >>> > shortest: >>> >> >> I just corrected a couple of typos, changed "header" to "header field", >> and accounted for the fact that a message might have multiple signatures in >> varying result combinations. >> >> >It's not clear to me from the thread whether or not the Note parts (see >below) should be kept, and if so where they should be located (end of >section 4.8?) > >Note: There is no need to perform Tree Walk searches for Organizational >Domains under any of the following conditions: <#section-4.8-3> > > - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF > authenticated), and/or the DKIM d= domain (if present and authenticated), > are all the same and that domain has a DMARC record. In this case, this > common domain is treated as the Organizational Domain. <#section-4.8-4.1> > - No applicable DMARC policy is discovered for the RFC5322.From domain > during the tree walk for that domain. In this case, the DMARC mechanism > does not apply to the message in question. <#section-4.8-4.2> > - The record for the RFC5322.From domain indicates strict alignment. In > this case, a simple string compare between the RFC5322.From domain and the > RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain > (if present and authenticated) is all that is required. > My view is kept and moved to the end of the section. I actually prefer it where it is, but in the interest of moving forward, I can live with it at the end. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu 28/Jul/2022 13:23:45 +0200 Scott Kitterman wrote: On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: ... Here's what's currently in Git between the shortcuts and the numbered steps (it's in Markdown, vice final RFC text, but I think it's clear enough): To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in (#dns-tree-walk) as needed for any of the domains in question. What are the "domains in question"? For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: If we change this to: To discover the Organizational Domain for these domains, perform the DNS Tree Walk described in (#dns-tree-walk) as needed for the domains in question. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: Does that resolve your concern? I changed "for a domain" to "for these domains" to address your concern about relaxing requirements. I think you're wrong and it makes absolutely no difference, but if you think it's better, believe it would do. I do think the two sentences would better be in one paragraph as they are not really separate ideas. How about moving the reference to the Tree Walk right to the first sentence at the beginning of the section, for example like so: For Organizational Domain discovery, in general it is necessary to perform two DNS Tree Walks (#dns-tree-walk)" in order to determine if any two domains are in alignment. Noteworthy exceptions are described in (#shortcuts). A DNS Tree Walk to discover an Organizational Domain can start only at one of the following locations: * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: 1 ... Let's focus on this part, as I think it's most important. In general, I think that's reasonable, but I think it needs work yet. How about this (and I'm fine with moving the note to the end): For Organizational Domain discovery, it will be necessary to perform one or more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in alignment. This means that a DNS Tree Walk to discover an Organizational Domain will start at one of the following locations: We are trying to stuff two sentences in one. It is not clear if we're discovering the org domain or establishing alignment. * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. To determine the Organizational Domain for any of these domains, perform the DNS Tree Walk as needed the selected domain. Splitting the first sentence, this becomes one of its parts. For each Tree Walk that retrieved valid DMARC records, select the Organizational Domain from the domains for which valid DMARC records were retrieved from the longest to the shortest: Could that be shortened? Each step requires a DMARC record, so the domains w/o record don't play. Here's another wording. I repeat the numbered steps but only change the paragraph after them: To discover the Organizational Domain of a domain, it is necessary to analyze the DNS Tree Walk (#dns-tree-walk)" which starts from it. That may be necessary in order to establish alignment between two domains. This means that the starting domain is one of the following: * The domain in the RFC5322.From header of the message. * The RFC5321.MailFrom domain if there is an SPF pass result for the message. * Any DKIM d= domain if there is a DKIM pass result for the message for that domain. For a Tree Walk that retrieved a valid DMARC record, select the Organizational Domain from its domains, from the longest toward the shortest: 1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n), this is the Organizational Domain and the selection process is complete. 2. If a valid DMARC record, other than the one for the domain where the tree walk started, contains the psd= tag set to 'y' (psd=y), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Thu, Jul 28, 2022 at 10:49 AM Murray S. Kucherawy wrote: > A couple of tweaks to suggest, edited in-place: > > On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman > wrote: > >> For Organizational Domain discovery, it will be necessary to perform one >> or >> more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are >> in >> alignment. This means that each DNS Tree Walk to discover an >> Organizational >> Domain will start at one of the following locations: >> >> > * The domain in the RFC5322.From header field of the message. >> > * The RFC5321.MailFrom domain if there is an SPF pass result for the >> > message. >> > * Any DKIM d= domain for which there is a DKIM pass result on the >> message. >> >> > To determine the Organizational Domain for any of these domains, >> perform the >> > DNS Tree Walk as needed the selected domain. For each Tree Walk that >> > retrieved valid DMARC records, select the Organizational Domain from the >> > domains for which valid DMARC records were retrieved from the longest >> to the >> > shortest: >> > > I just corrected a couple of typos, changed "header" to "header field", > and accounted for the fact that a message might have multiple signatures in > varying result combinations. > > It's not clear to me from the thread whether or not the Note parts (see below) should be kept, and if so where they should be located (end of section 4.8?) Note: There is no need to perform Tree Walk searches for Organizational Domains under any of the following conditions: <#section-4.8-3> - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated), are all the same and that domain has a DMARC record. In this case, this common domain is treated as the Organizational Domain. <#section-4.8-4.1> - No applicable DMARC policy is discovered for the RFC5322.From domain during the tree walk for that domain. In this case, the DMARC mechanism does not apply to the message in question. <#section-4.8-4.2> - The record for the RFC5322.From domain indicates strict alignment. In this case, a simple string compare between the RFC5322.From domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain (if present and authenticated) is all that is required. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 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] Shortcuts: parent-child allows shorter tree walks
A couple of tweaks to suggest, edited in-place: On Thu, Jul 28, 2022 at 7:24 AM Scott Kitterman wrote: > For Organizational Domain discovery, it will be necessary to perform one > or > more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are > in > alignment. This means that each DNS Tree Walk to discover an > Organizational > Domain will start at one of the following locations: > > > * The domain in the RFC5322.From header field of the message. > > * The RFC5321.MailFrom domain if there is an SPF pass result for the > > message. > > * Any DKIM d= domain for which there is a DKIM pass result on the > message. > > > To determine the Organizational Domain for any of these domains, perform > the > > DNS Tree Walk as needed the selected domain. For each Tree Walk that > > retrieved valid DMARC records, select the Organizational Domain from the > > domains for which valid DMARC records were retrieved from the longest to > the > > shortest: > I just corrected a couple of typos, changed "header" to "header field", and accounted for the fact that a message might have multiple signatures in varying result combinations. -MSK -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Wednesday, July 27, 2022 4:05:27 AM EDT Alessandro Vesely wrote: > On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: > > On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: ... > > Here's what's currently in Git between the shortcuts and the numbered > > steps > > > > (it's in Markdown, vice final RFC text, but I think it's clear enough): > >> To discover the Organizational Domain for a domain, perform the DNS Tree > >> Walk described in (#dns-tree-walk) as needed for any of the domains in > >> question. > > What are the "domains in question"? > > >> For each Tree Walk that retrieved valid DMARC records, select the > >> Organizational Domain from the domains for which valid DMARC records were > > > >> retrieved from the longest to the shortest: > > If we change this to: > >> To discover the Organizational Domain for these domains, perform the DNS > >> Tree Walk described in (#dns-tree-walk) as needed for the domains in > >> question. For each Tree Walk that retrieved valid DMARC records, select > >> the Organizational Domain from the domains for which valid DMARC records > >> were> > >> retrieved from the longest to the shortest: > > Does that resolve your concern? I changed "for a domain" to "for these > > domains" to address your concern about relaxing requirements. I think > > you're wrong and it makes absolutely no difference, but if you think it's > > better, believe it would do. I do think the two sentences would better > > be in one paragraph as they are not really separate ideas. > > How about moving the reference to the Tree Walk right to the first > sentence at the beginning of the section, for example like so: > > > For Organizational Domain discovery, in general it is necessary to > perform two DNS Tree Walks (#dns-tree-walk)" in order to determine > if any two domains are in alignment. Noteworthy exceptions are > described in (#shortcuts). A DNS Tree Walk to discover an > Organizational Domain can start only at one of the following > locations: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for >the message. > * Any DKIM d= domain if there is a DKIM pass result for the >message for that domain. > > For each Tree Walk that retrieved valid DMARC records, select the > Organizational Domain from the domains for which valid DMARC > records were retrieved from the longest to the shortest: > > 1 ... Let's focus on this part, as I think it's most important. In general, I think that's reasonable, but I think it needs work yet. How about this (and I'm fine with moving the note to the end): > For Organizational Domain discovery, it will be necessary to perform one or more DNS Tree Walks (#dns-tree-walk) to determine if any two domains are in alignment. This means that a DNS Tree Walk to discover an Organizational Domain will start at once of the following locations: > > * The domain in the RFC5322.From header of the message. > * The RFC5321.MailFrom domain if there is an SPF pass result for the > message. > * Any DKIM d= domain if there is a DKIM pass result for the message for > that domain. > To determine the Organizational Domain for any of thes domains, perform the > DNS Tree Walk as needed the selected domain. For each Tree Walk that > retrieved valid DMARC records, select the Organizational Domain from the > domains for which valid DMARC records were retrieved from the longest to the > shortest: > > 1. If a Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Mon 25/Jul/2022 17:15:34 +0200 Scott Kitterman wrote: On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote: On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote: On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: As I would hope everyone in this discussion would be aware, the "as if" rule applies to all IETF standards. You can do whatever you want so long as the result is the same as if you had done what the spec says. The "as if" rule also holds for the case that all domains are equal, the case that no policy record is found, and the case that all alignments are strict. Shortcuts have been part of the draft at least since April, and their presence seems to be accepted by the WG. I don't understand why those shortcuts deserve being mentioned while the parent-child does not. I think you're proposal is somewhat different than the existing shortcuts. The existing items in the note are cases where the tree walk can be skipped entirely. Your suggested addition is about a shortcut within the tree walk algorithm. I think that makes it sufficiently different to merit independent consideration. They're all shortcuts. In the case I presented there is only a query to _dmarc.signing.dept.example.com (NXDOMAIN). In the second of the three ones there is a first tree walk that yields no record. That sounds similar to me. I agree that there is some similarity, but I think that they are distinct. I think someone needs to apply judgement on how far to go. I'm comfortable with where the draft authors have decided enough is enough, but I understand opinions may differ. Thanks. In addition, presenting the shortcuts in the middle of the algorithm specification can alter its meaning. See below. I disagree. They're marked as part of a note, so are not part of the specification. This is a reasonably common thing to do in IETF RFCs. The note is not fully indented. It disrupts the text enough to make it necessary to add the paragraph that immediately follows it. The added paragraph is way too generic than needed. In general, there is no reason to specify exceptions before rules. I'm happy to accept the draft authors judgement on this, either way, both regarding the location and the indenting. I understand the (ed) mark that Todd and John added after their names is meant to hold the WG responsible for the text. Feeling responsible, and having been caught by the wrong meaning of that paragraph, I want it to be amended. I do agree it might be better to make it more visually distinct, but I think we have lots of time for polishing the document and it's a detail that shouldn't block the question of if we're agreed on the tree walk as our approach. I'm not trying to take back the WG decision. IIRC, the decision was made at the meeting. There is no question on that. The point is to express it clearly. Is the "added paragraph" you're referring to this: To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in Section 4.6 as needed for any of the domains in question. If so, I disagree. I think that the section on org domain determination needs to point to 4.6 regardless of if the notes are where they are or elsewhere. The text is changed slightly for the next revision in Git, but either way I think it's needed. Yes, that's the paragraph. I agree a reference to the Tree walk is needed. Indeed, the section starts with this sentence: For Organizational Domain discovery, it may be necessary to perform multiple DNS Tree Walks in order to determine if any two domains are in alignment. So, the only added info of the questioned paragraph is "4.6". As I have repeatedly asked, if you think there are places where the tree walk results are wrong, show us some examples. Otherwise, please stop. Here you are: I hope you agree that .com is a domain. The spec says that in order to discover the Organizational Domain for a domain, I can perform the DNS Tree Walk as needed for any of the domains in question. That way, the domain in question, .com, is the Organizational Domain of itself. That is wrong because .com is a PSD. Oh, perhaps "in question" refers to the three cases mentioned in the Section's intro? It doesn't say so, it says a tree walk "might start" there, without excluding other possibilities. "In question" can legitimately be understood to refer to any domain at hand. Furthermore, the parenthesized reinforcement "if present and authenticated" in a domain in the first shortcut casts a shadow on the requirement that all identifiers except From: must be authenticated —if that requirement were clear, there'd be no need to reinforce it. This corroborates the wrong interpretation. First, if .com had a DMARC record and .com sent mail, it could be both a PSD for lower level domains and it's own
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Monday, July 25, 2022 9:59:02 AM EDT Alessandro Vesely wrote: > On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote: > > On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote: > >> On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: > >>> As I would hope everyone in this discussion would be aware, the "as if" > >>> rule applies to all IETF standards. You can do whatever you want so > >>> long as the result is the same as if you had done what the spec says. > >> > >> The "as if" rule also holds for the case that all domains are equal, the > >> case that no policy record is found, and the case that all alignments > >> are strict. Shortcuts have been part of the draft at least since April, > >> and their presence seems to be accepted by the WG. > >> > >> I don't understand why those shortcuts deserve being mentioned while the > >> parent-child does not. >> > > > I think you're proposal is somewhat different than the existing shortcuts. > > The existing items in the note are cases where the tree walk can be > > skipped entirely. Your suggested addition is about a shortcut within the > > tree walk algorithm. I think that makes it sufficiently different to > > merit independent consideration. > They're all shortcuts. In the case I presented there is only a query to > _dmarc.signing.dept.example.com (NXDOMAIN). In the second of the three > ones there is a first tree walk that yields no record. That sounds similar > to me. I agree that there is some similarity, but I think that they are distinct. I think someone needs to apply judgement on how far to go. I'm comfortable with where the draft authors have decided enough is enough, but I understand opinions may differ. > >> In addition, presenting the shortcuts in the middle of the algorithm > >> specification can alter its meaning. See below.> > > I disagree. They're marked as part of a note, so are not part of the > > specification. This is a reasonably common thing to do in IETF RFCs. > The note is not fully indented. It disrupts the text enough to make it > necessary to add the paragraph that immediately follows it. The added > paragraph is way too generic than needed. > > In general, there is no reason to specify exceptions before rules. I'm happy to accept the draft authors judgement on this, either way, both regarding the location and the indenting. I do agree it might be better to make it more visually distinct, but I think we have lots of time for polishing the document and it's a detail that shouldn't block the question of if we're agreed on the tree walk as our approach. Is the "added paragraph" you're referring to this: >To discover the Organizational Domain for a domain, perform the DNS >Tree Walk described in Section 4.6 as needed for any of the domains >in question. If so, I disagree. I think that the section on org domain determination needs to point to 4.6 regardless of if the notes are where they are or elsewhere. The text is changed slightly for the next revision in Git, but either way I think it's needed. > >>> As I have repeatedly asked, if you think there are places where the > >>> tree walk results are wrong, show us some examples. Otherwise, please > >>> stop. > >> > >> Here you are: > >> > >> I hope you agree that .com is a domain. The spec says that in order to > >> discover the Organizational Domain for a domain, I can perform the DNS > >> Tree Walk as needed for any of the domains in question. That way, the > >> domain in question, .com, is the Organizational Domain of itself. That > >> is wrong because .com is a PSD. > >> > >> Oh, perhaps "in question" refers to the three cases mentioned in the > >> Section's intro? It doesn't say so, it says a tree walk "might start" > >> there, without excluding other possibilities. "In question" can > >> legitimately be understood to refer to any domain at hand. > >> > >> Furthermore, the parenthesized reinforcement "if present and > >> authenticated" in a domain in the first shortcut casts a shadow on the > >> requirement that all identifiers except From: must be authenticated —if > >> that requirement were clear, there'd be no need to reinforce it. This > >> corroborates the wrong interpretation. >> > > > First, if .com had a DMARC record and .com sent mail, it could be both a > > PSD for lower level domains and it's own organizational domain for > > itself, so your conclusion is incorrect. We have discussed this multiple > > times. I think we most recently used .gov.uk as a more realistic > > example. > No, I'm not hypothesizing that .com had a record and passed the requirements > stated (somewhat unclearly) right at the beginning of section 4.8. I'm > pointing out that the paragraph after the note relaxes those requirements. > Indeed, it says that the algorithm is valid for any domain. I fear that I'm understanding you less as a result of this email, not more. In an email earlier today you said: > Therefore, a
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote: On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote: On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: As I would hope everyone in this discussion would be aware, the "as if" rule applies to all IETF standards. You can do whatever you want so long as the result is the same as if you had done what the spec says. The "as if" rule also holds for the case that all domains are equal, the case that no policy record is found, and the case that all alignments are strict. Shortcuts have been part of the draft at least since April, and their presence seems to be accepted by the WG. I don't understand why those shortcuts deserve being mentioned while the parent-child does not. I think you're proposal is somewhat different than the existing shortcuts. The existing items in the note are cases where the tree walk can be skipped entirely. Your suggested addition is about a shortcut within the tree walk algorithm. I think that makes it sufficiently different to merit independent consideration. They're all shortcuts. In the case I presented there is only a query to _dmarc.signing.dept.example.com (NXDOMAIN). In the second of the three ones there is a first tree walk that yields no record. That sounds similar to me. In addition, presenting the shortcuts in the middle of the algorithm specification can alter its meaning. See below. I disagree. They're marked as part of a note, so are not part of the specification. This is a reasonably common thing to do in IETF RFCs. The note is not fully indented. It disrupts the text enough to make it necessary to add the paragraph that immediately follows it. The added paragraph is way too generic than needed. In general, there is no reason to specify exceptions before rules. As I have repeatedly asked, if you think there are places where the tree walk results are wrong, show us some examples. Otherwise, please stop. Here you are: I hope you agree that .com is a domain. The spec says that in order to discover the Organizational Domain for a domain, I can perform the DNS Tree Walk as needed for any of the domains in question. That way, the domain in question, .com, is the Organizational Domain of itself. That is wrong because .com is a PSD. Oh, perhaps "in question" refers to the three cases mentioned in the Section's intro? It doesn't say so, it says a tree walk "might start" there, without excluding other possibilities. "In question" can legitimately be understood to refer to any domain at hand. Furthermore, the parenthesized reinforcement "if present and authenticated" in a domain in the first shortcut casts a shadow on the requirement that all identifiers except From: must be authenticated —if that requirement were clear, there'd be no need to reinforce it. This corroborates the wrong interpretation. First, if .com had a DMARC record and .com sent mail, it could be both a PSD for lower level domains and it's own organizational domain for itself, so your conclusion is incorrect. We have discussed this multiple times. I think we most recently used .gov.uk as a more realistic example. No, I'm not hypothesizing that .com had a record and passed the requirements stated (somewhat unclearly) right at the beginning of section 4.8. I'm pointing out that the paragraph after the note relaxes those requirements. Indeed, it says that the algorithm is valid for any domain. I think we have been through this more than once and we should not do it again. Yes, we've been here before, but we didn't conclude: https://mailarchive.ietf.org/arch/msg/dmarc/sxijuMsZuBlinO4x_SN5qhJ08nM/ Second, your "Furthermore..." claim reads to me as because the text says the identifier must be present and authenticated, it will make readers likely to think that the opposite is true. I think you should take a step back and reconsider your suggestion as it doesn't seem at all logical to me. Why? For example "Consider all American cars. Note, if limiting to Ford and GM (which really are cars), then...". Doesn't the parenthesized part instill the doubt that the whole set includes something which somehow is not really a car? I'd specify the algorithm first and discuss shortcuts after. If they are correct, it doesn't matter where the note is and if they are wrong, they should be fixed. It is the paragraph after the note which is not correct. It adds nothing. Its only purpose seems to be to re-introduce the framework, after the note. However, in doing so it relaxes the requirements. I don't think they are wrong and we should move on. Perhaps you've been too much involved in authoring that text. Please consider the hypothesis that you and John intuited something which does not actually correspond to what you wrote. I'm usually not classified as subnormal, have been programming since the 80s and running a mail server for 20 years.
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely wrote: >John, > >On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: >> As I would hope everyone in this discussion would be aware, the "as if" >> rule applies to all IETF standards. You can do whatever you want so long >> as the result is the same as if you had done what the spec says. > > >The "as if" rule also holds for the case that all domains are equal, the case >that no policy record is found, and the case that all alignments are strict. >Shortcuts have been part of the draft at least since April, and their presence >seems to be accepted by the WG. > >I don't understand why those shortcuts deserve being mentioned while the >parent-child does not. I think you're proposal is somewhat different than the existing shortcuts. The existing items in the note are cases where the tree walk can be skipped entirely. Your suggested addition is about a shortcut within the tree walk algorithm. I think that makes it sufficiently different to merit independent consideration. >In addition, presenting the shortcuts in the middle of the algorithm >specification can alter its meaning. See below. I disagree. They're marked as part of a note, so are not part of the specification. This is a reasonably common thing to do in IETF RFCs. > >> In this case, the speedup from your change is unlikely to make any >> speed difference since the repeated queries will use cached results, >> the extra complication is confusing, and the extra utility is zero. > > >Several mail servers don't have a dedicated DNS server, that means that each >query has a measurable cost. If someone is running a mail server that has a non-trivial load without a local DNS resolver, this will be the least of their problems. Regardless, anyone is free to optimize for their local architecture, if needed. > >> As I have repeatedly asked, if you think there are places where the >> tree walk results are wrong, show us some examples. Otherwise, please >> stop. > > >Here you are: > >I hope you agree that .com is a domain. The spec says that in order to >discover the Organizational Domain for a domain, I can perform the DNS Tree >Walk as needed for any of the domains in question. That way, the domain in >question, .com, is the Organizational Domain of itself. That is wrong because >.com is a PSD. > >Oh, perhaps "in question" refers to the three cases mentioned in the Section's >intro? It doesn't say so, it says a tree walk "might start" there, without >excluding other possibilities. "In question" can legitimately be understood >to refer to any domain at hand. > >Furthermore, the parenthesized reinforcement "if present and authenticated" in >a domain in the first shortcut casts a shadow on the requirement that all >identifiers except From: must be authenticated —if that requirement were >clear, there'd be no need to reinforce it. This corroborates the wrong >interpretation. First, if .com had a DMARC record and .com sent mail, it could be both a PSD for lower level domains and it's own organizational domain for itself, so your conclusion is incorrect. We have discussed this multiple times. I think we most recently used .gov.uk as a more realistic example. I think we have been through this more than once and we should not do it again. Second, your "Furthermore..." claim reads to me as because the text says the identifier must be present and authenticated, it will make readers likely to think that the opposite is true. I think you should take a step back and reconsider your suggestion as it doesn't seem at all logical to me. > >I'd specify the algorithm first and discuss shortcuts after. If they are correct, it doesn't matter where the note is and if they are wrong, they should be fixed. I don't think they are wrong and we should move on. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
Ale's point is part of a larger inefficiency. As information is gathered, the candidate names can be reviewed for a match. If a match is obtained, the result is PASS and the algorithm exits. If not, then candidate names which can be ruled out are discarded. If this makes the candidate list empty, then the result is FAIL and the algorithm exits. Otherwise, the process proceeds to the next information gathering step, where the logic is repeated.By the time we reach the relaxed alignment test, we should have discarded any candidate domains that are not equal to or children of the From Address organization. So all that remains is to do the walk to verify that no PSD flags are found before the From address organization is reached. DF On Sun, Jul 24, 2022 at 5:59 AM Alessandro Vesely wrote: > John, > > On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: > > As I would hope everyone in this discussion would be aware, the "as if" > > rule applies to all IETF standards. You can do whatever you want so long > > as the result is the same as if you had done what the spec says. > > > The "as if" rule also holds for the case that all domains are equal, > the case that no policy record is found, and the case that all > alignments are strict. Shortcuts have been part of the draft at least > since April, and their presence seems to be accepted by the WG. > > I don't understand why those shortcuts deserve being mentioned while > the parent-child does not. > > In addition, presenting the shortcuts in the middle of the algorithm > specification can alter its meaning. See below. > > > > In this case, the speedup from your change is unlikely to make any > > speed difference since the repeated queries will use cached results, > > the extra complication is confusing, and the extra utility is zero. > > > Several mail servers don't have a dedicated DNS server, that means > that each query has a measurable cost. > > > > As I have repeatedly asked, if you think there are places where the > > tree walk results are wrong, show us some examples. Otherwise, please > > stop. > > > Here you are: > > I hope you agree that .com is a domain. The spec says that in order > to discover the Organizational Domain for a domain, I can perform the > DNS Tree Walk as needed for any of the domains in question. That way, > the domain in question, .com, is the Organizational Domain of itself. > That is wrong because .com is a PSD. > > Oh, perhaps "in question" refers to the three cases mentioned in the > Section's intro? It doesn't say so, it says a tree walk "might start" > there, without excluding other possibilities. "In question" can > legitimately be understood to refer to any domain at hand. > > Furthermore, the parenthesized reinforcement "if present and > authenticated" in a domain in the first shortcut casts a shadow on the > requirement that all identifiers except From: must be authenticated > —if that requirement were clear, there'd be no need to reinforce it. > This corroborates the wrong interpretation. > > I'd specify the algorithm first and discuss shortcuts after. > > > > It appears that Alessandro Vesely said: > >> [...] > >> I'd propose to collect this and the three shortcuts of Section 4.8 (no > >> need to perform Tree Walk searches for Organizational Domains) and > >> move them to an appendix. > >> > >> To better clean up that section, I'd also remove the paragraph: > >> > >> To discover the Organizational Domain for a domain, perform the DNS > >> Tree Walk described in Section 4.6 as needed for any of the domains > >> in question. > >> > >> It can be understood as stating that the algorithm which follows > >> allows to determine the org domain for any domain at hand. Indeed, it > >> does not say that the algorithm is valid for the needed domains only. > > > 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] Shortcuts: parent-child allows shorter tree walks
John, On Sat 23/Jul/2022 19:52:33 +0200 John Levine wrote: As I would hope everyone in this discussion would be aware, the "as if" rule applies to all IETF standards. You can do whatever you want so long as the result is the same as if you had done what the spec says. The "as if" rule also holds for the case that all domains are equal, the case that no policy record is found, and the case that all alignments are strict. Shortcuts have been part of the draft at least since April, and their presence seems to be accepted by the WG. I don't understand why those shortcuts deserve being mentioned while the parent-child does not. In addition, presenting the shortcuts in the middle of the algorithm specification can alter its meaning. See below. In this case, the speedup from your change is unlikely to make any speed difference since the repeated queries will use cached results, the extra complication is confusing, and the extra utility is zero. Several mail servers don't have a dedicated DNS server, that means that each query has a measurable cost. As I have repeatedly asked, if you think there are places where the tree walk results are wrong, show us some examples. Otherwise, please stop. Here you are: I hope you agree that .com is a domain. The spec says that in order to discover the Organizational Domain for a domain, I can perform the DNS Tree Walk as needed for any of the domains in question. That way, the domain in question, .com, is the Organizational Domain of itself. That is wrong because .com is a PSD. Oh, perhaps "in question" refers to the three cases mentioned in the Section's intro? It doesn't say so, it says a tree walk "might start" there, without excluding other possibilities. "In question" can legitimately be understood to refer to any domain at hand. Furthermore, the parenthesized reinforcement "if present and authenticated" in a domain in the first shortcut casts a shadow on the requirement that all identifiers except From: must be authenticated —if that requirement were clear, there'd be no need to reinforce it. This corroborates the wrong interpretation. I'd specify the algorithm first and discuss shortcuts after. It appears that Alessandro Vesely said: [...] I'd propose to collect this and the three shortcuts of Section 4.8 (no need to perform Tree Walk searches for Organizational Domains) and move them to an appendix. To better clean up that section, I'd also remove the paragraph: To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in Section 4.6 as needed for any of the domains in question. It can be understood as stating that the algorithm which follows allows to determine the org domain for any domain at hand. Indeed, it does not say that the algorithm is valid for the needed domains only. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Shortcuts: parent-child allows shorter tree walks
As I would hope everyone in this discussion would be aware, the "as if" rule applies to all IETF standards. You can do whatever you want so long as the result is the same as if you had done what the spec says. In this case, the speedup from your change is unlikely to make any speed difference since the repeated queries will use cached results, the extra complication is confusing, and the extra utility is zero. As I have reapeatedly asked, if you think there are places where the tree walk results are wrong, show us some examples. Otherwise, please stop. R's, John It appears that Alessandro Vesely said: >Hi, > >the need to actually determine the organizational domain is a >misconception. For alignment, it is sufficient to determine that the >organizational domain of two identifier is the same. There is no need >to actually walk up there. > >For example, let's reconsider the basic example with an added subdomain: > >From: @dept.example.com >DKIM d=signing.dept.example.com >MailFrom mail.dept.example.com > >_dmarc.dept.example.com has a classic DMARC record (w/o psd=), so >that's the policy (and reporting) record. To check, say, DKIM, a >verifier queries _dmarc.signing.example.com and gets NXDOMAIN. At >this point it already knows dept.example.com is valid. The org domain >probably is example.com, or maybe it has psd=y, or maybe it has no >record at all, who cares? Whatever it is, it is the same for parent >and child. > >In practice, this means that in the common cases it is not necessary >to query _dmarc.com. > > >I'd propose to collect this and the three shortcuts of Section 4.8 (no >need to perform Tree Walk searches for Organizational Domains) and >move them to an appendix. > >To better clean up that section, I'd also remove the paragraph: > >To discover the Organizational Domain for a domain, perform the DNS >Tree Walk described in Section 4.6 as needed for any of the domains >in question. > >It can be understood as stating that the algorithm which follows >allows to determine the org domain for any domain at hand. Indeed, it >does not say that the algorithm is valid for the needed domains only. > > >Best >Ale >-- > > > > > > > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
