PGNd wrote:
I'm running
postfix 3.0.1
amavisd-new-2.10.1 (20141025)
SpamAssassin version 3.4.1
on linux/64.
amavisd/spamassasin is invoked as a postfix prequeue proxy filter.
Spam is getting scanned and scored. Usually correctly.
Intermittenly, I get an email that gets SHORTCIRCUITED on ALL_TRUSTED
(example below).
I've read through https://wiki.apache.org/spamassassin/TrustPath, and
am missing something; I haven't yet managed to pick out the problem.
My SA config includes the following
internal_networks 127.0.0.0/8 10.2.2.0/24 10.1.1.0/24
X.X.X.X/29
trusted_networks 10.2.2.0/24 10.1.1.0/24
X.X.X.X/29
Here are headers for the received message. Note the shortcircuited
score:
X-Spam-Status: No, score=-101 tagged_above=-9999 required=5
tests=[ALL_TRUSTED=-1, SC_HAM=-100, SHORTCIRCUIT=-0.0001]
autolearn=disabled
the msg's received-from headers are _not_ all on my internal networks,
Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your
trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected.
grep Received: spam1.txt
INT Received: from mail-backend.DDDD.com (LHLO
mail-backend.DDDD.com)
INT Received: from relay-vpn.mail.DDDD.com (internal.mail.DDDD.com
[10.1.1.10])
INT Received: from localhost (localhost [127.0.0.1])
INT Received: from amavis-feed.mail.DDDD.com ([10.1.1.10])
INT Received: from localhost (localhost [127.0.0.1])
INT Received: from mail.DDDD.com ([127.0.0.1])
EXT Received: from relay09.smp.mweb.co.za (relay09.smp.mweb.co.za
[196.28.80.29])
EXT Received: from relay-mc01.smp.mweb.co.za ([196.28.80.61])
EXT Received: from [196.28.66.13] (helo=MWSJHBMC03)
If I 'spamassassin -D < spam1.txt' the message, it scores completely
differently
Jun 18 22:38:19.967 [19747] dbg: check:
tests=BAYES_50,DCC_CHECK,HTML_MESSAGE,UNPARSEABLE_RELAY
See the UNPARSEABLE_RELAY here? It prevents ALL_TRUSTED from firing.
Received: from mail-backend.DDDD.com (LHLO mail-backend.DDDD.com)
(10.2.2.20) by mail-backend.DDDD.com with LMTP; Thu, 18 Jun 2015
16:50:56 -0700 (PDT)
It is this Received header field above that is supposedly unparsable,
and it was added _after_ a message went though a content filter.
Remove it and re-try the command-line spamassassin test in the message.
Mark