[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-users
Subject:    Re: Trusted network mail spam detection
From:       Simon Wilson <simon () simonandkate ! net>
Date:       2019-10-17 7:43:49
Message-ID: 20191017174349.Horde.Iy9cHbhCKWD1EV1gkKyNzTO () mail ! simonandkate ! net
[Download RAW message or body]


Quoting Bill Cole <sausers-20150205@billmail.scconsult.com>:

> > > > > RDNS_DYNAMIC tries to exclude authenticated email. Are you  
> > > > > accepting email from senders without authentication? Or maybe  
> > > > > your trusted_networks/internal_networks are misconfigured, so  
> > > > > the authentication is not properly detected?
> > > > 
> > > > Example - user goes to my webmail site, logs in from his dynamic  
> > > > IP, sends an email from Chrome.
> > > > 
> > > > The email from the big bad world is sent through https Horde at  
> > > > my external IP, and the Horde webserver (internally 'emp06' @  
> > > > 192.168.1.230) submits it to postfix on the mail server on port  
> > > > 587, authenticated only.
> > > [...]
> > > > SA is then called. SA config includes (/etc/mail/spamassassin/local.cf):
> > > > 
> > > > trusted_networks 192.168.1. 119.18.34.29
> > > > internal_networks !192.168.1.230 192.168.1. 119.18.34.29
> > > > score ALL_TRUSTED -2.0
> > > > 
> > > > By which I wanted it to see my local subnet 192.168.1.0/24 as  
> > > > internal, but see the Horde webserver (.230) as the first point  
> > > > under my control, which was how I read:  
> > > > https://cwiki.apache.org/confluence/display/spamassassin/TrustPath and  
> > > > https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html
> > > > 
> > > > But... looking at it now and your comment I think I have that  
> > > > incorrectly set and should drop the !192.168.1.230 ? Some advice  
> > > > there would be appreciated...
> > > 
> > > Drop the '!192.168.1.230' from internal_networks. Add  
> > > '192.168.1.230' to msa_networks.
> > > 
> > > trusted_networks is for hosts you trust to not forge (or  
> > > obfuscate) Received headers or originate spam.
> > > internal_networks is for hosts you trust to not forge (or  
> > > obfuscate) Received headers or originate spam, whose detectable  
> > > authentication of senders you trust, but which may relay mail from  
> > > unauthenticated senders.
> > > msa_networks is for hosts you trust to ONLY offer you mail from  
> > > authenticated users.
> > > 
> > > A different viable option (if internal_networks & msa_networks are  
> > > too strong for you) is to construct compensatory meta-rules to  
> > > conditionally reverse (maybe only partially) the high scores of  
> > > RDNS_DYNAMIC and HELO_DYNAMIC_IPADDR2, e.g.:
> > > 
> > > meta      TRUSTED_USERS  ( RDNS_DYNAMIC || HELO_DYNAMIC_IPADDR2 )  
> > > && ALL_TRUSTED
> > > score     TRUSTED_USERS  -2.0
> > > describe  TRUSTED_USERS  Dynamic address submitters to trusted hosts.
> > > 
> > > 
> > 
> > Thanks Bill, very informative.
> > 
> > I've altered local.cf, and sent myself an externally originated  
> > test message (I'll save the meta rule for later when I understand  
> > what is happening).
> > 
> > trusted_networks 192.168.1. 119.18.34.29
> > internal_networks 192.168.1. 119.18.34.29
> > msa_networks 192.168.1.230
> > 
> > So trusted_ and internal_ both reflect my internal IP range  
> > (including the internal address of the Horde webserver) and my MX /  
> > external address (which is also external IP for the Horde webserver  
> > - is that an issue?).
> > 
> > Test result to myself:
> > 
> > X-Spam-Status: No, score=2.134 tagged_above=-999 required=6.2
> > 	tests=[ALL_TRUSTED=-2.4, BAYES_50=0.8, DKIM_ADSP_ALL=0.8,
> > 	HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001]
> > 	autolearn=no autolearn_force=no
> > Received: from mail.simonandkate.net ([127.0.0.1])
> > 	by localhost (mail-amavis.simonandkate.net [127.0.0.1])  
> > (amavisd-new, port 10026)
> > 	with LMTP id Kj_HtGN_pHXs for <simon@simonmwilson.net>;
> > 	Thu, 17 Oct 2019 07:32:43 +1000 (AEST)
> > Received: from [127.0.0.1] (localhost [127.0.0.1])
> > 	by mail.simonandkate.net (Postfix) with ESMTPSA id 20C5F3050A92
> > 	for <simon@simonmwilson.net>; Thu, 17 Oct 2019 07:32:43 +1000 (AEST)
> > Received: from pa49-197-19-57.pa.qld.optusnet.com.au
> > (pa49-197-19-57.pa.qld.optusnet.com.au [49.197.19.57]) by
> > mail.simonandkate.net (Horde Framework) with HTTPS; Thu, 17 Oct 2019
> > 07:32:40 +1000
> 
> That's helpful...
> 
> I had not understood that your webmail and MTA were on the same  
> machine, so that the Received headers never refer to 192.168.1.230  
> at all, just to 127.0.0.1. You may find success by adding the  
> loopback to msa_networks.
> 
> OR maybe not. But I think so. Probably. SA is obviously trusting  
> that header (because 127.0.0.1 is always in trusted_hosts unless you  
> clear it) and parsing it to find the dynamic HELO & rDNS.
> 
> 
> > I do note that the 4th score for e.g. HELO_DYNAMIC_IPADDR is  
> > triggering (1.951) not the 3rd which triggered on the other email I  
> > was using to test (I've asked them to resend as well), which from  
> > doc tells me that this means Bayes and network tests are triggering.
> > 
> > Adding the MSA has not removed the tests running - but is the  
> > different score parameter a result of the change?
> 
> The previous message triggered HELO_DYNAMIC_IPADDR2 not  
> HELO_DYNAMIC_IPADDR, according to the report that you quoted in your  
> first message. That is what accounts for the different scores.
> 
> 
> -- 
> Bill Cole

Hi Bill, thanks for the help and support :)

Externally I have one public IP address, which is both MX for my  
domain and also host for the Horde webserver. So externally - yes, MTA  
and webhost are "the same". Internally, they are separate: .230 for  
the web host, .235 for the MTA.

Internally the MTA's hostname resolves to a local IP, not the MX:

# ping mail.simonandkate.net
PING emp06.simonandkate.lan (192.168.1.230)

BUT!! Your comments got me thinking, and you know how a lightbulb goes  
on sometimes? I had a header rewrite that was put in place a long time  
ago, that was taking OUT the 192. internal addressing info. Old times,  
pretty pointless security through obfuscation... along the lines of  
this:  
http://realtechtalk.com/Postfix_how_to_secure_outgoing_authenticated_emails_for_privacy_and_hide_the_IP_address_mailer_and_other_things-1573-articles


I took that out, and tried again. Now the headers:

X-Spam-Status: No, score=-0.799 tagged_above=-999 required=6.2
	tests=[ALL_TRUSTED=-2.4, BAYES_50=0.8, DKIM_ADSP_ALL=0.8,
	HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.simonandkate.net ([127.0.0.1])
	by localhost (mail-amavis.simonandkate.net [127.0.0.1]) (amavisd-new,  
port 10026)
	with LMTP id bhg52kh3MlO4 for <simon@simonmwilson.net>;
	Thu, 17 Oct 2019 17:11:32 +1000 (AEST)
Received: from emp06.simonandkate.lan (emp06.simonandkate.lan [192.168.1.230])
	by mail.simonandkate.net (Postfix) with ESMTPSA id AFE373050A92
	for <simon@simonmwilson.net>; Thu, 17 Oct 2019 17:11:32 +1000 (AEST)

The "first" public IP 'Received: from' entry has been removed entirely  
(so is that triggered by SA now correctly detecting trust?), the MSA  
shows correctly as the first source, and the RDNS sigs etc. are not  
being triggered. Bingo... I think that is now working like it is  
supposed to. Thank you very much... (y)

Is there *any* point in rewriting / anonymising headers? As it is now  
configured I just have it removing User Agent, but that seems pretty  
pointless. What is being left after SA and amavisd finish processing  
the authenticated outbound email seems pretty harmless...

I now have the following in local.cf and it seems to be working OK,  
but I'll keep an eye on it.

trusted_networks 192.168.1. 119.18.34.29
internal_networks 192.168.1. 119.18.34.29
msa_networks 192.168.1.230
score ALL_TRUSTED -1.4

Thanks again.

-- 
Simon Wilson
M: 0400 12 11 16


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic