+1 to Doug's comments. I think an expected and desired state achievable in the foreseeable future (based on the flows I see) is to require at least some form of authentication (whether it's SPF, DKIM or ARC).
On Mon, Apr 10, 2023, 8:18 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
