On 01/19/2018 02:21 PM, Jeffs Chips wrote:
I would be very interested in knowing what features in SA  flag spoofed email addresses.  Knowing the methods used or plugins available to detect spoofed emails is integral to the project I'm working on.


That is the million dollar question. If we had a solid way to detect spoofing then the spoofing problem would not exist any more. It's a combination of sending IP reputation (RBLs), authorization (SPF), and authentication (DKIM), and content. These are the main categories of rules which all have to be balanced carefully to accurately detect spam without FPs.

The major brands and company names are commonly used in spoofing like Dropbox, Paypal, Bank of America (and other banks), etc. I just got one a few hours ago spoofing LinkedIn.

The technique that I have found to work requires these major brands and companies to have properly implemented SPF and/or DKIM usually on a subdomain like alertsp.chase.com or a dedicated email address like serv...@paypal.com. Then you add an entry like this:

whitelist_auth *@*.chase.com
whitelist_auth serv...@paypal.com

(No need to add those entries since they are in the default rulesets already.)

This would trust emails from any subdomain under chase.com and serv...@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.

Assuming that real human users with passwords that can be compromised are using *@example.com, you would never want to add "whitelist_auth *@example.com" except for very specific reasons. Example.com should have proper SPF and/or DKIM and the domain ownership be verified to be who you think it really is. Then create rules and train your Bayes DB for all other variations of these major brands and companies to add points and block the spoofing.

If you look at my ena.com, we have DMARC setup with p=reject. This is just about the best thing that we have today to prevent spoofing of ena.com. As more an more major brands and companies wanting to protect their brands and reputation implement DMARC p=reject, we can use this information to block even more spoofing. Of course my domain is not a target of spoofing since we are a small company.

Today DMARC support for SA requires setting up OpenDMARC at the MTA (i.e. Postfix) and then adding custom rules to act on those headers. For example, I add a number of points when the sending domain has p=reject and DMARC fails.

FYI, there are a huge number of broken SPF records out there. Thanks to Microsoft telling everyone to create brand new SPF records with "-all" without knowing all sources of their email, a lot of legit emails fail SPF checks with the standard Office 365 SPF record.

--
David Jones

Reply via email to