We should talk about "correct results". The PSL gets the correct results in 99-dot-something percent of messages, but we are proposing a new algorithm because it is wrong on some fraction of a percent. The size of the fraction is not a reason to ignore a problem. I support a change. But is the proposed change an improvement?
We also think the proposed tree walk will also return a correct result in 99-dot-something percent. But are they better answers? On what basis would we answer that question? What matters is whether the new algorithm produces correct answers when the PSL produces wrong ones, and whether it does this without introducing new errors that are not present in the PSL solution. On that question, the answer is at best uncertain. When the PSL and Tree Walk produce different results, we simply have no basis for choosing between the two, because the proposed Tree Walk is sourced on no new information. However, when the Tree Walk result is based on explicit tagging provided by the domain owner, then we do have a better answer than the PSL, because the domain owner knows more about his organizational structure than the PSL volunteers, and we have every reason to trust the domain owner's assertions. Consequently, we need DMARC policies that explicitly identify the organization domain and explicitly document the presence or absence of private registries. This is why I have proposed tags to that effect, with full intent of encouraging domain owners to use them. An alternate solution is to encourage domain owners to use exact-match identifiers, but we assume that option is a non-starter. Doug On Mon, Jul 11, 2022, 7:29 AM Alessandro Vesely <ves...@tana.it> wrote: > On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote: > > > On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely <ves...@tana.it> > wrote: > >> On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote: > >>> It appears that Scott Kitterman <skl...@kitterman.com> said: > >>>> On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely <ves...@tana.it> > 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: psd@c.b.a, 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
