On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote:
On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely <[email protected]> wrote:
On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
It appears that Scott Kitterman <[email protected]> said:
On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely <[email protected]> wrote:
Yeah, /should/! The very fact that you yourself changed your mind about how it
works, without going into the hassle of explaining your reasoning,
Um, what? Scott and I went through some rounds of debugging to be sure the tree walk
handled some obscure edge cases in a reasonable way. It was all on this very mailing
list with examples. I think what we have now is OK but if you find something in the
tree walk that is unclear or gets an unreasonable result, let us know, preferably with a
concrete example.>>>
I think I received all list messages (although I don't check against your weekly
count) and I read all of them. Perhaps I've been inattentive, but I don't recall the
switch from stop on psd=y to continue on psd=y if it's the first lookup. Any
pointer?>>
I don't recall having changed this. If you can check the previous draft revisions
to see when it changed, maybe I could find it. I'm confident that any changes to
the way the tree walk works have been discussed on the list.>
I changed it in a pull request a few weeks ago.
If you don't stop on the first psd=y that is not the original domain,
you get the wrong result if there are DMARC records above the psd=y.
That's undoubtedly correct. The point I'm raising is the one at point 2 (both
sections). For org discovery, it's in the hunk tagged @@ -720,13 +722,13 @@ in
the same pull request, here:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47/files#diff-758de98ab8f970604c5891fceb8cb498ffe212c02060fdbf0e6ee5bffbb0a3cbL720
That affects messages From: [email protected], in John's example below. In that case,
the change sets the org domain at b.a (assuming that blah stands for a DMARC
record) instead of c.b.a. That is, a PSD domain itself is a regular subdomain
of the org domain below. Apart from slightly complicating the algorithm, that
might be a reasonable position. IIRC, it wasn't discussed on list. More
importantly, it isn't explained in the draft.
I don't understand what you want.
An appendix exposing a walk through the algorithm.
I think (and I might be wrong) you agree the current draft gets the correct
results, but you think there was some kind of process foul about how it got
fixed.
I don't think your assertion that it wasn't discussed is correct.
Well, we're discussing it now. However, we're keeping on a meta-level
above the matter.
John posted a pointer to the changes [1] and asked for comment. You
participated in the thread. I don't know what else you want. If a document
author provides proposed changes and no one asks questions about one of the
changes, I don't think it's incumbent upon the author to point out not
everything was discussed.
I reviewed the thread you cited. I did ask questions about one of the
changes when I replied. John's answer, however, simply repeated the
words of the draft. He previously only said that if you are sending
mail you are not really a PSD. Then, one may wonder whether a filter
should still consider a specific psd=y to be an error if it is going
to meet it in subsequent steps, because once it received mail (or
signatures) from that domain.
I also don't know what explanation you want in the draft. In my experience,
IETF documents focus on what to do and do not generally have significant
expositions on why or all the potential implications of a particular design
choice.
We are proposing an alternative to the PSL without having any
experience of it. I think a Proposed Standard should give full
explanations of design choices, so that possible, future amendments
can be thoughtful and considered.
As I said in that thread, I think going too far into corner cases like this is
likely to make the document more confusing.
An appendix is usually not normative, and people not interested in
delving into the specific detail just skip it.
Finally, I struggle to understand how this detail is relevant to the question
of early assignment of psd=?
It is not. Neither suggests a better term.
Please help me understand what the issue is here? It might be useful for you
to start a new thread with specific text you think needs to be in the document?
Hm... could do.
Best
Ale
--
[1] https://mailarchive.ietf.org/arch/msg/dmarc/OaaC-N1MV-JlnpdDm0HTMVeSQrs/
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
