Re: trusted_networks default settings too permissive?

[ha...@t-online.de]

I am getting more and more confused :)

If the sender is a NATed box in 192.168/16 space, and the receiver also is a NATed box
in 192.168/16, rhe received message will have a by 192.168.xx.yy, and seemingly never
left the trusted network.
If you change trusted networks to 127. or your public ip, then mails from the local net will
come from outside the trust zone.
The real solution should be to teach the MTA to use the public ip in the "received by" part
for mails received from the internet, and its local ip otherwise.
This may be hard to achieve :)
It should be possible, however, to setup the mailserver with two local ip's, and send local
mails to one of them, and external mails to the other.
Now, how do I declare to SA that mails received by 192.168.2.11 come from the trusted network,
while those received by 192.168.2.10 are untrusted?

Wolfgang Hamann

>> OK, after more R'ing TFM and some kind advice from a list member, I
>> think I understand now what has been happening.
>> 
>> >From the Mail::SpamAssassin::Conf man page:
>> 
>> *   if the ?from? IP address is on the same /16 network as the top
>> Received line?s ?by? host, it?s trusted
>> 
>> *   if the address of the ?from? host is in a reserved network range,
>> then it?s trusted
>> 
>> *   if any addresses of the ?by? host is in a reserved network
>> range, then it?s trusted
>> 
>> So the solution is to add these two lines to local.cf:
>> 
>> clear_trusted_networks
>> trusted_networks        127/8 24.173.79.19/32
>> 
>> IIUC this sets any traffic which originates from my server as trusted,
>> but all other traffic is not.
>> 

>> > trusted!  That seems too permissive to me.  Am I still not understanding
>> > trusted_networks correctly?
>> 
>> Yup.  Those are on the other side of an *un*trusted network, so they don't
>> count.
>> 
>> Trusted networks determine where the trust stops.  It doesn't (so far as I
>> know) restart after that.
>> 
>>         Loren
>> 
>> 

Re: trusted_networks default settings too permissive?

[Thomas Cameron <th...@camerontech.com>]

On Mon, 2004-12-06 at 01:30 -0500, Matt Kettler wrote:
> At 03:40 PM 12/6/2004 +1300, Jason Haar wrote:
> >>Ahh, but this can never happen over the open internet. When the NATed 
> >>sender sends mail to your NATed server, the server will not see the mail 
> >>as coming from 192.168/16. It will see the sender's public, post-nat IP.
> >
> >To put it more bluntly, the trusted_networks checks are only against the 
> >last (i.e. newest) Received: header IP addresses.
> 
> That's just false. Completely false. Trusted will work it's way back from 
> the newest Recieved header and continue until it hits one with an untrusted 
> host. There's no limit to the number of Received: headers it can consider 
> trusted. It certainly can trust more than just the one.
> 
> The OP was suggesting that this could cause problems if both sides NATed 
> and you trust 192.168/16. But that can't happen, because the NATed source 
> will still appear as an untrusted IP, not 192.168./24, stoping the trust 
> path cold.
> 
> >So for your gateway to be receiving the SMTP connection, that Received: 
> >header would contain a real Internet IP address - or it was a connection 
> >from one of your own internally-NATted IP addresses - either way, the 
> >check should work.
> 
> Yes, that's fine, but SA does have trust issues if your mailserver itself 
> is NATed and will resolve it's own "by xxx.example.com" name as a reserved IP.
> 
> >I too was having difficulty with ALL_TRUSTED firing on incoming Internet 
> >mail a month ago, but it's all fixed now (I don't know if 3.0.1 fixed it? 
> >Can't remember)
> 
> Shouldn't have. There's been no change to the trust code, or ALL_TRUSTED in 
> 3.0.1 vs 3.0.0. Perhaps you set trusted_networks?

Let me tell you what I'm seeing...

I set 127/8 and 24.173.79.19/32 as trusted networks.  ALL_TRUSTED fired
on a (spam) message which had 127.0.0.1 in the headers, even though that
machine was the originator of the message.

