On 6/30/2006 10:19 PM, Ross Boylan wrote:
On Fri, 2006-06-30 at 18:00 -0400, Daryl C. W. O'Shea wrote:
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."
Why doesn't this apply?
The docs are referring to hosts acting as MSAs. It probably doesn't say
MSA because so many people go, "what's an MSA". SA has a really diverse
user base.
Perhaps it should say "Trusted relays that are *intended* to 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.
Your interpretation of my interpretation, so let's just skip that one.
Throw an *intended* somewhere in there and it's all good.
[rules omitted]
If I understand what you're saying about the simple example, the machine
is acting as an MSA and MTA. Because it's an MTA and MX for my domain,
it has to go in trusted and internal_networks. Because it also acts as
an MSA, there are two possibilities:
a) it breaks the above rule.
Then SA's performance will be degraded, because it may flag some
internal users as being spammy.
b) fix the server or the configuration so one of the above conditions is
met.
Then things are good.
Right.
Or, I could just not run SA when I'm getting a message from an
authenticated user (I think you mentioned that possibility in an earlier
message). (I suppose this technique becomes difficult as the chain gets
indirect. In my real situation, for example, an authenticated user sent
a message to me at [EMAIL PROTECTED] He connected to the MX a.b.c with an
authenticated connection. I then pulled the message down with fetchmail
from a.b.c to my box q.r.s. The MTA on my box can not easily tell which
messages it pulls in from a.b.c are authenticated and which ones aren't,
so I need to have SA able to know what's going on.)
If there's no indication in the headers as to how they auth'd and you
don't know what the server's AccessDB or similar says about auth'd IPs
then you're out of luck.
Of course this is only problem when you have to trust the server that
accepted the mail from the user. ie. the server is acting as an MX or
relay for you.
So there really is a potential contradiction, because the rules for an
MTA as an MX say it must go in internal_networks, while the rules for an
MSA says it mustn't unless certain conditions are met (which they are
not in the example).
The "MX is always internal" rule has to take priority. If for whatever
reason, whether or not fetchmail is involved, a user submits mail to a
combined MX/MSA and you can't tell that it was auth'd (either by auth
tokens, IP address, or POPAuth) then that user is going to be subject to
DNSBL tests.
If that's a problem, it may be time to spring for a $12 a month VPS to
build a more robust mail network. Or just another IP on the existing
server so that you can have two logical mail servers (one MX and one
MSA) on the same physical server.
[snipped... answered in other posts]
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.
Supposing the rule applies only to clients in my domain, it still seem
to me the rule "Internal only if it's not directly accepting mail from
client IPs that you WANT to accept mail from" still implies a box that
does accept direct connections from my clients on dial-up IPs fails this
I think you're clear on this now.
If it's an MX it's internal, period.
If it's also an MSA, which normally shouldn't be internal, you have to
make up for it being marked as internal by extending the trust boundary
to the MSA clients by satisfy one or more of the three options we're now
all so familiar with.
test. So I think you're saying two things: regardless of that rule,
"MXes and everything (internal relays) after them are ALWAYS in both
trusted and internal networks." (that was the next sentence after the
quoted rule--not to mention the *must* *must* *must* earlier!). And,
second, if you are in such a situation, you better meet one of the 3
tests of point 3) to avoid degraded SA results.
Correct. I guess I could have said "you better" instead of "must", but
I figured that you wanted it to work right, so really there's no difference.
Hopefully I've clarified any remaining questions about this. If I
haven't maybe Matt, Bowie, Kelson or someone else will take a whack at
it. I'm four hours into a public holiday so I now get to bill you twice
as much!
Daryl
