Nothing trimmed in an attempt to keep things somewhat coherent...
Ross Boylan wrote:
Thank you for your very clear answers. I have a few follow-up questions
below.
On Fri, 2006-06-23 at 23:44 -0400, Daryl C. W. O'Shea wrote:
On 6/21/2006 4:39 PM, Ross Boylan wrote:
After reading the Mail::SpamAssassin::Conf (spamassassin 3.1.3-1 on
Debian) I was unclear about trusted vs internal networks. After
reviewing previous emails on this list, here's what I think it is:
trusted_networks for hosts I trust to put good info in the Received
headers.
internal_networks for those that are additionally trusted not to receive
email from IP's in dial-up RBL's.
Is that about right?
Yeah, that's pretty good.
....
If you don't set either of these (trusted/internal) then SA will attempt
to infer the correct settings on a per message basis. There's still no
default... and no contradiction.
Now that I understand the inference is on a per message basis, I have a
last question about defaults. Say you have specified neither trusted
nor internal networks (or have cleared both, which I think is the same
thing). Does the inference for trusted_networks carry over to
internal_networks?
Functionally it appears that both trusted_networks and internal_networks
are inferred.
They're not really both inferred though (internal_networks is just
copied/ignored where appropriate), but that's just implementation details.
3) Does clear_trusted_networks affect the inferred trusted networks?
If you clear your trusted/internal network settings and then don't
define any SA will have to attempt to infer the correct settings on a
per message basis... it's the only (semi-)logical thing to do.
...
However, my main confusion was the exact distinction between internal
and trusted networks. Under trusted_networks it says "MXes for your
domain(s) and internal relays should also be specified using the
internal_networks setting. When there are 'trusted' hosts that are not
MXes or internal relays for your domain(s) they should only be specified
in trusted_networks."
This had me wondering what would be sending mail that wasn't an MX or a
relay, and thinking that the key distinction between trusted_networks
and internal_networks was this MX and relay vs others.
So I was noticing the "not MXes or internal relays" above, but the "for
your domain(s)" is more important.
Yeah. Including other people's relays, even if you trust them, in your
internal_networks wouldn't be too sensible.
Also, since discussion on this list has emphasized that trusted means
"trust the receive headers," I can't see how it would be relevant to
anything but an MX. But I'm no expert in this area.
Other people's MTAs aren't your MXes or internal relays. I trust (and
configure in my trusted_networks on a few of my high volume MXes) a
number of my major customers' MTAs.
Does this mean that if an MX is not in your domain, but you know it
writes good headers and doesn't get dial-up mail, it still should not be
in internal_networks?
Correct. If it's not a relay for domains that you're scanning mail for
then it's not on your logical (and often physical) internal network and
thus doesn't get listed in your internal_networks.
The ONLY way a relay gets listed in your internal_networks is if it is a
part of the mail system for the domains your are scanning mail for AND
it's not an MSA (unless you work around the MSA restriction as below,
then it can be included too).
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.
For most people they won't have anything but their own MXes, MSA and
internal relays in their trusted_networks. Their internal_networks will
usually include only your MXes and internal relays.
MSA=? I take it MSA has something to do with dialup.
Mail Submission Agent... accepts mail from your own clients' MUAs (also
known as UAs).
You can not add your MSA to your internal_networks unless you can do one
of the following:
- have all your MSA users use SMTP auth AND use mail server software
that includes RFC 3848 or Sendmail-style auth tokens in it's received
headers
- include ALL of your MSA users' IP addresses in your trusted_networks
and internal_networks -- you can only do this if you control all of
the IP space in question and never have roaming users sending mail
from remote IP space (which is nearly never the case)
- use the POPAuth plugin to extend trusted_networks to POP-before-SMTP
clients if you use POP-before-SMTP for user authentication
Note: Only configure trusted_networks if you're using this plugin,
do not configure internal_networks
If you can do any of the above, you can include your MSA in your
internal_networks config (except for the POPAuth case). Since most
people will only include their own MXes, internal relays and MSA in
their trusted_networks this means that the internal_networks config
would be the same as the trusted_networks config. In this case you'd
only have to set one of them (and it's recommended that you'd set the
trusted_networks).
Finally, the discussion of internal_networks makes clear that the
statement "MXes for your domain(s) ... should also be specified using
the internal_networks" is wrong. MXes that get mail from dial-up hosts
do not belong in internal_networks. If this distinction based on
dial-up hosts is the key one, the names trusted_networks and
internal_networks seem pretty confusing to me.
Dial-up hosts shouldn't be sending mail directly to an MX. In the case
that you only have one server that acts as both your MX and your MSA
users are really sending mail to the MSA, not the MX. Of course they're
really the same thing, though, so you have to have a way to
differentiate your users from the rest of the world. You have two
options in this case:
- don't scan mail from your own users (using whatever means your mail
system software provides)
- use one of the three options noted above to extend SAs trust boundary
to your users
In either case, you MUST include this MX in your trusted_networks (and
internal_networks if defined) even though it is also being used as an MSA.
I'm wondering if I'm confused about the significance of dial-up hosts.
Your discussion centers on users who dial in to your server to send
mail. I was thinking about a different scenario, namely one in which
the sending host is on an IP that somebody indicates is assigned
dynamically, associated with home users, or otherwise a bit less
trustworthy. That IP is completely external to my domain(s). Are these
two situations equivalent for purposes of assigning *_networks, or
different?
Yes, equivalent. Dial-up, IP dynamically assigned, or any host that may
be listed in DNSBLs that you actually want mail from can all be
substituted above.
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.
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.
Do either of these conditions (getting mail from dynamic
IP's, servicing different domain) imply the host should not be in
internal_networks?
This secondary MX acting as an MSA for dynamic clients in no different
than the case described above with your primary MX acting as an MSA.
For mail from that systems "own" clients to be optimally handled that
system (or your SA config, which ever is appropriate) would have to meet
one of the three requirements previously outlined above.
Daryl
