You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ross Boylan <ro...@biostat.ucsf.edu> on 2006/07/01 04:19:54 UTC
Re: trusted_networks confusion--simple case
On Fri, 2006-06-30 at 18:00 -0400, Daryl C. W. O'Shea wrote:
> 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).
My setup is a bit more complex than the one described here; I said
"assume for simplicity" in the opening just because I'm having trouble
even with the simple case.
So I'm still trying to understand the principles.
>
> 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?
> >
> > 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.
> >
> > 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
Since I think one of the real systems I'm dealing with is doing the
above, but it's not in this simple example, I'll save that for later.
> >>
> >> - 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.
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.
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 xyz@b.c. 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.)
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).
>
>
>
> > 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.
Does a machine that is not part of my domain qualify as a client?
Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my
domain), and that I do want to accept such mail. Does that count as
"directly accepting mail from client IPs that you WANT to accept mail
from"? If it does, then the "internal only if it's not ...." test says
the machine is not internal.
>
> 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
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.
>
> > 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.
>
[deletions]
Ross
Re: trusted_networks confusion--simple case (clarification)
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 6/30/2006 11:08 PM, Ross Boylan wrote:
> To clear up an ambiguity in my original:
> On Fri, 2006-06-30 at 19:19 -0700, Ross Boylan wrote:
>
>>Does a machine that is not part of my domain qualify as a client?
>>Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my
>>domain), and that I do want to accept such mail.
>
> The human client sending the mail works for somewhere.com, not my
> organization. I'm not talking about the case of a roaming user who
> really is in my domain. The mail is external in all senses; I just want
> to accept it for the same reason I accept email from anywhere on the
> internet. They could be a spammer.
Anyone from somewhere.com sending mail directly to your MXes are taking
their chances with being looked up in DNSBLs. Anyone trying to do so
these days should be well aware of that. Telling SA that the MX is
internal tells it to look up these people, who may be spammers as you
said, in DNSBLs.
As Matt Kettler best said in a post tonight, internal hosts aren't
*intended* to have mail sent directly to them from humans at
somewhere.com. They should really use their own MSA.
Daryl
Re: trusted_networks confusion--simple case (clarification)
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
To clear up an ambiguity in my original:
On Fri, 2006-06-30 at 19:19 -0700, Ross Boylan wrote:
> Does a machine that is not part of my domain qualify as a client?
> Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my
> domain), and that I do want to accept such mail.
The human client sending the mail works for somewhere.com, not my
organization. I'm not talking about the case of a roaming user who
really is in my domain. The mail is external in all senses; I just want
to accept it for the same reason I accept email from anywhere on the
internet. They could be a spammer.
> Does that count as
> "directly accepting mail from client IPs that you WANT to accept mail
> from"? If it does, then the "internal only if it's not ...." test
> says
> the machine is not internal.
>
This was all in the context of discussing this passage:
>> [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.
Sorry for the chatter.
Re: [OT} silliness wasRe: trusted_networks confusion--simple case
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
jdow wrote:
> Is there a local workaholics annonymous branch near you?
Oh I'm sure not to be anonymous about it. I guess one upside to
insomnia is that I don't spend time working that could be better spent
sleeping.
[OT} silliness wasRe: trusted_networks confusion--simple case
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
...
> 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!
Is there a local workaholics annonymous branch near you?
{^_-}
Re: trusted_networks confusion--simple case
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
On Sat, 2006-07-01 at 03:55 -0400, Daryl C. W. O'Shea wrote:
...
>
> 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!
>
Thank you very much for sticking with this. I think I've got it now.
As I said at the start, if the docs could make this a little easier to
understand, that would be great.
Ross
Re: trusted_networks confusion--simple case
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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 xyz@b.c. 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