On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > attacked? Granted, high profile domains or perceived lucrative targets will > receive the most attention but threat actors absolutely do attack all sorts > of organizations all the time. > > Maybe I’ve misunderstood but I hope that no langue that could be construed > as discouraging domain owners from moving toward an enforcing policy would > be a mistake.
It all depends on the user base of the domain and the tradeoff between the benefits of having such a policy against the interoperability risks of having such a policy. We absolutely should be discouraging blind adoption of policies that result in reduced utility for email. For any domain that has non-transactional users, that takes work to assess the completeness of email authentication deployment, assess aggregate reporting to understand the likely effects of either p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs associated with such policies. That's a non-trivial set of work to do and it's not cost effective for all domains to do it. Early in the deployment of SPF there was a similar push to deploy SPF records with -all (the SPF rough equivalent of p=reject). A lot of people did it without thinking it through and there were significant side effects. The community concluded that SPF Fail (due to the -all in the record matching) was not a sufficiently reliable indicator that mail should be rejected and largely stopped doing it. Aggressively pushing DMARC p=reject on domains that aren't ready for it may well lead to a similar result. Let's not. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
