On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman <skl...@kitterman.com> wrote:
> >> 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. > Or using data that is accidentally correct most of the time, where alternatives are available. Either way, +1. >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. > If we think this is important data to put in front of people, this WG could do that sort of survey once there are implementations and include the result in an appendix, or put it in the WG's wiki or in the IETF's collection of implementation reports: https://www.ietf.org/how/runningcode/implementation-reports/ It sounds like we're mostly there already given the analysis John did previously. >> 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? > RFC 2026 lays out the criteria for progressing a Proposed Standard to a Draft Standard and then to Internet Standard, and RFC 6410 later consolidated the latter two. The criterion to which I think you're referring asserts that any unused features need to be removed before a protocol can advance. However, RFC 7489 is not a Proposed Standard, so we're not constrained by that here. In any case, I agree that the longer the PSL remains in the equation, the longer we have to keep it, due to both inertia and growth of the deployed base. 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. > I think that's right, though Barry's memory on this might be better than mine. At a minimum, they're exceedingly rare. A working group or other community pushing for a flag day needs to have quite a bit of momentum to make it work. > 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. > +1 to this, for the reasons John gave in the email right below this one that just came in. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
