On Sun 24/Jul/2022 22:04:07 +0200 Scott Kitterman wrote:
On July 24, 2022 9:58:46 AM UTC, Alessandro Vesely <[email protected]> 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. Yet, I got it wrong, and you had to
write several clarification messages before I could grasp the algorithm you
mean. I had misunderstood what the draft says. After I finally got it, I
identified the misleading paragraph which deceived me. I'm asking that it be
removed.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
