On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy <[email protected]> wrote:
> On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman <[email protected]> > 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. > > Bite the bullet and mark use of the PSL historical for DMARC. As has been pointed out, there will always be a long tail but we are talking rare corner cases where the results from the two approaches diverge. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
