The recent discussion has introduced two challenges to ARC: first, that it is too complicated, and second, that it opens up security holes that should be unacceptable. John's response appears to be that the technology will only be used by a small group of lists in cooperation with a small group of recipients, that the complexity will be a non-issue for the participants and the risk, while present, will be mitigated by the limited scope of participation. All of this is problematic.
On security issues, we have to assume attacks by state-sponsored actors, not just fortune seekers. So the security challenge needs to be thoroughly vetted. But the participation assumption is even more worrisome. If this is a limited participation protocol, supported by a private but not-yet-created communication network, then it does not solve the chair's requirement for a general solution. I ask the chairs to formally endorse development of an alternative to ARC as an additional approach to the mailing list problem, a solution based on reverse transformation. Alessandro and Murray have submitted drafts. It is time to study their proposals and merge their work. Doug Foster On Sat, Dec 5, 2020 at 11:14 PM John R Levine <[email protected]> wrote: > On Sat, 5 Dec 2020, Jim Fenton wrote: > >> Of course not. That's just the tiny gorillas stamping their teensy > feet. > >> Why would anyone expect that the people publishing that flag actually > >> understood what it meant? Many will just turn it on because someone > said > >> it's "more secure." > > > > FWIW, I don’t think a lot of the people publishing p=reject understood > the > > implications of that, either. This is not significantly more arcane. > > Then I think we agree. There's no difference from p=reject and > p=reject-I-really-mean it. > > > ... If the recipient domain accepts modifications by zero-reputation > > intermediaries (because there are so many of them, after all) > > I wouldn't call that a reasonable implementation of ARC. The set of hosts > that are likely to send you mail with interesting ARC chains is relatively > small, and I don't think it changes very fast. Most of the hosts that > send you non-spam mail aren't going to send you mail that needs ARC. > > If you're setting up a new mailing list host or forwarder, getting > yourself into whatever whitelists people use will be somewhat painful but > there's nothing new about that. > > > I’d be interested in other opinions on this. Or whether this is a > fundamental > > problem with ARC. > > I'd certainly be interested in hearing how people plan to compile and > maintain their lists of ARC-worthy hosts. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
