On July 14, 2022 12:11:57 PM UTC, Alessandro Vesely <ves...@tana.it> wrote: >On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote: >> On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" <superu...@gmail.com> >> wrote: >>> Once again, participating only: >>> On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote: >>>> [...] >>> >>>> 3) The critical question is whether we can treat the PSL as replaced >>>> without obtaining the markers first. On this issue, John and I have a >>>> different assessment of the risk. I can accept a solution which lays out >>>> the assumptions and risks to the evaluator, and lets them decide what to >>>> do. This is what sections 4.7. and 4.8 in my text from Sunday night >>>> attempted to do. >>> >>> My suggestion would be that if we are going to offer a choice, there should >>> be some eventual path toward convergence rather than an open-ended period >>> of people doing either. Otherwise, the PSL will be a part of DMARC for far >>> longer than we'd like. >> >> I think a choice within DMARCbis is a bad idea. Effectively the choice >> exists. Evaluators will have the choice to stay with an RFC 7489 design or >> to upgrade to DMARCbis. > > >The incentive to upgrade is not clear. DMARC filters can run based on an >obsolete version of the PSL with no inconvenience, for a different flavor of >"upgrade". Indeed, according to John's figures, we could have done without >any psd= tag. > Using obsolete data is a bug, not a feature.
>Doug's idea of checking the results is a means to draw the attention of >operators on both the PSL version they use and its agreement with the DNS at >large. New implementations could be encouraged to track the differences and >produce some kind of report about them. IME, although running a very small >mail site, it does happen to hit some PSL entry, a fact which I realized by >chance —browsing the logs— so I cannot tell figures. What would operators do with such a report? Receivers tracking sender configuration issues and reporting issues back to them is a very 1990s approach to making the Internet work. I don't think it's relevant to anything useful these days. > >> We can't get rid of the PSL without getting rid of the PSL. >> >> There's no way to constrain it within the document. If we have a 'choice', >> we are essentially signing up the IETF to a future effort to produce an >> update to actually get rid of it. > > >Right, that would be the Internet Standard. Not really. To drop functionality going to Internet Standard, don't you have to show it's not used? How would that even work? My understanding is that the IETF, based on past experiences, doesn't do flag days where everyone has to switch to some new thing by a specific date. Currently we don't have any procedural requirement for backward compatibility, since RFC 7489 isn't an IETF document. Based on the working group charter and good engineering practice we should limit changes that affect existing deployments, but we have more flexibility now than we will ever have again. In my view, standardizing two ways to do policy discovery and alignment would be a substantial danger to interoperability and we'd be stuck with it approximately forever. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
