determining trusted_networks via MX lookup

[Gerd von Egidy <li...@egidy.de>]

Hi,

consider the following mail setup:

sender -> ISP -> customer mailserver (running SA)

Currently the ISP's mail server isn't automatically added to trusted_networks 
but this has to be done manually.

Wouldn't it make sense to determine the MX hosts of the target domain via DNS 
and dynamically add them to trusted_networks?

How about the following setup:

sender -> ISP-MX -> ISP-forwarding server -> customer mailserver (running SA)

In this case the ISP's forwarding server will not be within trusted_networks 
and the trust chain breaks. How about additionally trusting all 
Received-Headers until one of the MXs for the domain appears for the first 
time?

Do you see any problems (e.g. holes for spammers) with this logic?

Do you think this will help reducing the need to configure trusted_networks by 
hand?

Kind regards,

Gerd

Re: determining trusted_networks via MX lookup

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

Gerd von Egidy wrote:
> Hi Matt,
>
>   
>>> Do you see any problems (e.g. holes for spammers) with this logic?
>>>       
>> The only problem I see is split-DNS configurations where there's an
>> internal server (ie: exchange) being used as the MX in the internal
>> view. As a result, SpamAssassin might see a completely different host as
>> the MX than the outside world.
>>     
>
> You are right. I did not think about this but know that it is not an uncommon 
> setup.
>
>   
>> Personally, I think a better way to go would be to have a config option
>> that selects whether the first public is trusted or not. This way the
>> end user could choose which of the two guessing methods to use.
>>     
>
> Using the first public address is a good idea.
This is pretty close to what SpamAssassin does. Currently SA uses the 
first public, but it is not selectable which way it goes. Currently, it 
is always assumed to be the MX, therefore trusted. However, anyone with 
a static mapped NAT (which is now VERY common) gets the wrong trust 
values, because the first public is actually an outside host.

>  It will help in most cases but 
> not work with the following setups:
>
> 1. the ISP running the MX uses different servers for MX and storage or 
> forwarding. The storage/forwarding server will in be the first public 
> received line but not the real MX.
>
> 2. Use of public addresses in the local network (e.g. within a DMZ or because 
> of misuse of public addresses)
>
> I have especially seen case 1 at a lot of bigger ISPs. I'm still thinking how 
> to fix it.
>   
At that point, I think you're getting into sufficiently exotic (or in 
some cases stupid) configurations that you might just have to break down 
and manually configure trusted_networks.

In general, this is a fundamental problem I, and other members of the SA 
team have given a lot of thought to over the years. There's really no 
good way that covers all scenarios. However, it would be nice to cover a 
larger swath than we currently do.

Re: determining trusted_networks via MX lookup

[Gerd von Egidy <li...@egidy.de>]

Hi Matt,

> > Do you see any problems (e.g. holes for spammers) with this logic?
>
> The only problem I see is split-DNS configurations where there's an
> internal server (ie: exchange) being used as the MX in the internal
> view. As a result, SpamAssassin might see a completely different host as
> the MX than the outside world.

You are right. I did not think about this but know that it is not an uncommon 
setup.

> Personally, I think a better way to go would be to have a config option
> that selects whether the first public is trusted or not. This way the
> end user could choose which of the two guessing methods to use.

Using the first public address is a good idea. It will help in most cases but 
not work with the following setups:

1. the ISP running the MX uses different servers for MX and storage or 
forwarding. The storage/forwarding server will in be the first public 
received line but not the real MX.

2. Use of public addresses in the local network (e.g. within a DMZ or because 
of misuse of public addresses)

I have especially seen case 1 at a lot of bigger ISPs. I'm still thinking how 
to fix it.

Kind regards,

Gerd

Re: determining trusted_networks via MX lookup

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

Gerd von Egidy wrote:
> Do you see any problems (e.g. holes for spammers) with this logic?
>   
The only problem I see is split-DNS configurations where there's an 
internal server (ie: exchange) being used as the MX in the internal 
view. As a result, SpamAssassin might see a completely different host as 
the MX than the outside world.

> Do you think this will help reducing the need to configure trusted_networks by 
> hand?
>   
No, I think it would, yet again, make it a different set of people who 
need it.

Personally, I think a better way to go would be to have a config option 
that selects whether the first public is trusted or not. This way the 
end user could choose which of the two guessing methods to use.