Okay, trying to understand.
You say:
whitelist_auth *@*.chase.com
whitelist_auth serv...@paypal.com
This would trust emails from any subdomain under chase.com and
serv...@paypal.com that hit SPF_PASS or DKIM_VALID_AU rules.
Okay, got that.
But I'm confused when you further explain:
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.
Do you mean don't whitelist_auth *@example.com *unless* they have
published spf/dkim?
Certainly paypal and chase (your examples where you would use
whitelist_auth) have real human users. . .
Thanks in advance for clarifying.
On 01/19/2018 03:59 PM, David Jones wrote:
> 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.
>
