On 2024-01-31 at 08:16:13 UTC-0500 (Wed, 31 Jan 2024 14:16:13 +0100)
Matus UHLAR - fantomas <uh...@fantomas.sk>
is rumored to have said:
On 2024-01-30 at 12:08:18 UTC-0500 (Tue, 30 Jan 2024 18:08:18 +0100)
Matus UHLAR - fantomas <uh...@fantomas.sk>
is rumored to have said:
[...]
autolearn may help if your DB is well maintained, although I have
disabled nearly all rules with negative scores, like
RCVD_IN_DNSWL_*
RCVD_IN_IADB_* DKIMWL_WL_*
RCVD_IN_MSPIKE_*
RCVD_IN_VALIDITY_*
USER_IN_DEF_*
ALL_TRUSTED
etc, because spammers often abuse these.
I mean, they may have negative score but don't train on them.
On 30.01.24 15:31, Bill Cole wrote:
If spammers can 'abuse' ALL_TRUSTED you have a major problem. Either
a serious misconfiguration or compromised machines in
trusted_networks.
Can't ALL_TRUSTED happen if spammer delivers mail directly to my
network,
or, if last mail server removes Received: headers?
I think this happened to me in the past but I may be wrong
I just did a manual test on my personal machine to confirm: mail entered
manually in a connection to port 25 from an unprivileged network with no
Received headers did NOT get an ALL_TRUSTED match.
The semantics around the word 'trusted' in SA are subtle and arcane.
There's an important distinction between trusting that a particular MTA
writes transparent and honest Received headers and trusting that a
particular MTA does not relay spam. For example, I have 2 address blocks
in my trusted_networks that are used by the ASF for forwarding, which I
needed precisely because those machines sometimes forward spam and I
need SA to look beyond the immediate clients, which I know tell me the
truth about where they get the spam they offer me.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
