Those are all valid points, and I don't have a solution for them which preserves the status quo.
I see the world moving to more Sender Authentication, not less. Mandatory Sender Authentication is my expected end-state. ARC is an acknowledgement of this trend. ARC may not add much value to lists, because it requires out-of-band communication before From-munging can be disabled. But to the extent that ARC is useful to lists, it forces them to do more and better Sender Authentication than the previous norm. So even they are getting sucked in, willing or not. All of which is why I sketched out a very different mailing list design. It's not my job or my agenda to sell it to people, not my job to build the product, and not my job to deal with hurt feelings. The Internet changed when we realized that bad guys dominate the environment, and Sender Authentication is one of the consequences. The name-translating design provides a path to reliable list delivery when Sender Authentication is mandatory. I think that kind of future-thinking is what standards are supposed to do. Doug On Sun, Apr 9, 2023 at 5:28 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> As an evaluator, what I can accept is that "Some intermediaries could be >> allowed to make some changes y do want unrestricto messages, if I have a >> list of intermediaries that should be allowed, sufficient reason to trust >> what they propose to do, and a reliable way to identify them." I do >> exceptions all the time. But lists don't want to make special >> arrangements with evaluators, and don't want to make special arrangements >> with senders. Apparently, lists don't even want to do rigorous >> verification to ensure that a post comes from the purported subscriber. >> But theted access to evaluators that filter based on simplistic triggers >> like "p=reject". >> > > I see two issues with this line of thinking: > > (1) "I do exceptions all the time" works when you are a relatively small > operator with a relatively small user base for whom you need to configure > exceptions. You can get away with doing those manually. What size staff > do you imagine GMail would need to hire to investigate and configure manual > exceptions on a timely basis for each time one of its billion-plus users > wants to subscribe to a mailing list? The notion screams for automation, > and automation screams for something deterministic or at least close to it > upon which to base automated decisions. That last bit is what's missing > here. > > (2) "But lists don't want to make special arrangements with evaluators, > and don't want to make special arrangements with senders". They might, if > there existed a reliable way to do so. How would you accomplish this in a > way that prevents an attacker from making you think he's a list, and then > sending whatever he wants from inside that trust boundary? > > I think evaluators SHOULD NOT block on simplistic rules like p=reject, >> because a correct p=reject block requires follow-on work to block >> everything else from that malicious source, and should not be done >> incorrectly. They should review, either with pre-quarantine or >> post-audit, which is what I do. I have no problem with >> disposition=quarantine, even for p=none. I am obligated to protect my >> users, while also obligated to provide my users the messages they need, not >> the ones that are technically optimal I don't understand why Big Tech and >> its A.I. tools cannot be deployed to do the best thing. >> > > I'm pretty sure they could, for their own use cases. But what about the > operators in between, who aren't Big Tech and don't have AI tools? A > standard has to work for everyone. > > -MSK, participating > _______________________________________________ > 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
