I disagree with the conclusions drawn here. This frankly feels like the old chestnut, how does DMARC protect anything at all, since a domain owner can only protect their own domain against spoofing and the bad actor will simply choose another domain? My response to that is that I still wish to lock my car and secure it even if people are stealing other cars. At my personal level, I start by protecting my domain. I help the ecosystem by helping others to protect their domains, through specifications such as this.
I also disagree that only god can see the global threat situation. Every mailbox provider and spam filter MX has a varying level view of the threat situation and information on the global threat situation is compiled from that data and comparing notes between providers and filterers. None of this seems like actionable feedback on how to improve the specification. Regards, Al Iverson On Thu, Dec 5, 2024 at 6:28 AM Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: > > Example.com sends 10,000 messages per day, of which 100 (1%) produce DMARC > Fail, so they publish a policy with p=none. > > Attackers send 1,000,000 messages that impersonate Example.com. On a global > basis, messages claiming to be from Example.com are 99% Fail, and the Fail > are 99.99% true spam and 0.01% false positives. > > In response, Example.Com changes its policy to p=reject. The spammers mostly > switch to impersonating Example.Edu,leaving only 100 attacks per day on > Example.Com. The Fail rate is now down to 2%, of which 50% are true spam > and 50% are false positives. > > > But nobody but God sees the global threat situation. An evaluator who sees > 50 messages per day may see 50 PASS, 50 False Positives, 50 True Spam, or any > mix of the three. Additionally the mix may change over time. > > Responses: > Some evaluators will see 50 true spam with p=none, conclude that DMARC is > useless, and unconditionally block Example.com. When the mix changes, > legitimate messages will be blocked. > > Some evaluators will see 48 pass, 2 false positives, and conclude that DMARC > needs an override. They use the only override offered by their filtering > product, which is to exempt Example.Com from authentication. When the mix > changes, attack messages will be allowed. > > Because neither of these evaluators have learned anything about the > attackers, they are not prepared to defend themselves when the same attackers > change from impersonating Example.Com to impersonating Example.Edu > > Conclusion #1: Sender disposition policy has no relationship to either > global threat risk or personal threat risk, and SHOULD be ignored unless > another use can be found for it. > > Conclusion #2: Blocking unauthenticated messages creates vulnerabilities, > unless the cause of the authentication is investigated and traced to the > responsible party. The best way to do this is by sending messages to > quarantine, then configuring wanted message sources with alternate > authentication and unwanted messages sources with block rules. > > RFC7489 has misled a lot of people about the impersonation problem, and > DMARCbis has not fixed that. > > Doug > _______________________________________________ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
