Keep in mind that we have looked at this extensively, and what we've found is this:
1. Almost all [1] of the DMARC senders out there will see the same results when recipients look them up using the tree walk as they have using the PSL. In other words, the change will be different an *extremely* small set of DMARC domains. 2. In *all* -- by that I mean 100% -- of the cases that we've actually *seen* where there's a difference, the difference is *better*: that is, the difference is a better reflection of the intent of the sending domain. 3. We can find theoretical cases where the tree walk will be *worse*: that is, where the PSL is a better reflection of the intent than the tree walk is. But *all* of these are theoretical, and we have not found *any* such cases that actually exist in the real world. It is, though, possible that they do exist. Emil, given those three points, do you still think you need to be concerned about the risk of making the change? Barry [1] In mathematics, we use "almost all" as an actual technical term that applies to an infinite set and means "all but a finite number", since removing a finite number of entries from an infinite set still leaves an infinite set. That's kind of what I mean here. That is, the vast, vast, VAST majority. On Sat, Jun 10, 2023 at 12:26 AM Emil Gustafsson <emgu=40google....@dmarc.ietf.org> wrote: > > Not sure if I am that someone mentioned. In case I am - I'd like to clarify > what I meant; > > Without a version change for the tree-walk, I think we (Google) would need to > support both approaches (the old one plus the tree-walk) and based on what we > see - make a best guess which version we should use. > Having two explicit versions still means we have two implementations, but at > least we don't have to guess which one to use whenever there would be > ambiguity with a single version. > > I'm always concerned about what bad people do to gain an advantage. But in > this case I'm more worried about somebody having an ambiguous DMARC setup > where VLMPs end up guessing the wrong intention. The most likely outcome > there would be rejected emails and an upset sender the VLMP need to deal > with. But atleast they are not spoofed. I think explicit versioning helps > mitigate that risk too (but it wont help companies making bad configurations > - but that we always have to live with). > > /E > > On Thu, Jun 8, 2023 at 10:21 AM John Levine <jo...@taugh.com> wrote: >> >> It appears that Tobias Herkula <tobias.herk...@1und1.de> said: >> >However, such a fundamental shift in the protocol's architecture warrants a >> >clear signifier. I suggest we upgrade >> >our DMARC version string from the current state to 'DMARC2.' This upgrade >> >would not only denote the change of SPF >> >removal, but also the switch from the Public Suffix List (PSL) to the >> >Tree-Walk algorithm. >> >> I was talking with someone from a Very Large Mail Provider who told me that >> if we keep the same version number, they won't change what they do now, so >> no tree walk even if we keep SPF. >> >> They understand that as things stand now, the results of the PSL and >> the tree walk are in practice the same. Their concern is that if some >> people do it the old way and some the new, and you can't tell which >> the domain expects, bad guys will create records with deliberately >> inconsistent results. >> >> I'm not sure how likely that is, but arguing with a gorilla rarely >> turns out well. I will see if I can talk to people at other VLMPs >> and see how widespread this concern is. >> >> R's, >> John >> >> PS: If we do bump the version number, it needs to go into the >> aggregate reports, too. >> >> _______________________________________________ >> 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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
