Why emails relayedfrom trusted/internal networks trigger rules?

[Palvelin Postmaster <po...@palvelin.fi>]

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?

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⁩
Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)
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 info@xxxxxxxx.com; Mon, 23 Apr 2018 06:35:44 +0300⁩
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 <in...@obesus.fi>; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix) id DCA21C000C; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix, from userid 0) id D6BF2C010F; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩


--
Palvelin.fi Hostmaster
postmaster@palvelin.fi

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[Matus UHLAR - fantomas <uh...@fantomas.sk>]

On 26.04.18 10:04, Palvelin Postmaster wrote:
>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?

because you feed the messages to spamassassin. SpamAssassin has no option
for ignoring messages, if you really want to avoid spamassassin, then avoid
spamassassin and don't feed messages into it.

SA options trusted_networks and internal_networks are used for better spam
detection - there is still possibility of spam soming from trusted server,
SA only believes that the trusted server does not fake real sender (in the
Received: header).

see https://wiki.apache.org/spamassassin/TrustedRelays

>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⁩
>Received: ⁨by palvelin.fi (CommuniGate Pro PIPE 6.2.3)
>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 info@xxxxxxxx.com; Mon, 23 Apr 2018 06:35:44 +0300⁩
>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 <in...@obesus.fi>; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
>Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix) id DCA21C000C; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩
>Received: ⁨by ip-172-31-26-125.eu-central-1.compute.internal (Postfix, from userid 0) id D6BF2C010F; Mon, 23 Apr 2018 06:35:43 +0300 (EEST)⁩

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[RW <rw...@googlemail.com>]

On Thu, 26 Apr 2018 16:21:01 -0400
Bill Cole wrote:

> On 26 Apr 2018, at 3:04 (-0400), Palvelin Postmaster wrote:
> 

> > 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.


Aside from disabling ALL_TRUSTED, unparseable received headers are
simply ignored. Actually I think that pattern is parsed as a header
that should be explicitly skipped.


> 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.

The headers do parse correctly provided that you remove the invisible
unicode isolates in the email text. They presumably weren't present at
the time of the scan or no IP addresses would have been found. 

Everything here is consistent with the OP leaving-out 172.16.0.0/12 from
from the trusted/internal networks.

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[Bill Cole <sa...@billmail.scconsult.com>]

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 
> info@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 <in...@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Why emails relayedfrom trusted/internal networks trigger rules?

[RW <rw...@googlemail.com>]

On Thu, 26 Apr 2018 10:04:32 +0300
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?

internal_networks and trusted_networks aren't there to avoid scanning
(although there is an ALL_TRUSTED rule with a negative score), they are
there to help SA determine which relays are relevant to certain tests. 

However, HELO_DYNAMIC_IPADDR and RDNS_DYNAMIC shouldn't be there if
your network settings are correct.

You mention listing 52.28.104.67, but not 172.16.0.0/12.  When you
specify internal or trusted networks you then have to include any
relevant RFC 1918 address blocks.