On 9/23/18 10:46 AM, Henrik Krohns wrote:
On Sun, Sep 23, 2018 at 09:15:33AM -0500, Dave Jones wrote:
Keep in mind that these entries are usually subdomains that will not be
user/human mailboxes that can be compromised. These entries are verified to
be system-generated and have other rule hits making them trustworthy senders
that honor opt-out requests without harvesting/validating the email
addresses and handle abuse reports of their rogue customers.
I guess that makes sense since system-generated messages are more prone to
FPs, perhaps being identical looking and mass sent.
But lets say we take for example the 5 biggest banks, healthcare or
insurance companies in some country (Finland? I trust them to be competent
enough. :-D). What are the chances of someone hijacking a mailbox there
and sending masses of spam? They can't even anonymize themselves. Or if
they tried to impersonate someone, what difference would SA default
whitelisting make? Very likely custom phishing would not be caught in
any filters anyway, unless foolishly having some uribl links etc.
Domains with user mailboxes that can be compromised should not be added
to this list unless we can know for sure the sender properly filters
outbound email or uses 2FA to stop compromised accounts. That is why
you see entries like *@*.example.com and not *@example.com since
*@example.com will most likely be user mailboxes that can be compromised.
Phishing can be caught if you have local meta rules matching content
that is common to phishing. For example, I have local rules that add 4
to 8 points for emails with "Chase" in various locations then the
whitelist_auth *@*.chase.com entry will allow through real chase.com emails.
If backgrounds are checked carefully, I don't think there is much difference
in whitelisting system or user domains. Someone could as easily hack a
mass-mailer account.
I have not seen a hacked mass-mailer account in 4+ years. I have seen
rogue customers of the mass-mailers. Most mass-mailers I have worked
with want to keep their domain reputation in good standing so they
welcome feedback via Spamcop or their abuse contacts to lock/disable
their rogue customer.
I would not put a mass-mailer domain in 60_whitelist_auth.cf but I have
put a few into my local whitelist_auth list.
I do have these in my local list:
whitelist_auth *@amazon.com
whitelist_auth *@*.amazon.com
but this is very different from:
whitelist_auth *@amazonses.com
whitelist_auth *@*.amazonses.com
which is a mass-mailler with some rogue customers.
It would be nice to create to guidelines on what to check if considering
adding something, and not having a private backend to utilize..
Here's my system's logic:
1. Must have at least 100 hits the past week
2. AND must not hit FREEMAIL, URIBL_IVMURI, or DMARC FAIL
3. AND must hit RCVD_IN_HOSTKARMA_W, RCVD_IN_MSPIKE_H4,
RCVD_IN_MSPIKE_H3, RCVD_IN_RP_CERTIFIED, RCVD_IN_RP_SAFE, or RCVD_IN_IADB_*
4. AND must hit SPF_PASS, DKIM_VALID_AU, or DMARC_PASS
5. AND have an average SA score < -2.0
6. AND then pass domain level requirements to be a subdomain (not the
primary domain where user mailboxes could be compromised)
I have a script run that query every Sunday morning and spit out entries
to add. It automatically adds these to my local lists.
For example, if this is the SPF record:
include:spf.messagelabs.com include:_spf.anpdm.com ip4:194.9.95.111 -all
That does have quite many loopholes, even though you see reputable companies
handling the mail. Would this be considered safe for whitelisting then?
Logic rule #6 above will exclude user mailboxes that I would not trust.
Consider the difference between these two SPF records:
# dig email.chase.com txt +short
"v=spf1 include:epsl1.com -all"
# dig chase.com txt +short
"v=spf1 a:spf.jpmchase.com ip4:207.162.228.0/24 ip4:207.162.229.0/24
ip4:207.162.225.0/24 ip4:196.37.232.50 ip4:159.53.46.0/24
ip4:159.53.36.0/24 ip4:159.53.110.0/24 ip4:159.53.78.0/24
include:tpo.chase.com -all"
Do this make sense that *@*.chase.com is safer to trust than
*@chase.com? Many company have started using subdomains properly to
send from so SPF, DKIM, and DMARC can have their own settings diferent
from their main user email. We want to encourage this all over the
Internet so we can separate out those system-generated emails from user
mail.
Of course there is DNSWL etc which can be utilized.
-hk
