Ross Boylan wrote:
On Wed, Jun 28, 2006 at 01:45:52AM -0400, Daryl C. W. O'Shea wrote:
Ross Boylan wrote:
For 99% of systems there's no need to worry about listing systems that
aren't a part of your mail network in your trusted_networks (and never
list them in your internal_networks). Keep it simple and just configure
your trusted/internal networks for your own systems as appropriate.
Originally I thought spamassassin checked only the sender immediately
outside trusted_networks, so it was important to expand
trusted_networks as far as reasonable. Having looked at the debug
output, I now see my initial impression was wrong. The IP's in the
Received headers are checked back through the whole chain, and
suspicious IP's give you spam points regardless of where they are in
the chain. Right?
Right... SA will check, based on the specific rule, the appropriate IPs
in the untrusted (and sometimes external but trusted) portion of the
received headers.
There's really no need to extend the trust boundary to third parties in
an effort to "try and catch IPs further down the chain". SA will do
this for you. Actually, trying to do so will probably end up in you get
FPs for some senders.
Also, I'm in a situation in which it's a little tricky to identify
"inside" and "outside." More on that below.
Inside and outside (trusted and untrusted) is really quite simple. If
you use someone else's system to accept mail on your behalf (someone
elses MX acts as a secondary MX for you) you must place trust on their
entire mail setup to achieve an optimal configuration.
All you're really doing is taking all of their trusted and internal
networks and adding them to yours.
........
My situation is that I often receive mail via a smarthost, and the
smarthost may not block all contact from questionable IP's. So I was
thinking this meant the smarthost should not go in internal_networks.
In view of the preceding information, I guess there may be another
issue, since the smarthost handles a different domain than the one my
machine is in.
You don't receive mail from smarthosts and smarthosts don't handle mail
for domains.
Well, the same machine that is acting as a smarthost for my outbound
mail is also receiving mail for me.
Yeah one physical server, many logical services. For such a server you
MUST conform to one of the three options outlined in my original email.
In sounds like you're saying that one of your MXes accept and forward
mail to a primary MX (probably without address verification, etc.). It
just so happens that that server is also acting as an MX and probably
MTA/MSA for another domain.
If this is the case (the server is acting as an MX for you -- it'd be
listed in one of your MX records) then you must include it in both your
trusted and internal networks.
I thought it was internal only if I was sure it wasn't accepting mail
from questionable IP's, and I'm not.
No. Internal only if it's not directly accepting mail from client IPs
that you WANT to accept mail from. MXes and everything (internal
relays) after them are ALWAYS in both trusted and internal networks.
This is what tells SA that mail was sent directly from "questionable
IPs" to your systems. It sees that some (questionable) IP sent mail to
an internal host without going through some external host first.
Maybe it will help to be concrete. I'll use made up names to foil
spambots:
People send me mail at [EMAIL PROTECTED] b.edu has an MX record. I use
fetchmail to pull my mail off a.b.edu, the actual host machine the MX
records points to. We have a weird setup; my machine's name
internally is c.d.net (not c.b.edu). So a.b.edu is getting mail for
me, but it doesn't even appear to have the same domain. a.b.edu may
also accept mail from IP's on RBL's.
So I think this means the IP for a.b.edu belongs on trusted_networks,
but not internal_networks. Right?
No. a.b.edu is an MX. ALL MXes MUST be in both trusted and internal
networks.
If a.b.edu also acts as an MSA for people then your config or that host
must conform to one of the three options originally noted.
I then forward this mail (at SMTP time as it is being delivered to
c.d.net) to [EMAIL PROTECTED], my home ISP. The mail is stored on e.f.com,
and I retrieve it via fetchmail to my machine g.h.us. g.h.us is also
reachable directly from the world, since h.us (a domain I control) has
an MX record.
I think that for g.h.us I should set trusted_networks to the IP's for
"g.h.us e.f.com a.b.edu" and no internal_networks. I guess from what
you say I could set trusted networks to IP's for "e.f.com g.h.us", or
even just "g.h.us". f.com was on an RBL briefly, so it needs to be in
trusted_networks to avoid false alarms.
No. EVERYTHING after an MX MUST be listed as BOTH trusted and internal
networks.
But if I don't specify internal_networks it will take on the value of
trusted_networks. And I thought from our prior discussion that
clear_internal_networks would have the same effect: at runtime, SA
sees a blank list and copies the value from trusted_networks. So how
do I say there's nothing in my internal_networks?
clear_internal_networks
internal_networks
?
Explained above that there are indeed hosts in your internal networks.
To be clear though, there is ALWAYS at least one host listed in your
internal_networks. Always.
Daryl
