No, I am not saying that we need to develop a tool to detect the difficult cases.
You say we need to preach at domain owners to lower defenses on 100% of their mail because one or more unthinking evaluators may do something foolish with a small percentage of their mail. I say that we need to preach at evaluators to not make foolish unthinking decisions. I say that DMARC is oversold because "reject" is the wrong assertion, although we are stuck with it for historical reasons, All that "p=reject" can mean is that "I believe all of my in-house mail is dual authenticated at origin and all of my service provider mail is DKIM signed at origin." The domain owner cannot assert anything more than he knows, and this is all that he can know. The DMARC specification and the "p=reject" terminology imply that this is all that the evaluator needs to know. The reality is that there are some messages which the evaluator (or at least his users) consider acceptable and desirable, which will not meet the DMARC criteria. The evaluator needs to consider that issue when formulating local policy. A large number of message sources can be trusted as impersonation-free because of the source, either the Mail From address or the server identity. This includes email service providers ,like ConstantContact.com and SendGrid.net, mailing list providers like IETF.org, outbound filtering services like ProofPoint and Mimecast, and necessarily trusted organizations like the U.S. Government. Some of these will actually violate DMARC, but all of their mail can be trusted as representing the true author. The specifics of these trust decisions are a matter of local policy, but identifying the ones that an evaluator will trust is a necessary part of any DMARC implementation. (And providing the appropriate exception mechanisms is an implied requirement for software developers.) Having evaluators understand how to act in their own self interest makes more sense than telling domain owners to weaken defenses for all of their mail and increase vulnerability for all of their recipients. Doug On Thu, Aug 11, 2022 at 12:29 AM Murray S. Kucherawy <[email protected]> wrote: > On Wed, Aug 10, 2022 at 10:44 AM Douglas Foster < > [email protected]> wrote: > >> "Breaking long-standing practice" is not the fault of the domain owner >> policy, it is the fault of DMARC being oversold and the DMARC result being >> applied by the evaluator in a way that undermines the interest of his own >> recipients. >> > > It's worse than that: It also sabotages normal operation of third > parties. RFC 6377 describes the damage we're talking about here, although > the tool was called ADSP back then. > > >> However, the domain owner has no reliable way of knowing whether >> conditions 4-5 will ever apply, and applicability will be different for >> different recipients. Therefore, the burden falls on the recipient's >> evaluator to determine whether "p=reject" is caused by condition 6 or by >> one of the other conditions. Telling domain owners not to use p=reject is >> not the solution; the real solution is for evaluators to act wisely, and to >> review other available evidence carefully. Our document can provide >> guidance on wise use, starting with a discussion of possible failure modes. >> > > I think you're suggesting that we need a way to identify a failure that's > caused by, say, MLMs altering messages (your case 4), and handle those > differently -- perhaps with less severity -- to avoid the collateral damage > DMARC causes. But that gives attackers a recipe for creating a message > that falls in your cases 5 or 6 yet will get less severe treatment than it > deserves. > > Similarly, creating a de-munging strategy presents a cookbook that might > be able to construct a message that will fail DKIM in a way that something > later in the processing order will forgive. Moreover, we would have to be > sure of being able to describe a very high percentage of all mutations MLMs > do in a manner that's hard for receivers to reverse incorrectly. But those > mutations range from simple (subject tagging) to quite complex (MIME > wrapping or restructuring). We've considered both of these approaches > before, and have never managed to convince ourselves we could achieve an > acceptable level of success. There was, so far as I know, not even a > single experimental implementation of any of the proposals. > > We seem to be left with the idea of telling domain owners that "p=reject" > causes damage at a level that does not justify the protection it provides. > Domain owners wishing to protect themselves obviously have disagreed with > that value judgement, but the community for which the IETF speaks, I would > argue, is larger than that. > > -MSK, no hat >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
