On 11 Apr 2016, at 10:55, Helmut Schneider wrote:

Hi,

for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without success.

Did it just start showing up 6 months ago on a previously-working SpamAssassin installation, of was SA just set up 6 months ago and has been broken the whole time?

I have read https://wiki.apache.org/spamassassin/TrustPath and
https://wiki.apache.org/spamassassin/FixingAllTrusted carefully, put

trusted_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
internal_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
add_header all RelaysUntrusted _RELAYSUNTRUSTED_ (this does not seem to
work at all, no header seems added)

into local.cf and still ALL_TRUSTED gets fired. Any help would be
appreciated.

mail:~$ sudo spamassassin -V
SpamAssassin version 3.4.0
  running on Perl version 5.18.2

There have been some issues fixed since 3.4.0 that MIGHT be related to this, particularly if you're using Net::DNS v1.0x where x<5. The details of that are rather arcane and involve problematic code on both sides, but it can be fixed IF that's the root cause.

The next step you should try in figuring this out is to strip down the message to what Amavisd was given by removing everything before this header:

Received: from XXX (XXX [172.20.12.10])
                 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
                 (No client certificate requested)
                 by XXX (Postfix) with ESMTPS
                 for <XXX>; Mon, 11 Apr 2016 15:01:32 +0200 (CEST)

Pipe that message into "spamassassin -t -D dns,received-header,metadata" *running as the same user that runs your Amavisd* and examine the first ~20 line of the debug output, which will show you how SA is parsing those Received headers as well as what version of Net::DNS you're using.

One oddity I noticed in your example that may cause trouble is that there was no Return-Path header or any other header that SpamAssassin would use in lieu of an explicit "envelope_sender_header" setting, until deep into the headers where SA may not be looking. That should not be capable of causing a wrong ALL_TRUSTED result, but it is something you should try to fix.

Reply via email to