The AOL breach obviously just magnified a problem that was already in place - impersonation is a useful attack vector. Email addresses do not have restricted distribution, and they fall into the hands of unwanted senders all the time.
We currently have a regime of semi-mandatory sender authentication. Some domain owners request it and some do not, some evaluators enforce it and some do not. Recipients assume that apparent identities can be trusted, generally without understanding the nuances between Friendly Name, From Address, and MailFrom address. At the same time, some participants (including but not limited to mailing lists) depend on absence of sender authentication, at least on their unauthenticated traffic, a practice which works only as long as their traffic is not be impersonated. The whole configuration is inherently unstable because domain owners and evaluators can change their policy at any time, and unauthenticated traffic can collect impersonators at any time. The stable designs involve no authentication and mutual distrust, or mandatory authentication. Neither outcome is likely in the short term, so the instability will persist. I don't know that our document can make much impact either way. I think language which most closely reflects reality is the tone that I have been pushing: "Sender Authentication is too important to ignore, but too imperfect to trust unconditionally." Doug Foster On Mon, Apr 10, 2023 at 2:00 AM Wei Chuang <weihaw= 40google....@dmarc.ietf.org> wrote: > > > On Sun, Apr 9, 2023 at 2: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. >> > > +1 > > >> (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? >> > > +1 > > FWIW I'm starting to think this problem has two parts: > 1) We know that a sender intends to send a message down some path that may > include a mailing list, that got to me safely. This is to avoid DKIM > replay and FROM spoofing attacks. > 2) That we can identify the contributors to the content of the message in > that path to distinguish malicious vs benign contributors. For certain > constrained but hopefully reasonable scenarios of mailing list > modifications, we might be able to distinguish the sources of content. If > necessary, we can go back to first principles to determine which > modifications have to be supported. For example I've seen Brandon mention > that mailing list appending disclosure footers are required for compliance > sometimes. Others hopefully we would not have to support to reduce > implementation complexity. > > >> >> 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. >>> >> > Simplistic rules are more likely to be deterministic and interoperate in > an understandable way. Permitting exceptional cases and AI tools > introduces complexity and variability as exceptions are given and AI models > change. > > -Wei > > >> 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
