> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz <[email protected]> wrote: > > > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman <[email protected]> wrote: >>> >>> 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.
Scott, I’m also aware of what happened to SPF’s run as a policy layer. There’s a big difference between SPF and DMARC. People deploy DMARC with the knowledge that it is the policy layer. Many soon learn that SPF hard fail isn’t honored much. There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes for a more robust system that you can get your legit mail passing DMARC consistently. SPF does was it does well but it with things like forwarding breaking it, the presence of DKIM made up for some of SPF’s shortcomings and vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a good place to set policy. DMARC is a much stronger policy layer so I hope you are thinking that the policy setting aspect will go the way of SPF? It won’t. Neil _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
