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.
No, the X.X.X.X/29 is a different server -- one of my own, not in a 186. block,
and definitely not in ZA.
Jun 18 22:38:19.967 [19747] dbg: check:
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
/local.cf
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
etc, the msg's received-from headers are _not_ all on my internal networks,
What are the X.X.X.X/29 above? It can't
PGNd wrote:
The LHLO/LMTP header still is added at the backend, and
UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
problem with the parsing is.
It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
Please open a Bugzilla ticket and provide a sample of
your
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly intermittently, albeit now with a -1
score attached.
The LHLO/LMTP header still is added at the backend, and UNPARSEABLE_RELAY
Am 19.06.2015 um 16:31 schrieb PGNd:
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly intermittently, albeit now with a -1
score attached.
The LHLO/LMTP header still is added
UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
problem with the parsing is.
It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
Please open a Bugzilla ticket and provide a sample of
your Received header field (which is perfectly valid
according to RFC
amavisd seems to be involved in this issue; not sure whether it's the 'culprit'
or the 'victim'.
A 'ham' mail received through postfix+amavisd+spamassassin arrives with headers
...
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level:
X-Spam-Status: No,
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
