I'm going to skip to the end pretty quick... where I tell you exactly
the config YOU need (except I don't know your IPs, so you'll have to
fill that in).
Ross Boylan wrote:
Well, I've obviously missed something. In this message I will focus
exclusively on the question of whether a host that receives messages
from dial-up hosts should go on internal_networks. Assume for
simplicity I have a mail domain b.c. The MX records point to a.b.c.
I'm running SA on a.b.c for messages it receives. It might be at SMTP
time (in which case I don't think the received header for a.b.c is in
the message yet) or later.
Also, I'm talking about messages received from the internet at large,
not from my own users.
Here's why I thought such a host did not go on internal_networks:
================================================================
1) Mail::SpamAssassin:Conf says "Trusted relays that accept mail
directly from dial-up connections should not be listed in
internal_networks."
2) My original post and the first reply were
[Ross] 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?
[Daryl] Yeah, that's pretty good.
3)
[Daryl] 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
Since I'm accepting mail from the internet at large, it doesn't seem any
of these apply, and so the machine should not be on internal_networks.
It is true the machine is picky about who it will send mail to the
internet on behalf of (namely, on itself in this simple case).
1 and 3 could apply. 2 might but probably isn't realistic.
And here's why it now seems such a host should go on internal_networks:
======================================================================
10)
[Daryl] 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.
*must* *must* *must* If the server is acting as an MX then it *must*
*must* *must* go in internal networks regardless of anything else.
11)
[Ross] I thought it was internal only if I was sure it wasn't
accepting mail
from questionable IP's, and I'm not.
[Daryl] 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.
So, in the situation above, is my system "directly accepting mail from client IPs
that you WANT to accept mail from"? I'm not sure of the significance of
the words "directly" or "client". In particular, does "client" mean
client as in client/server, in which case any system contacting my
server is a client, or something more specific? And does "direct"
somehow refer to the distinct roles my mail server plays (see point 20
below), even though it's one program?
Client means the computer and the associated person that has two legs
and a heartbeat.
Directly means they send the mail directly to your server (ie. they've
set smtp.your.server.com.org.net.blah. as their outgoing SMTP server in
their mail client).
In your case (as I now know from below) you've got a combined MX/MSA so
by the rule "the MX is always internal" you *must* satisfy one of my
original three options as quoted above.
The options apply to your own clients, as described immediately above.
My reading is that the server directly accepts all connections, so it
fails this test and doesn't belong in internal_networks. But that's
clearly not the intended meaning.
If it was just an MSA then it'd only be trusted and not internal. Since
it's also an MX you MUST set it as internal (MXes are *always* internal)
and then satisfy one of the requirements (three options quoted above)
that allow you to include your MSA in the internal network config.
12)
[Daryl]
To be clear though, there is ALWAYS at least one host listed in your
internal_networks. Always.
That's easy: there is only one host I might list here, so clearly this
means I do list it.
Yeah. One host in your entire mail server setup, it's both trusted and
internal.
13)
[Daryl]
No. a.b.edu is an MX. ALL MXes MUST be in both trusted and internal
networks.
I assume that means all *my* MXes.
MXes for the domains you are scanning mail for. Which is probably your
MXes and none of mine. :)
Finally, there was something that just puzzled me:
=================================================
20)
[Daryl] You don't receive mail from smarthosts and smarthosts don't
handle mail for domains.
[Ross] Well, the same machine that is acting as a smarthost for my outbound
mail is also receiving mail for me.
[Daryl] 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.
Those are the points in item 3) above. This means the server must
conform for SA to work? It must conform for SA to work optimally?
It must conform for SA to properly score mail from your own clients
(those computers with people you know attached to them, using your
server as an MSA). Otherwise you run the risk of looking up your own
clients in dynamic IP blacklists, etc and penalizing them for doing what
they are supposed to be doing.
It must conform to be a good internet citizen (not an open relay)?
The rest of the net couldn't care less. This will only affect the
scoring of your own clients' mail in your installation of SA.
What if
it doesn't conform? Some of the options seem to refer to the setup of
the mail server itself (the first option), while some refer to the
configuration of SA (the last 2 options).
If it doesn't conform your clients' mail will likely be scored against
their favour (as above).
Yes, the first solution is a mail server config option (Exim supports
this unless I've gone nuts).
The second and third solution are done in the SA config.
Some people may use more than one of the solutions. It all depends on
how your users authenticate with your MSA.
In the same vein, Daryl wrote
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.
Conclusion
==========
So how can all the previous items (removing my interpretations) be true?
I think I may be missing some distinction between MX, MTA, MSA, and
relay, which I tend to collapse since the same box and the same program
(exim) is performing all these roles.
In particular, I'm not familiar with the concept of an MSA. Should I
think MTA when mail comes from the internet to my system, and MSA when
it goes from my system to the internet? What about mail entirely within
my system?
MSA accepts mail from your own authenticated clients (people using, say
Outlook Express or any other MUA).
MTA sends mail to other mail servers.
MX receives mail from MTAs.
P.S. What does FP mean? Spam points?
False positive.
OK, here's a setup specifically for you (add each relevant line marked
with a *, but don't include the * in your actual config):
* trusted_networks 1.2.3.4
Don't bother declaring internal_networks, it'll get copied automatically
(and the POPAuth plugin, if you need it, doesn't currently work right
when internal_networks are manually configured).
If you know of some static IPs your clients (MUA users) use then add
them to your trusted_networks. If you had a directly connected network
using some RFC 1918 address you might add:
* trusted_networks 10.1.100.0/24
If your clients connect to your MSA using SMTP AUTH, then you don't have
to do anything for those clients... SA will take care of it as long as
the received header added by your MSA says something like "with ESMPTA".
If you've got clients using POP-before-SMTP, then you'll need to add the
POPAuth plugin available here:
http://wiki.apache.org/spamassassin/POPAuthPlugin
That's it. If you tell me specifically how all of your clients (two
legged people with heartbeats using MUAs) authenticate with your MSA I
can be even more specific in you exactly you need to configure your setup.
Note: I have nothing against one legged people, or even people without
legs. I'm just generalizing.
Daryl
