The 2% of messages statistic is probably the wrong measure. The alternative measure is to examine the percentage of domain pairs that have a result change. Using that measure, we have
70 of 881 (7.9%) pairs change from "PASS using relaxed alignment" to "FAIL because unaligned." 3 of 21 pairs change from "FAIL because relaxed alignment is present but strict alignment is required" to "FAIL because unaligned" 7 of 235 pairs change from "NO POLICY with relaxed alignment" to "NO POLICY and unaligned." In total 80 of 1137 (7.0%) change to an inferior trust state. Whether the best number is 7% or 7.9%, the error rate is too high to ignore. Doug On Sat, Oct 7, 2023 at 10:00 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Attached it is a spreadsheet with the problems from my data set. If it is > dropped during the forwarding process, let me know and I will re-post it in > the body of the message. > > The WG needs to prove that "The Tree Walk will cause no significant > disruption". We should have understood that trying to prove a negative > is a very difficult undertaking. Only one counterexample is needed to > disprove the assumption, and there is a near-infinite number of > counterexamples to be considered. In this case, we embraced one favorable > report, without obtaining additional data, and without even asking whether > the mail stream used for testing is a plausible proxy for the general > Internet. > > We do not need to speculate about "what the domain owner expected". We > can reliably assume that the domain owner expected his message to be > evaluated by RFC 7489 rules using a correct PSL. Did the Tree Walk > actually expose any PSL errors? If not, then the RFC 7489+PSL result is > what was intended. > > One could postulate this approach to finding and fixing problems in the > PSL: > 1) Evaluate incoming messages using both PSL and Tree Walk. > 2) When the two techniques produce different results, study the message, > and consult other resources, to determine whether the PSL is correct or > not. If the conclusion is a PSL error, make the PSL correction and note > the entry as verified. If the Tree Walk result is in error, document that > result as well. > 3) Repeat for each new discrepancy between the two methods. > > My suspicion is that PSL errors will be very difficult to find by this > method, because the PSL will be correct in the overwhelming majority of > cases. When the payback is infrequent, most evaluators will conclude that > the labor investment is not sufficient to the benefits gained. > > I am not opposed to deprecating the PSL, just opposed to deprecating it > with a one-sided redesign of the protocol, using rosy assumptions. I do > not want to create a clone of the mailing list problem. > > Doug > > > On Sat, Oct 7, 2023 at 3:46 PM John Levine <jo...@taugh.com> wrote: > >> It appears that Richard Clayton <rich...@highwayman.com> said: >> >I do wonder if this is the PSL raising its ugly head again. A remarkable >> >number of the people who have added entries have not understood how they >> >now need to publish rather more DNS records than previously ... >> >> Definitely. In the few cases we've found where a tree walk would >> provide a different result to the PSL, it is not clear which one the >> domain owner expected. >> >> R's, >> John >> >> _______________________________________________ >> 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