I now only have 24.173.79.19/32 as a trusted network (which seems silly
to me - it's not a network, it's a host).

Thomas

Re: trusted_networks default settings too permissive?

[Matt Kettler <mk...@comcast.net>]

At 03:40 PM 12/6/2004 +1300, Jason Haar wrote:
>>Ahh, but this can never happen over the open internet. When the NATed 
>>sender sends mail to your NATed server, the server will not see the mail 
>>as coming from 192.168/16. It will see the sender's public, post-nat IP.
>
>To put it more bluntly, the trusted_networks checks are only against the 
>last (i.e. newest) Received: header IP addresses.

That's just false. Completely false. Trusted will work it's way back from 
the newest Recieved header and continue until it hits one with an untrusted 
host. There's no limit to the number of Received: headers it can consider 
trusted. It certainly can trust more than just the one.

The OP was suggesting that this could cause problems if both sides NATed 
and you trust 192.168/16. But that can't happen, because the NATed source 
will still appear as an untrusted IP, not 192.168./24, stoping the trust 
path cold.

>So for your gateway to be receiving the SMTP connection, that Received: 
>header would contain a real Internet IP address - or it was a connection 
>from one of your own internally-NATted IP addresses - either way, the 
>check should work.

Yes, that's fine, but SA does have trust issues if your mailserver itself 
is NATed and will resolve it's own "by xxx.example.com" name as a reserved IP.

>I too was having difficulty with ALL_TRUSTED firing on incoming Internet 
>mail a month ago, but it's all fixed now (I don't know if 3.0.1 fixed it? 
>Can't remember)

Shouldn't have. There's been no change to the trust code, or ALL_TRUSTED in 
3.0.1 vs 3.0.0. Perhaps you set trusted_networks?

Re: trusted_networks default settings too permissive?

[Jason Haar <Ja...@trimble.co.nz>]

Matt Kettler wrote:

> Ahh, but this can never happen over the open internet. When the NATed 
> sender sends mail to your NATed server, the server will not see the 
> mail as coming from 192.168/16. It will see the sender's public, 
> post-nat IP.
>

To put it more bluntly, the trusted_networks checks are only against the 
last (i.e. newest) Received: header IP addresses. So for your gateway to 
be receiving the SMTP connection, that Received: header would contain a 
real Internet IP address - or it was a connection from one of your own 
internally-NATted IP addresses - either way, the check should work.

I too was having difficulty with ALL_TRUSTED firing on incoming Internet 
mail a month ago, but it's all fixed now (I don't know if 3.0.1 fixed 
it? Can't remember)

BTW: I've set mine to

clear_trusted_networks
trusted_networks 127/8 172.30/12 10/8 192.168/16

...which should be the defaults anyway? Basically I just listed the 
official private IP address-spaces - they'll never be seen on incoming 
Internet connections.

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

Re: trusted_networks default settings too permissive?

[Matt Kettler <mk...@comcast.net>]

At 05:44 PM 12/5/2004 +0000, hamann.w@t-online.de wrote:
>I am getting more and more confused :)
>
>If the sender is a NATed box in 192.168/16 space, and the receiver also is 
>a NATed box
>in 192.168/16, rhe received message will have a by 192.168.xx.yy, and 
>seemingly never
>left the trusted network.

Ahh, but this can never happen over the open internet. When the NATed 
sender sends mail to your NATed server, the server will not see the mail as 
coming from 192.168/16. It will see the sender's public, post-nat IP.

In order to NAT, it actually has to be translated by the NAT before it can 
hit the internet. Anything which has nothing but reserved IPs, by 
definition, must never have been on the internet, as it never got 
translated to a public IP at any point.

ie: xan.evi-inc.com is NATed. If it were to send mail to this list, you 
would not see it's private IP, 192.168.50.6, as the server dropping off to 
apache.org. You'd see 208.39.141.86.

ie:
Received: from xan.evitechnology.com (HELO xanadu.evi-inc.com) (208.39.141.86)
   by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 02 Dec 2004 13:01:32 -0800