On Thu, Aug 11, 2022 at 4:50 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> 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. > The rollout of DKIM to the world taught me that the more thinking an operator needs to do, the less likely this is to be deployed quickly or correctly. > 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. > I disagree. A domain owner can know, for instance, that it only sends transactional messages that have no purpose to ever go to a mailing list. Such an operator can safely set "p=reject" because the risk of the collateral damage about which we're concerned here is close to zero. That is equivalent to the domain owner knowing not only that there's dual authentication, but also that authentication is highly likely to survive to delivery. When users are introduced into such a system, that logic goes out the window. DMARC is arguably not appropriate for those use cases, and Barry is urging that we say so. > 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.) > Who has that list? Who keeps it up to date? How do you know it's complete, at least enough for all your users to be happy? Would you trust someone else's list? I'm not sure I'd trust even the list you just gave me given the number of spam messages I get via SendGrid, for example. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
