TL;DR: These need to be def_whitelist_auth NOT whitelist_auth as you
have been committing them. See the earlier exchange between myself and
RW, who had assumed this was only about def_whitelist_auth entries.
Precisely because most users will never bother managing a large number
of local rules, using whitelist_auth with its -100 score prevents the
rest of SA (and prudent local rules) from mitigating the whitelisting
effect in the event of a compromise or change in behavior of a 'trusted'
sender. While the documentation doesn't say so explicitly, the
implication in the Mail::SpamAssassin::Conf descriptions of the
def_whitelist_* directives is that the default whitelist entries all use
those less powerful versions. That was true until this week. I think
changing back to that practice is imperative, albeit not enough of an
emergency to fix unilaterally without discussion here.
On 26 Nov 2017, at 12:04 (-0500), Dave Jones wrote:
The current 60_whitelist_spf.cf is 11 years old. What does everyone
think about starting a 60_whitelist_auth.cf and extending this list to
known good senders like *@alertsp.chase.com and
*@email.dropboxmail.com?
My SA platform has very good results with thousands of whitelist_auth
entries but 98% of the SA users are not going to know to create/manage
these entries themselves. Combined with other rules this also helps
with spoofing legit senders like the IRS, Bank of America, etc. I am
not suggesting we put thousands of entries in the new
60_whitelist_auth.cf but the common, high-profile, large senders that
often get spoofed.
The current list of def_whitelist_from_spf entries is very beneficial
and should be extended now that SPF and DKIM are widely deployed and
are being taken seriously by the major mail hosting providers like
Google.
Thanks,
Dave
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
