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
