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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to