On 26 Apr 2018, at 3:04 (-0400), Palvelin Postmaster wrote:
Hi,
I relay mail from another server to my main mail server. I have set
its IP 52.28.104.67 in my spamassassin conf in the internal_networks
and trusted_networks. I assumed that would prevent spamassassin from
scanning the messages but no. Why does this happen?
Even when SA can recognize that a message is coming via only trusted
systems, by default it does not exempt the message from other scanning,
it simply hits the ALL_TRUSTED rule. That rule normally has a
significant negative score itself and is used to prevent matching in
many 'meta' rules.
X-Spam-Status: Yes, score=6.1 required=5.0
tests=AWL,DKIM_ADSP_NXDOMAIN,
HELO_DYNAMIC_IPADDR,NO_DNS_FOR_FROM,RDNS_DYNAMIC,T_RP_MATCHES_RCVD
autolearn=disabled version=3.4.1
Since proper determination of the "X-Spam-Relays-*" pseudo-headers
controls most of those hits as well as ALL_TRUSTED, getting that fixed
will almost surely be adequate. It will also help with other rules that
depend on identifying the boundaries between internal vs. external
and/or trusted vs. untrusted Received headers.
Received: by palvelin.fi (CommuniGate Pro PIPE 6.2.3)
That may be your first problem. SA can't parse that as a proper Received
header, which may trigger it to not classify the rest of the Received
headers correctly. It's hard to tell if this is causing trouble in this
case, because there are problems with the rest as well. With that said,
if you can make CGP use SA via an external filter rather than delivering
through the PIPE module, you'll get a more robust and performant
solution without this oddball Received header. For the 8+ years I ran
CGP systems, I used the free cgpav filter, but for modern CGP that needs
some patching to work. I seem to recall that cgpsa is also a free tool
that works.
Received: from [52.28.104.67] (HELO
ip-172-31-20-213.eu-central-1.compute.internal) by palvelin.fi
(CommuniGate Pro SMTP 6.2.3) with ESMTPS id 10108357 for
i...@xxxxxxxx.com; Mon, 23 Apr 2018 06:35:44 +0300
The Postfix MTA running on the AWS instance using 52.28.104.67 is
grossly misconfigured. It should use a EHLO/HELO name ( myhostname, or
smtp_helo_name if there's a reason myhostname can't be changed) that
resolves to 52.28.104.67 and also should have proxy_interfaces set to
52.28.104.67. It appears that
ec2-52-28-104-67.eu-central-1.compute.amazonaws.com would be a good
choice, but if that machine talks to anyone else you may want to post a
non-generic name at the IP and use that.
Received: from ip-172-31-26-125.eu-central-1.compute.internal
(ip-172-31-26-125.eu-central-1.compute.internal [172.31.26.125]) by
ip-172-31-20-213.eu-central-1.compute.internal (Postfix) with ESMTP id
ECF2CC0C32 for <i...@obesus.fi>; Mon, 23 Apr 2018 06:35:43 +0300
(EEST)
At this point, SA should have already given up parsing Received headers
so the fact that this and the remaining Received headers use RFC1918 IPs
and a generic name in a non-resolvable domain doesn't matter: SA cannot
trust these because the chain of trust and working DNS is already
broken.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
