Sidney Markowitz wrote:
Daryl C. W. O'Shea wrote, On 24/10/06 8:31 AM:
I don't see any benefit in trying
to be helpful and further complicating how the
trusted/internal networks config works.
In theory that sounds nice, but it violates the principle of least
surprise.
SA including any IP on its own, after you've explicitly configured it
yourself, would certainly be surprising to me.
If you were to use clear_trusted_networks first this wouldn't happen,
but having to do this first doesn't make sense to me either. Why should
the first step in configuring something manually have to be clearing a
config you haven't already configured?
Consider an ISP that has SpamAssassin working fine using the
default for the trust path that includes private network ip addresses in
the trusted and internal networks. A user gets a gmail address that is
configured to forward to the ISP address. They add the gmail server ip
addresses to their trusted_networks in their user_prefs. Now the trusted
path is broken because they did not include the private ip addresses in
their trusted networks, even though there is no reason for them to be
aware of the specifics of the ISP's trusted_networks configuration.
Not only would it not work because they didn't include the private
IP(s), it wouldn't work because they didn't include their ISP's public
IP(s).
Forgetting that the ISP's public IP(s) need to be added, why when adding
other IPs they see in their forwarded mail headers would they not
include 127.0.0.1 if it appears in those headers?
If we were to include 127.0.0.1, why would they not expect that we also
include other addresses that are quite likely to appear in the headers
such as 10/8 (or any other address we consider private when inferring
the config)? Why would SA including these addresses, when you've
configured something else on your own, NOT be surprising?
To put it another way, a user adding a trusted_network configuration
line in user_prefs should not have the side effect of preceding it with
an invisible clear_trusted_networks option when the system local.cf is
using the default trusted_networks but not when local.cf has an explicit
trusted_networks option. Users should not have to know the details of
local.cf to configure their own user_prefs.
This really has nothing to do with whether we include some private
addresses in the manual configuration by default, or not, as the same
thing is going to happen either way.
If the local site config does not explicitly set their trusted network
and is relying on SA to infer it's public IPs, any config in a
user_prefs file is going to be wrong if it doesn't also include these
public IPs. The same thing happens with any other IP that we'd normally
infer.
As it is now, in a setup that allows users to add trusted/internal
networks to their user_prefs config the local site config *must* also
manually configure their trusted/internal networks. This seems
reasonable to me too, if (as the site admin) you feel your users can't
rely on SA inferring things, you shouldn't either.
If we wanted to "fix" this (and I'm open to fixing this, rather than
adding defaults to the manual config), we'd be far better off getting
the whole site vs. user config issue fixed first (with everything in
arrays and accessors, etc.) before hackishly mangling the
trusted_networks config structures.
Daryl
