From: NFN Smith [mailto:[EMAIL PROTECTED]
>
> Bowie Bailey wrote:
>
>
> >>
> >>>X-Spam-Score: 6.87 (******) (required=4)
> >>>tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,
> >>>NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE
> >
> > I don't see ALL_TRUSTED, so apparently this email originated outside
> > of your network. Otherwise, there are no tests listed here that would
> > be affected by your trusted_networks settings.
>
> It's definitely coming from an external network.
>
> From the beginning, I've tried to emphasize that each of the
> servers in question are hosted in different co-lo facilities, with
> completely different blocks of IP addresses. We control all the
> servers, and they're definitely trusted, but they're not local to
> each other.
Yes, I understand that your servers are separated in different IP
blocks and in different facilities, but that is irrelevant. When I
say that the email is coming from an external network, what I mean is
that it is originating from a server that is not in your
trusted_networks list.
All of the servers that you control should be listed in
trusted_networks. This tell SA that it can trust the headers coming
from them and trust them not to originate spam.
> > That looks like a faked header. Is your server really called
> > "alpha.example.com"?
>
> Real data redacted for security reasons. I don't have the freedom to
> be more detailed in a public discussion. Yes, I know it makes
> troubleshooting more difficult this way.
I can understand not wanting to post email addresses, but IP addresses
are not private information in most cases. They get published in DNS
records and broadcast to anyone the server communicates with. If
we're dealing with internal network IPs, then I can understand. It
does, however make troubleshooting more difficult.
In this case, I don't think we really need to go there yet. At
the moment, we are mainly trying to establish how SA is supposed
to work. Once we agree on what is supposed to happen, then if
there was an email that didn't seem to be scored properly, I would
need to see the headers in order to diagnose the scoring.
> > As I said above, this looks like a normal email coming from
> > outside of your network. If it really originated inside your
> > network, then you need to fix your trusted_networks. Beyond that,
> > everything looks normal as far as I can tell from the information
> > provided.
>
> As noted, the message definitely originates in a different network.
>
> Let me make sure I have the problem definition correct --
>
> We have servers in several co-lo facilities, and each server hosts
> several domains, each with its own IP address. As noted, the
> domains and the servers are trusted, but they're in separate
> networks.
>
> The problem that we do have is that when we list our domains via
> whitelist_from, then incoming mail with forged From: lines that
> shows one of those domains (typically, the same domain as the
> addressee) is given a free pass.
As noted by Matt Kettler, whitelist_from is very dangerous for exactly
that reason. Don't use it.
> For this, there's no reason to trust the From: line as being valid,
> because it's so easily forged. However, if the message is coming
> from known trusted IP addresses, then that's reason to the message a
> pass, and either have SA give a low score, or not run SA at all.
>
> In short, in the question of how the message is handled, we want to
> trust the server IP address, but assume that the From: line is
> probably forged.
>
> From this discussion, I think I'm trying to do something outside the
> scope of what SA is designed to do, and the better way of getting
> there is the suggestion of doing it via MIMEDefang, and bypassing
> the call to SA altogether if the message is coming from a trusted
> (but non-local) server.
The solution to the problem depends on exactly what you want to
accomplish.
If you want the email to bypass scanning completely, then that needs
to be addressed outside of SA. Once a message is passed to SA, it
WILL be scanned -- there is no method to prevent it.
If you want to avoid local mail being marked as spam, this can be done
in SA with a combination of settings.
trusted_networks
Every mailserver you control (no matter what network it is on)
should be listed here. SA uses this list to determine from the
headers when the email entered your sphere of control. Your
servers will not be checked for blacklisting and the spam score
for the email will be reduced on emails that originate within your
control. This setting MUST be set correctly since it affects so
many other things in SA.
internal_networks
This should contain all of the mailservers listed in
trusted_networks except those that are expected to receive mail
directly from computers on dial-up connections. If none of your
mailservers receive mail directly from dial-up connections, you
can leave this empty and it will default to the same settings as
trusted_networks.
whitelist_from_rcvd
You can use this instead of whitelist_from. It requires a bit
more setup, but it is immune to the forgery problems of
whitelist_from. Use this to list each valid domainname/mailserver
combination. Note that this requires a correct internal_networks
configuration to work properly.
The bottom line is that there is no way to prevent an email from being
scanned once it gets to SA, but you can take steps to prevent it from
being marked as spam.
Also, SA doesn't care how widely scattered your MXs are as long as it
knows who they are. Don't think of it as multiple separate networks
containing mailservers, think of it as a single logical network
containing all of the mailservers you control.
Bowie
