https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7500

Adrian Pepper <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.4.1                       |3.4.0

--- Comment #12 from Adrian Pepper <[email protected]> ---
Thanks to everyone for all the help.  I am chagrined and appreciate your
patience.

Everyone has pointed me to appropriate routes of experimentation.

I actually do not have access to the actual remote spamd server which exhibits
the problem.

I believe I misinterpreted some of what those administrators said in the past,
and thought they ran closer to stock than is the case.  Or perhaps in some
cases
they have brought forward past defaults via upgrades.  And, very sorry, along
the way I mixed up the spamc version and the actual remote spamd version.
The remote spamd server runs 3.4.0.

Obviously the remote spamd uses trusted_networks.  I have asked for the details
of those settings but not received any replies.  I also suspect they are using
a statistically incorrectly high negative value for ALL_TRUSTED, but cannot
fully verify that.

I have experimented in lxc containers on my workstation (3.4.0 and 3.4.1) and,
together with reading, it's not clear a private subnet is supposed to be
automatically assumed to be trusted for this purpose.

I get good results from adding something to match the
[fe80::d4bf:9432:cac5:5f3b]
to both trusted_networks and internal_networks.  (Adding to internal_networks
only generates an informational /var/log/syslog message suggesting you add it
to trusted_networks too).

I have not heard back from my contact with access to the spamd  server.

My experiments on my containers have the same difficulty triggering
RDNS_NONE at all (even for blatant examples), suggesting you need to do
something besides just having non-zero rules defined to trigger/enable the
test.

But at this point I can cause "ALL_TRUSTED" to appear or not, on those
experimental containers, more-or-less at will.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to