Re: [dmarc-ietf] premature optimizations, Shortcuts: parent-child allows shorter tree walks
When a topic is decided with consensus, it does not get reopened.What happened here? On Sun, Jul 24, 2022, 9:35 PM John R Levine wrote: > >> 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. > > Scott is correct and I wish people would stop trying to reargue decisions > we > already made. > > Regards, > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > 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 > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] premature optimizations, Shortcuts: parent-child allows shorter tree walks
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. Scott is correct and I wish people would stop trying to reargue decisions we already made. Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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 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
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 24 06:00:04 2022
Count| Bytes | Who ++--- 44 ( 100%) | 275972 ( 100%) | Total 14 (31.8%) | 85847 (31.1%) | Scott Kitterman 13 (29.5%) | 71816 (26.0%) | Alessandro Vesely 8 (18.2%) | 40989 (14.9%) | John Levine 4 ( 9.1%) | 43642 (15.8%) | Douglas Foster 2 ( 4.5%) | 18007 ( 6.5%) | Murray S. Kucherawy 2 ( 4.5%) | 9399 ( 3.4%) | John R. Levine 1 ( 2.3%) | 6272 ( 2.3%) | Tim Wicinski ___ 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
