On 01/19/2018 03:17 PM, Chip wrote:
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.
Human users would be @chase.com not on a subdomain like
@alertsp.chase.com. It's becoming common practice to use a subdomain
for mass mailings, third-party senders, and automated mailings with
their own SPF and DKIM settings. This is good for us to separate out
the potential compromised accounts from system generated mass mailings
that can be trusted.
For example, we use clickdimensions.ena.com and "delegate" that
subdomain to marketing emails and customer communications from
ClickDimensions.com. There are no human senders sending from that
subdomain so the SPF and DKIM are very specific for ClickDimensions.com
to use. It would be safe to add "whitelist_auth *@*.ena.com" if one
wanted to. You could be absolutely sure that any emails from that
sender would be from my company and if there are any problems, report
them to our abuse mailbox and I would handle it.
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.
--
David Jones
