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/06/21 22:39:30 UTC
trusted_networks confusion
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?
Here are the things that confused me. This is a request for
clarification, and a hint that maybe the man page could be clearer.
The simplest issue is the question of defaults. Both settings say the
default is none. However, the text asserts that each defaults to the
other, and also that trusted_networks defaults to an inferred check if
DNS tests are enabled. These various statements appear contradictory.
The inferred trusted_networks in particular raises some questions:
1) if you specify trusted_networks explicitly, do these add to or
replace the ones inferred?
2) if internal_networks is set and trusted_networks is not, does trusted
networks end up holding the contents of trusted_networks, the inferred
list, or both?
3) Does clear_trusted_networks affect the inferred trusted networks?
4) If internal_networks is specified explicitly and trusted_networks is
not, does internal networks end up with the explicit specification, the
inferred trusted_networks (seems unlikely), or both?
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.
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.
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.
--
Ross Boylan wk: (415) 514-8146
185 Berry St #5700 ross@biostat.ucsf.edu
Dept of Epidemiology and Biostatistics fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm: (415) 550-1062
Re: trusted_networks confusion--authentication
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 6/30/2006 10:46 PM, Ross Boylan wrote:
> Now for the "3 tests" as they apply to my non-hypothetical case.
> On Wed, 2006-06-28 at 01:45 -0400, Daryl C. W. O'Shea wrote:
>>>>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
>
>
> Although my simple example didn't involve this, I have a feeling one of
> the real servers I'm dealing with does. I've been unable to find out
> exactly what it would mean to meet the requirement above (specifically
> the requirement for "mail server software that includes RFC 3848 or
> Sendmail-style auth tokens in it's received headers"). The received
> headers from that system do look like (edited slightly for security)
>
> Received: from x.y.z.net ([64.1.2.3]
> helo=[10.0.11.25]) by biostat.ucsf.edu with esmtpsa
> (TLSv1:RC4-SHA:128) (Exim
> 4.50) id 1FtS7g-0004tO-BY for ross@biostat.ucsf.edu; Thu, 22 Jun
> 2006
> 09:33:40 -0700
> so this particular connection was encrypted as well as authenticated.
> It does say "with esmtpsa". Is that sufficient?
YES. RFC3848 describes the "with types", some of which indicate that
the client authenticated in some way. ESMPTSA is secure and
authenticated, while ESMPTA would just we authenticated. Either would
suffice.
> [The next 3 paragraphs explain why I have doubts that it is sufficient,
> as well as some evidence it is. Readers may wish to skip ahead.]
>
>>>From the phrase "auth tokens" I thought the line was supposed to include
> some cryptographic signature. The material in parens
> (TLSv1:RC4-SHA:128) seems simply to indicate the details of the
> encryption mechanism (maybe RC4-SHA refers to authentication?), but not
> any particular key.
By auth tokens, I simply mean some indication that the client
authenticated. One of the RFC3848 with types indicating authentication
would be an auth token. Another would be the "(authenticated bits="
line that Sendmail inserts when a client authenticates. See the headers
of any email from me for an example.
Currently the four groups of auth tokens (or authentication indicators)
that SA will parse are:
- Critical Path's "(authenticated as" line
- Courier's "AUTH: auth-type" lines
- with types: ESMTPA|ESMTPSA|LMTPA|LMTPSA|ASMTP|HTTP
- Sendmail's "(authenticated bits=" line
For a whole bunch of background on why this was necessary see:
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=2462
>>>> - 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).
>
>
> [...]
>
> And later you wrote
>
>>Some people may use more than one of the solutions. It all depends
>>on how your users authenticate with your MSA.
>
>
> So, in particular, if the mail server were to accept mail from our own
> clients either if they came from a recognized one of our IP's or if they
> used SMTP auth from elsewhere, SA would be OK if I set trusted_networks
> to be the address of the server and of all our IPs. internal_networks
> will automatically use the same list. And SA will handle things as it
> should. Right?
You've got it.
It'll work right, and you're right that you don't need to also set
internal networks manually. In fact, you're probably better of that way
(not setting it).
> In particular, if our IP's include non-public ranges (e.g.,
> 192.168.1.0/24), I should include those in the trusted_networks list as
> well, right?
Yes.
Also, more relevant info to all of this:
http://wiki.apache.org/spamassassin/DynablockIssues
Daryl
Re: trusted_networks confusion--authentication
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
Now for the "3 tests" as they apply to my non-hypothetical case.
On Wed, 2006-06-28 at 01:45 -0400, Daryl C. W. O'Shea wrote:
[..]
> 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
Although my simple example didn't involve this, I have a feeling one of
the real servers I'm dealing with does. I've been unable to find out
exactly what it would mean to meet the requirement above (specifically
the requirement for "mail server software that includes RFC 3848 or
Sendmail-style auth tokens in it's received headers"). The received
headers from that system do look like (edited slightly for security)
Received: from x.y.z.net ([64.1.2.3]
helo=[10.0.11.25]) by biostat.ucsf.edu with esmtpsa
(TLSv1:RC4-SHA:128) (Exim
4.50) id 1FtS7g-0004tO-BY for ross@biostat.ucsf.edu; Thu, 22 Jun
2006
09:33:40 -0700
so this particular connection was encrypted as well as authenticated.
It does say "with esmtpsa". Is that sufficient?
[The next 3 paragraphs explain why I have doubts that it is sufficient,
as well as some evidence it is. Readers may wish to skip ahead.]
>>From the phrase "auth tokens" I thought the line was supposed to include
some cryptographic signature. The material in parens
(TLSv1:RC4-SHA:128) seems simply to indicate the details of the
encryption mechanism (maybe RC4-SHA refers to authentication?), but not
any particular key.
For completeness, here's what I did to find out what the requirements
were: I looked at RFC 3848; it seems to be mostly a pointer to other
RFCs, and none of those said what should go in the received headers
specifically for SMTP auth (as far as I can tell, checking 2554, 2821,
2822). google with sendmail also didn't help, nor did the exim spec
provide any details about what it does with the received lines for AUTH.
exim's standard Received: template includes
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
which seems to provide info on whether authentication occurred and any
TLS use, but no particular cryptographic tokens.
However, 3848 does specify the names ESMTPA and ESMTPSA, which is exim's
$received_protocol.
> >>
> >> - 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).
[...]
And later you wrote
> Some people may use more than one of the solutions. It all depends
> on how your users authenticate with your MSA.
So, in particular, if the mail server were to accept mail from our own
clients either if they came from a recognized one of our IP's or if they
used SMTP auth from elsewhere, SA would be OK if I set trusted_networks
to be the address of the server and of all our IPs. internal_networks
will automatically use the same list. And SA will handle things as it
should. Right?
In particular, if our IP's include non-public ranges (e.g.,
192.168.1.0/24), I should include those in the trusted_networks list as
well, right?
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
Re: trusted_networks confusion--simple case
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
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
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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
Re: trusted_networks confusion
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
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).
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.
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?
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.
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.
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.
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 to be a good internet citizen (not an open relay)? 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).
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?
P.S. What does FP mean? Spam points?
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Bart Schaefer wrote:
> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>> Bart Schaefer wrote:
>> >
>> > Under what circumstances would one list something as internal but not
>> > trusted?
>>
>> NEVER. Newer versions of SA won't even allow you to make that
>> misconfiguration.
>
> Ah, good. That's as I expected. (So why doesn't SA simply always
> merge internal_networks into trusted_networks? It seems a waste of
> effort to have to manually list the internal_networks in both places.)
It'd make inclusion/exclusion syntax impossible.
Daryl
Re: trusted_networks confusion
Posted by Bart Schaefer <ba...@gmail.com>.
On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
> Bart Schaefer wrote:
> >
> > Under what circumstances would one list something as internal but not
> > trusted?
>
> NEVER. Newer versions of SA won't even allow you to make that
> misconfiguration.
Ah, good. That's as I expected. (So why doesn't SA simply always
merge internal_networks into trusted_networks? It seems a waste of
effort to have to manually list the internal_networks in both places.)
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "John D. Hardin" <jh...@impsec.org>
> On Thu, 29 Jun 2006, Daryl C. W. O'Shea wrote:
>
>> Bart Schaefer wrote:
>> >
>> > Under what circumstances would one list something as internal but not
>> > trusted?
>>
>> NEVER. Newer versions of SA won't even allow you to make that
>> misconfiguration.
>
> What, you *trust* all your users? :)
Wazzat have to do with anything, John? Trusted is for the mail servers.
I treat it as the last one in line that will not lie to you about where
it got things. Since Fetchmail does add a header line and that ends up
trashing the SpamAssassin ability to figure out trusted I have had to
push through the Fetchmail header by ONE to the place from which it
fetches my mail. That place is NOT within my network. And I rather
emphatically do not want to consider it such.
{^_^}
Re: trusted_networks confusion
Posted by "John D. Hardin" <jh...@impsec.org>.
On Thu, 29 Jun 2006, Daryl C. W. O'Shea wrote:
> Bart Schaefer wrote:
> >
> > Under what circumstances would one list something as internal but not
> > trusted?
>
> NEVER. Newer versions of SA won't even allow you to make that
> misconfiguration.
What, you *trust* all your users? :)
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Senator, when you took your oath of office, you placed your hand on
the Bible and swore to uphold the Constitution. You didn't place your
hand on the Constitution and swear to uphold the Bible.
-- Jamie Raskin, Professor of Law at American
University, testifying before the Maryland Senate
-----------------------------------------------------------------------
5 days until The 230th anniversary of the Declaration of Independence
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
<internal network stuff>
This inspired me to make a brute force test. Something has changed in
the machine's configuration that allows me to remove all references to
internal or trusted networks and still run without ALL_TRUSTED coming
up and bugging me. Maybe those entries were hangovers from 2.64 or maybe
it was from the earlier 3.0 series versions. Or maybe I made a change
to fetchmail that made it all happier.
I still think recycling "internal_networks" to indicate those email
senders for whom you want special processing as in "skip", "notify
postmaster if spam", and so forth would be a splendid idea.
{^_^}
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
jdow wrote:
> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>> jdow wrote:
>>> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>>>
>>>> jdow wrote:
>>>>> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>>>>> The Earthlink mail servers are ABSODAMNLUTELY not part
>>>>> of my internal network. But if I do not list them with trusted
>>>>> networks
>>>>> I visit the land of ALL_TRUSTED.
>>>>
>>>> I'm assuming you're still using 3.0.x which has a number of flaws
>>>> when trusted != internal networks.
>>>
>>> Have you worked around the FetchMail situation? Until I trusted the
>>> server to which Fetchmail connected I was up ALL_TRUSTED creek.
>>
>> Nothing to work around. You *have to* include Earthlink's *incoming*
>> mail network in your trusted and internal config.
>>
>> You're scanning mail for user@earthlink.net, you have to include all
>> hosts from the MXes for earthlink.net all the way to you in your
>> trusted *and* internal networks.
>
> That may be so but it's a crock if I wish to treat REAL internal
> network as different from the virtual one at Earthlink. Otherwise
> the fetchmail headers not parsed right leading to ALL_TRUSTED must
> be fixed.
I have no clue about what you're talking about there. I have a few
accounts that I use fetchmail for and SA has been parsing it correctly
throughout the 3.x series.
Perhaps you're including their MSAs in your config, in which case you'd
see ALL_TRUSTED if the MSA's client connected with SMTP AUTH and the MSA
included auth tokens in it's received header.
>>>> Whenever you move to 3.1 or 3.2 you'll see that the appropriate
>>>> Earthlink hosts should indeed by listed as part of your internal
>>>> network and not just your trusted network.
>>>
>>> But they are NOT my internal network. As I see it the internal network
>>
>> YES, they are a part of your internal MAIL network. They're your mail
>> provider. Their network is your network.
>
> Not when I want to treat real internal email differently from outside
> email from the Earthlink servers.
Their *incoming* mail servers shouldn't be originating mail.
Mail from hosts outside of Earthlink's mail would be treated differently
than mail from your own internal network.
Like I said before, 3.0.x has some brokenness in that it treats trusted
but not internal hosts as internal anyway in a number of cases. So
really, you'd have the same config either way (with 3.0). In 3.1 you'll
see that it was really the bugs in 3.0 covering your config error.
>>> can be effectively skipped for spam scanning. When A@here.net sends
>>> email to B@here.net other controls on spamming exist - such as turning
>>> around in my chair and issueing a verbal tongue lashing or at least a
>>> "Why?" with arched eyebrows. When someone uses Earthlink's servers,
>>> which I am probably over-trusting, I do not want any shortcuts taken.
>>
>> There's your problem. If you've trusted Earthlink's MSAs and other
>> *outgoing* mail hosts then you are trusting more of their network than
>> you need to.
>
> Sadly they've changed their network around a few times in the past.
> As it is I am getting nothing mismarked from Earthlink. But....
> What in was the reason for the two different variables in the first
> place? Given them I'd expect they would get some form of different
> treatment or at least that this was contemplated when they were made.
The purpose is to extend trust to other domain's servers in the sense
that you know they won't forge headers -- not something that's useful
for most setups. It's also used for trusting MSA headers, but not
trusting mail from them.
In your case Earthlink isn't another domain, it is your domain.
>>> If not I sense an enhancement request coming.
>>
>> Oh gee. I can't even imagine what that may be.
>
> And you're probably right. You have two variables. Allow for different
> behaviors when there is a fetchmail situation involved. (I am wondering
> how a dnsalias.net email forwarding is handled with respect to these
> two variables and SA guesses for ALL_TRUSTED prevention.)
Dynamic DNS would be handled with auth tokens. I do that too. :)
Daryl
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> jdow wrote:
>> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>>
>>> Bart Schaefer wrote:
>>>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>>>
>>>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>>>> networks.
>>>>
>>>> Under what circumstances would one list something as internal but not
>>>> trusted?
>>>
>>> NEVER. Newer versions of SA won't even allow you to make that
>>> misconfiguration.
>>
>> Gawd I hope not.
>
> Well I hope so. It's the only way that (a) makes sense and (b) works right.
>
> Note that we're talking about internal networks always being trusted,
> not that trusted networks are always internal.
OK, I had read your comments to mean that they were going to be forced
to be the same thing. Thanks for the clarigication.
>> The Earthlink mail servers are ABSODAMNLUTELY not part
>> of my internal network. But if I do not list them with trusted networks
>> I visit the land of ALL_TRUSTED.
>
> I'm assuming you're still using 3.0.x which has a number of flaws when
> trusted != internal networks.
Have you worked around the FetchMail situation? Until I trusted the
server to which Fetchmail connected I was up ALL_TRUSTED creek.
> Whenever you move to 3.1 or 3.2 you'll see that the appropriate
> Earthlink hosts should indeed by listed as part of your internal network
> and not just your trusted network.
But they are NOT my internal network. As I see it the internal network
can be effectively skipped for spam scanning. When A@here.net sends
email to B@here.net other controls on spamming exist - such as turning
around in my chair and issueing a verbal tongue lashing or at least a
"Why?" with arched eyebrows. When someone uses Earthlink's servers,
which I am probably over-trusting, I do not want any shortcuts taken.
But I do trust it not to lie about its headers. So I see distinct
needs for internal_networks and trusted_networks. Perhaps I had rashly
presumed that a small real estate office that had people sending each
other email would find SA treating it differently than mail coming in
via a fetchmail process Earthlink's business account email handlers.
If not I sense an enhancement request coming.
{^_^}
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
jdow wrote:
> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>
>> Bart Schaefer wrote:
>>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>>
>>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>>> networks.
>>>
>>> Under what circumstances would one list something as internal but not
>>> trusted?
>>
>> NEVER. Newer versions of SA won't even allow you to make that
>> misconfiguration.
>
> Gawd I hope not.
Well I hope so. It's the only way that (a) makes sense and (b) works right.
Note that we're talking about internal networks always being trusted,
not that trusted networks are always internal.
> The Earthlink mail servers are ABSODAMNLUTELY not part
> of my internal network. But if I do not list them with trusted networks
> I visit the land of ALL_TRUSTED.
I'm assuming you're still using 3.0.x which has a number of flaws when
trusted != internal networks.
Whenever you move to 3.1 or 3.2 you'll see that the appropriate
Earthlink hosts should indeed by listed as part of your internal network
and not just your trusted network.
ALL hosts after (and including) the MX that accepts mail on your behalf
are a part of your internal network.
Of course we've been over this before...
> Forcing them to be the same is a fatal bug.
Well, we're not forcing you to configure it that way, but you really
should. :)
Daryl
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> Bart Schaefer wrote:
>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>
>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>> networks.
>>
>> Under what circumstances would one list something as internal but not
>> trusted?
>
> NEVER. Newer versions of SA won't even allow you to make that
> misconfiguration.
Gawd I hope not. The Earthlink mail servers are ABSODAMNLUTELY not part
of my internal network. But if I do not list them with trusted networks
I visit the land of ALL_TRUSTED.
Forcing them to be the same is a fatal bug.
{^_^}
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Bart Schaefer wrote:
> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>
>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>> networks.
>
> Under what circumstances would one list something as internal but not
> trusted?
NEVER. Newer versions of SA won't even allow you to make that
misconfiguration.
Daryl
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
jdow wrote:
> From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
>
>> jdow wrote:
>>> From: "Bart Schaefer" <ba...@gmail.com>
>>>
>>>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>>>
>>>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>>>> networks.
>>>>
>>>> Under what circumstances would one list something as internal but
>>>> not trusted?
>>>
>>> One example is when you are using FetchMail or equivalent.
>>> {^_^}
>>
>> No! NEVER. You can't trust a received header to determine that it is
>> internal if you haven't first trusted it.
>>
>> ALL internal_networks MUST be in trusted_networks.
>
> But not the obverse - all trusted_networks are NOT internal_networks.
There wouldn't be much point to having the two if they both contained
each other now would there! :)
Daryl
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> jdow wrote:
>> From: "Bart Schaefer" <ba...@gmail.com>
>>
>>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>>
>>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>>> networks.
>>>
>>> Under what circumstances would one list something as internal but not
>>> trusted?
>>
>> One example is when you are using FetchMail or equivalent.
>> {^_^}
>
> No! NEVER. You can't trust a received header to determine that it is
> internal if you haven't first trusted it.
>
> ALL internal_networks MUST be in trusted_networks.
But not the obverse - all trusted_networks are NOT internal_networks.
{^_^}
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
jdow wrote:
> From: "Bart Schaefer" <ba...@gmail.com>
>
>> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>>
>>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>>> networks.
>>
>> Under what circumstances would one list something as internal but not
>> trusted?
>
> One example is when you are using FetchMail or equivalent.
> {^_^}
No! NEVER. You can't trust a received header to determine that it is
internal if you haven't first trusted it.
ALL internal_networks MUST be in trusted_networks.
Daryl
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Bart Schaefer" <ba...@gmail.com>
> On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>>
>> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
>> networks.
>
> Under what circumstances would one list something as internal but not trusted?
One example is when you are using FetchMail or equivalent.
{^_^}
Re: trusted_networks confusion
Posted by Bart Schaefer <ba...@gmail.com>.
On 6/29/06, Daryl C. W. O'Shea <sp...@dostech.ca> wrote:
>
> EVERYTHING after an MX MUST be listed as BOTH trusted and internal
> networks.
Under what circumstances would one list something as internal but not trusted?
Re: trusted_networks confusion
Posted by jdow <jd...@earthlink.net>.
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
> Ross Boylan wrote:
...
>> Maybe it will help to be concrete. I'll use made up names to foil
>> spambots:
>>
>> People send me mail at xyz@b.edu. 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 should not have skipped his message since his topology is not
really different from mine. We use fetchmail here from Earthlink.
This is an edited extract from my local.cf:
clear_trusted_networks
trusted_networks 127/8 192.168/16 207.217.121/24 209.86.93/24
internal_networks 192.168/16
192.168/16 basically describes the room allocated for local networks.
Although only a few of the machines involved are actually capable at
this time of sending email. (Some of the gadgets may grow such an
ability. But so far it is not used.)
207.217.121/24 moderately accurately describes the smtpauth.earthlink.net
addresses. They are not REALLY needed in trusted_networks. But Earthlink
seems to move things around from time to time in this regard so....
209.86.93/24 moderately accurately describes the pop.earthlink.net
set of addresses. (As with the 207 set this also includes mindspring
and many other "absorbed" ISP names.)
I hope this helps. It's what I am using here with Fetchmail, which is
setup per user this way:
defaults mda "/usr/bin/procmail -d jdow"
set syslog
set postmaster "" # I don't CARE if it foos.
set no bouncemail
set no spambounce
set properties ""
set daemon 60
poll smtp.earthlink.net with proto POP3
user 'jdow' there with password 'XXXXXXXXXXXXXXXXy'
is 'jdow@thismachine.thisdomain' here options pass8bits
smtpaddress ' '
Some of this seems to be magic for the version I started with. I've
never edited out things that might not apply anymore.
{^_^}
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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 xyz@b.edu. 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 xyz@f.com, 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
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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
Re: trusted_networks confusion
Posted by Ross Boylan <ro...@biostat.ucsf.edu>.
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?
> > 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.
> >
> > 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?
>
> 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.
>
> 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?
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. Do either of these conditions (getting mail from dynamic
IP's, servicing different domain) imply the host should not be in
internal_networks?
Thanks.
Ross
Re: trusted_networks confusion
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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.
> Here are the things that confused me. This is a request for
> clarification, and a hint that maybe the man page could be clearer.
>
> The simplest issue is the question of defaults. Both settings say the
> default is none. However, the text asserts that each defaults to the
> other, and also that trusted_networks defaults to an inferred check if
> DNS tests are enabled. These various statements appear contradictory.
There's no set defaults for either.
If you only set one of them, the other will get the same setting.
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.
> The inferred trusted_networks in particular raises some questions:
> 1) if you specify trusted_networks explicitly, do these add to or
> replace the ones inferred?
Inferring the correct settings for a setting you've already configured
manually wouldn't be to wise... so we don't do it. If you manually
configure any of the trusted/internal networks no inferring is done.
> 2) if internal_networks is set and trusted_networks is not, does trusted
> networks end up holding the contents of trusted_networks, the inferred
> list, or both?
As above, the undefined list takes the value of the defined list. No
inferring is done if anything is set manually.
> 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.
> 4) If internal_networks is specified explicitly and trusted_networks is
> not, does internal networks end up with the explicit specification, the
> inferred trusted_networks (seems unlikely), or both?
This should be clear by now... a manually configured config is never
altered. internal_networks retains it's settings, the undefined
trusted_networks gets a copy of internal_networks as it's config. No
inferring is done.
> 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.
>
> 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.
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.
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.
Daryl