The SmarterMail implementation follows RFC 7489, which is a big problem, because the RFC leads people to make poor decisions. It implies that Fail with p=Reject is always unwanted, which is false. IETF wrote a whole RFC on the problem (RFC 7960). The RFC also implies that any other Fail is not actionable, which is also false.
Since 95% of all domains lack a p=reject policy, ignoring No Policy and Fail with p=none will leave you vulnerable to 95% of all detectable impersonation attacks. A completely different approach is recommended.
- A message is authenticated if it has "Aligned SPF Pass" or "Aligned DKIM Pass". This test can be applied to every message, using a default alignment rule of relaxed. It is stupid to ignore this important information simply because the domain owner has not published a policy. (This approach is predicted to jump your authentication rate to about 85% of all incoming messages.) When this criteria is satisfied, it becomes safe to flag a Trusted Sender or a BIMI image, because impersonation has been ruled out (within the limits of the technology.)
- If a message cannot be authenticated, you are at risk of a malicious impersonation attack. You either hope to luck that your content filtering will catch the malicious attackers, or you do the hard work of investigating the authentication failure. I refuse to delegate my network security to strangers, so the stranger's DMARC policy has no impact on how I respond. My commitment is to investigate EVERY authentication failure.
- Authentication failure is ALWAYS an ambiguous result. You need to investigate the root cause to eliminate the ambiguity so that you will never have to do so again. Two results are possible:
- The message originator is malicious, or otherwise unwanted, so you block the identifiers that represent the message originator. Now you are protected even if the attacker uses a different attack technique.
- The message author is acceptable, so you create an alternate authentication rule that represents the acceptable entity.
- A rule based on server name, verified with fcDNS, can provide proxy authentication for the accompanying "Mail From" address, mimicking the design of SPF.
- A rule based on Mail From domain, verified by SPF or local policy, provides proxy authentication for the From address, mimicking the design of DMARC.
Because future messages will either be blocked by local blacklist policy or verified by local authentication policy, you never need to worry about this ambiguity again.
When the message is authenticated by local policy, the message should be given a custom header to indicate successful authentication. Then SmarterMail can detect the custom header so that Trusted Sender and BIMI image features can be activated.
I had to build the alternate authentication rule structure using Declude and SQL, because you build long lists and you are creating 3-attribute authentication rules (underlying identifier, verification result, and proxy authenticated identifier.)
The implementation process was manageable because I had a good message review tool in my Barracuda appliance. In the beginning, I let Declude flag the authentication results while relying on content filtering alone. Then I investigated unauthenticated traffic after it was released to the user. The process converged pretty quickly, at which point I was able to make authentication mandatory, with unauthenticated messages being sent to quarantine (never to Block!)
Authentication does not solve all problems. I still have to contend with authenticated-but-unwanted messages, mostly from Gmail, that are sent from computer-generated accounts created for one-time use. But it helps block most everything else.
In the short term, what I want SmarterMail to do is to drop the "ALWAYS BLOCK ON FAIL" rule. This will at least allow me to activate SmarterMail DMARC processing, s that I can take of Trusted Sender and BIMI when their standards-based design generates a PASS result. But I will not turn it on anything that forces me to block wanted messages.