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 <ves...@tana.it> 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
