Question regarding trusted_networks

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Question regarding trusted_networks

J Doe
Hello,

I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS.  I have SA running on a server with Postfix as the MTA on the same server.

I have a question regarding the trusted_networks configuration parameter (man Mail::SpamAssassin::Conf).  I manually added this to a custom local.cf file and linted it:

    /etc/spamassassin/local.custom.cf:
        trusted_networks 1.2.3.4

    $ spamassassin --lint --config-file=/etc/spamassassin/local.custom.cf

This displays:

    Jun 15 18:31:02.893 [8327] warn: netset: cannot include 1.2.3.4/32 as it has already been included

This lead me to believe that when SpamAssassin loads, it automatically adds the IP address of the host it is running on (along with localhost, which is mentioned in man).  As a result, I removed the trusted_networks entry and a subsequent lint produces no warnings or errors.

When I then ran lint and added the --debug flag:

    $ spamassassin --debug --lint --config-file=/etc/spamassassin/local.custom.cf

…I see the following in the output:

    Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually

My question is:

— Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or …
— Should I not set trusted_networks and ignore the warning from --debug ?

Thanks,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Benny Pedersen-2
J Doe skrev den 2018-06-16 00:44:

>     $ spamassassin --debug --lint
> --config-file=/etc/spamassassin/local.custom.cf

dont use --lint and --config-file at same time to do lint testing

if this is a error, please create a bug

--debug does not make it more simple, and mostly only developpers know
what is displayed in debug :)
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

David Jones
In reply to this post by J Doe
On 06/15/2018 05:44 PM, J Doe wrote:

> Hello,
>
> I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS.  I have SA running on a server with Postfix as the MTA on the same server.
>
> I have a question regarding the trusted_networks configuration parameter (man Mail::SpamAssassin::Conf).  I manually added this to a custom local.cf file and linted it:
>
>      /etc/spamassassin/local.custom.cf:
>          trusted_networks 1.2.3.4
>
>      $ spamassassin --lint --config-file=/etc/spamassassin/local.custom.cf
>
> This displays:
>
>      Jun 15 18:31:02.893 [8327] warn: netset: cannot include 1.2.3.4/32 as it has already been included
>
> This lead me to believe that when SpamAssassin loads, it automatically adds the IP address of the host it is running on (along with localhost, which is mentioned in man).  As a result, I removed the trusted_networks entry and a subsequent lint produces no warnings or errors.
>
> When I then ran lint and added the --debug flag:
>
>      $ spamassassin --debug --lint --config-file=/etc/spamassassin/local.custom.cf
>
> …I see the following in the output:
>
>      Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually
>
> My question is:
>
> — Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or …
> — Should I not set trusted_networks and ignore the warning from --debug ?
>
> Thanks,
>
> - J
>

internal_networks should be any RFC 1918 networks that your mail server
sees plus any public networks that are in your control.

trusted_networks should be internal_networks plus any external networks
that you trust to not send spam -- in other words they are known to have
their own outbound mail filtering.  This will tell SA to go back one
more Received: header to test for "last_external" checks and RBL checks.

For example:

internal_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20
trusted_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20
162.216.126.0/23

My SA servers actually have public IPs on them so technically I don't
need the 192.168.0.0/16 in the list but I put it in there for reference.
  If your mail servers are NAT'd and have a private RFC 1918 IP on them
then you need to include any internal subnet that can send outbound
through your SA server.

--
David Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

David Jones
On 06/16/2018 06:33 AM, David Jones wrote:

> On 06/15/2018 05:44 PM, J Doe wrote:
>> Hello,
>>
>> I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS.  
>> I have SA running on a server with Postfix as the MTA on the same server.
>>
>> I have a question regarding the trusted_networks configuration
>> parameter (man Mail::SpamAssassin::Conf).  I manually added this to a
>> custom local.cf file and linted it:
>>
>>      /etc/spamassassin/local.custom.cf:
>>          trusted_networks 1.2.3.4
>>
>>      $ spamassassin --lint
>> --config-file=/etc/spamassassin/local.custom.cf
>>
>> This displays:
>>
>>      Jun 15 18:31:02.893 [8327] warn: netset: cannot include
>> 1.2.3.4/32 as it has already been included
>>
>> This lead me to believe that when SpamAssassin loads, it automatically
>> adds the IP address of the host it is running on (along with
>> localhost, which is mentioned in man).  As a result, I removed the
>> trusted_networks entry and a subsequent lint produces no warnings or
>> errors.
>>
>> When I then ran lint and added the --debug flag:
>>
>>      $ spamassassin --debug --lint
>> --config-file=/etc/spamassassin/local.custom.cf
>>
>> …I see the following in the output:
>>
>>      Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not
>> configured; it is recommended that you configure trusted_networks
>> manually
>>
>> My question is:
>>
>> — Should I manually set trusted_networks to have the IP address of the
>> host it is running on and ignore the warning from --lint or …
>> — Should I not set trusted_networks and ignore the warning from --debug ?
>>
>> Thanks,
>>
>> - J
>>
>
> internal_networks should be any RFC 1918 networks that your mail server
> sees plus any public networks that are in your control.
>
> trusted_networks should be internal_networks plus any external networks
> that you trust to not send spam -- in other words they are known to have
> their own outbound mail filtering.  This will tell SA to go back one
> more Received: header to test for "last_external" checks and RBL checks.
>
> For example:
>
> internal_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20
> trusted_networks 192.168.0.0/16 fe80::/10 96.4.0.0/15 207.191.176.0/20
> 162.216.126.0/23
>
> My SA servers actually have public IPs on them so technically I don't
> need the 192.168.0.0/16 in the list but I put it in there for reference.
>   If your mail servers are NAT'd and have a private RFC 1918 IP on them
> then you need to include any internal subnet that can send outbound
> through your SA server.
>

Oh yeh, when using Postfix your internal_networks should basically match
the Postfix mynetworks value.

# postconf mynetworks

Then copy/paste the internal_networks to trusted_networks and add any
external networks that can be trusted, if any.  trusted_networks might
start out identical to internal_networks until you find external sources
that you want to include later.

--
David Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Matus UHLAR - fantomas
In reply to this post by David Jones
>On 06/15/2018 05:44 PM, J Doe wrote:
>>     Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not configured; it is recommended that you configure trusted_networks manually
>>
>>My question is:
>>
>>— Should I manually set trusted_networks to have the IP address of the host it is running on and ignore the warning from --lint or …
>>— Should I not set trusted_networks and ignore the warning from --debug ?

On 16.06.18 06:33, David Jones wrote:
>internal_networks should be any RFC 1918 networks that your mail
>server sees plus any public networks that are in your control.

no. only servers that deliver mail to you, as your MX servers or other
mailservers directly within your organization should be in
internal_networks.

>trusted_networks should be internal_networks plus any external
>networks that you trust to not send spam -- in other words they are
>known to have their own outbound mail filtering.  This will tell SA
>to go back one more Received: header to test for "last_external"
>checks and RBL checks.

not external networks. only external mail servers you trust not to forge e-mail
headers. They may send spam but are not the spam sources.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

David Jones
On 06/16/2018 09:37 AM, Matus UHLAR - fantomas wrote:

>> On 06/15/2018 05:44 PM, J Doe wrote:
>>>     Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not
>>> configured; it is recommended that you configure trusted_networks
>>> manually
>>>
>>> My question is:
>>>
>>> — Should I manually set trusted_networks to have the IP address of
>>> the host it is running on and ignore the warning from --lint or …
>>> — Should I not set trusted_networks and ignore the warning from
>>> --debug ?
>
> On 16.06.18 06:33, David Jones wrote:
>> internal_networks should be any RFC 1918 networks that your mail
>> server sees plus any public networks that are in your control.
>
> no. only servers that deliver mail to you, as your MX servers or other
> mailservers directly within your organization should be in
> internal_networks.
>

That is basically the same thing worded a little differently.  If you
have an internal mail relay and your SA server has a private IP on it,
then that will be an RFC 1918 IP or range in your internal_networks.

If your SA servers only have public IPs on them, then you won't have any
RFC 1918 IPs in the internal_networks but you may have 127.0.0.1 and
fe80::/10 for locally generated email plus any public ranges that
smarthost to you.

In my case, I have many customers setup to smarthost to smtp.ena.net so
I have many large CIDRs in my Postfix mynetworks and SA internal_networks.

This can be very different for each use case and probably deserves a
drawing to explain it better.  Seems like I have seen a graphic or
something that shows the logic behind this setting.

Mail with all Received headers of IPs within the internal_networks will
hit the ALL_TRUSTED rule.

>> trusted_networks should be internal_networks plus any external
>> networks that you trust to not send spam -- in other words they are
>> known to have their own outbound mail filtering.  This will tell SA to
>> go back one more Received: header to test for "last_external" checks
>> and RBL checks.
>
> not external networks. only external mail servers you trust not to forge
> e-mail
> headers. They may send spam but are not the spam sources.
>

True.  That is a better way to put it.  I have read that in the SA wiki
documentation now that you mention it.

--
David Jones
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Matus UHLAR - fantomas
>>>On 06/15/2018 05:44 PM, J Doe wrote:
>>>>    Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks
>>>>are not configured; it is recommended that you configure
>>>>trusted_networks manually
>>>>
>>>>My question is:
>>>>
>>>>— Should I manually set trusted_networks to have the IP address
>>>>of the host it is running on and ignore the warning from --lint
>>>>or …
>>>>— Should I not set trusted_networks and ignore the warning from
>>>>--debug ?
>>
>>On 16.06.18 06:33, David Jones wrote:
>>>internal_networks should be any RFC 1918 networks that your mail
>>>server sees plus any public networks that are in your control.

>On 06/16/2018 09:37 AM, Matus UHLAR - fantomas wrote:
>>no. only servers that deliver mail to you, as your MX servers or other
>>mailservers directly within your organization should be in
>>internal_networks.


On 16.06.18 10:12, David Jones wrote:
>That is basically the same thing worded a little differently.  If you
>have an internal mail relay and your SA server has a private IP on
>it, then that will be an RFC 1918 IP or range in your
>internal_networks.

the differences it that RFC1918 networks should NOT be listed in
internal_networks - only mail servers should be listed, no clients.

>Mail with all Received headers of IPs within the internal_networks
>will hit the ALL_TRUSTED rule.

ALL_TRUSTED uses trusted_networks, not internal_networks.
listing internal and external clients in trusted_networks is fine, but they
don't belong to internal_networks.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Benny Pedersen-2
Matus UHLAR - fantomas skrev den 2018-06-16 18:07:

> On 16.06.18 10:12, David Jones wrote:
>> That is basically the same thing worded a little differently.  If you
>> have an internal mail relay and your SA server has a private IP on it,
>> then that will be an RFC 1918 IP or range in your internal_networks.
>
> the differences it that RFC1918 networks should NOT be listed in
> internal_networks - only mail servers should be listed, no clients.

there is no point in have non routeble ips tested by rbls

thats why 127.0.0.1 is forced (RFC 1700) but adding RFC1918 does not
hurt at all

there is alot of ipv6 ranges to add aswell

pleasee understand what it does
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Benny Pedersen-2
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas skrev den 2018-06-16 16:37:

> not external networks. only external mail servers you trust not to
> forge e-mail
> headers. They may send spam but are not the spam sources.

not correct

spamassassin need to know all wan ips your own servers use, it does not
need to protect forgin senders ips or even trustness of forgin

spf is a better forgin protector
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

J Doe
Hi everyone,

Thank you for the feedback.  I am still uncertain, however, if I have to explicitly define the trusted_networks/internal_networks parameters manually in my case (where SA is running on same host as MTA) ?

Ignoring the --debug I note that --lint does warn if I manually specify my MTA here and implies that the IP of the MTA that SA is running on is automatically added to this list.

I note though that man Mail::SpamAssassin::Conf under the trusted_networks setting says:

    "MXes for your domain(s) and internal relays should _also_ be specified using the "internal_networks” setting . . . “

In the same section the algorithm that is used when neither trusted_networks or internal_networks are specified is listed, but there’s no information about whether SA automatically grabs the IP address of the host it is running on when that host also is the MTA.

My question is:

   1. Do I have to manually specify trusted_networks and internal_networks to list the IPv4/IPv6 address of my MTA or because SA is running on the same host as the MTA this is automatically picked up ?

A SIDE QUESTION - is there a way, like postconf, to dump the parameters that SA is using when it has already parsed local.cf and is running ?

Thanks again,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

RW-15
On Sat, 16 Jun 2018 16:00:05 -0400
J Doe wrote:

> Hi everyone,
>
> Thank you for the feedback.  I am still uncertain, however, if I have
> to explicitly define the trusted_networks/internal_networks
> parameters manually in my case (where SA is running on same host as
> MTA) ?

You shouldn't need to set network settings, unless you want to extend
your trusted network or internal+trusted into a third party network or
need to workaround a rare situation or bad practice.

Despite the warning I wouldn't recommend setting the networks unless you
have good reason. SA is pretty good at working this stuff out, but once
you set it it manually it's your responsibly.

If you want to scan outgoing mail, make sure that that your mta is
recording authentication on submission e.g. showing "with ESMTPA",
rather than "with ESMTP".


> there’s no information about whether SA automatically grabs the IP
> address of the host it is running on when that host also is the MTA.

Aside from the practicalities of that, it shouldn't need to. Remember
that a received header reports the upstream IP address.

Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Bill Cole
In reply to this post by J Doe
On 16 Jun 2018, at 16:00 (-0400), J Doe wrote:

> Hi everyone,
>
> Thank you for the feedback.  I am still uncertain, however, if I have
> to explicitly define the trusted_networks/internal_networks parameters
> manually in my case (where SA is running on same host as MTA) ?
>
> Ignoring the --debug I note that --lint does warn if I manually
> specify my MTA here and implies that the IP of the MTA that SA is
> running on is automatically added to this list.
>
> I note though that man Mail::SpamAssassin::Conf under the
> trusted_networks setting says:
>
>     "MXes for your domain(s) and internal relays should _also_ be
> specified using the "internal_networks” setting . . . “
>
> In the same section the algorithm that is used when neither
> trusted_networks or internal_networks are specified is listed, but
> there’s no information about whether SA automatically grabs the IP
> address of the host it is running on when that host also is the MTA.

The documentation says nothing about any automatic inclusions other than
the loopback addresses because the code does no automatic inclusions
other than the loopback addresses.

The reason for SA to NOT include anything automatically other than the
loopback addresses is that it may not be running on the same host as the
MTA or in the same IP environment even if it is on the same host. The
address lists aren't relative to were SA runs, but relative to the
MTA(s) that write Received headers which are seen by SA. So in addition
to the circumstance where a central spamd on one host is getting
submissions from multiple clients that use spamc, it is possible to use
containers and container-like mechanisms (e.g. FreeBSD jails) to isolate
spamd or a SA-embedding program like MIMEDefang or AmavisD in an
environment where it is talking to a local MTA but cannot see the
network interfaces the MTA sees.

>
> My question is:
>
>    1. Do I have to manually specify trusted_networks and
> internal_networks to list the IPv4/IPv6 address of my MTA or because
> SA is running on the same host as the MTA this is automatically picked
> up ?

You need to explicitly specify any addresses you want to be in those
lists other than 127.0.0.0/8 and ::1. The only reason the loopbacks are
automatically included is that an MTA is assumed to have a single
trustworthy identity: if the MTA says mail came from the loopback, it is
receiving mail from itself.

> A SIDE QUESTION - is there a way, like postconf, to dump the
> parameters that SA is using when it has already parsed local.cf and is
> running ?

You are mistaken: Postfix's postconf command does not do that. Really,
I've read the code. It uses the same code that master and the other
Postfix programs use to parse the config files but it cannot tell you
what the running Postfix programs are currently using as their config.
If you run 'postfix reload' (or stop and start) and 'postconf' with no
changes to the config files between running them, the operative config
and the displayed config will be identical.

SpamAssassin does not have an equivalent command to postconf. The reason
for that is pragmatic: the SA "config" is huge and not entirely
reversible into a canonical unparsed config file-like format that can be
readily understood by a user. In the form dumped by the Perl debugger,
the object representing the fully parsed config is scores of thousands
of lines with megabytes of content, and that doesn't include the bits of
code generated at parse time from some rules.

You can get something like a useful dump of the non-rule config elements
with this one-liner, if all of your config files are in
/etc/mail/spamassassin/:

egrep -hvr
'^(($|[[:space:]]*$|[[:space:]]*#|#)|[[:space:]]*(score|describe|meta|tflags|(mime|)header|body|rawbody|full|uri|if|ifplugin|else|askdns|endif)[[:space:]]*)'
/etc/mail/spamassassin/*.{pre,cf}

>
> Thanks again,
>
> - J



--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Matus UHLAR - fantomas
In reply to this post by Benny Pedersen-2
>>On 16.06.18 10:12, David Jones wrote:
>>>That is basically the same thing worded a little differently.  If
>>>you have an internal mail relay and your SA server has a private
>>>IP on it, then that will be an RFC 1918 IP or range in your
>>>internal_networks.

>Matus UHLAR - fantomas skrev den 2018-06-16 18:07:
>>the differences it that RFC1918 networks should NOT be listed in
>>internal_networks - only mail servers should be listed, no clients.

On 16.06.18 18:29, Benny Pedersen wrote:
>there is no point in have non routeble ips tested by rbls

you misunderstand what internal_networks does.
it's trusted_networs that prevent IPs from being tested in RBLs, not
internal_networks.

>thats why 127.0.0.1 is forced (RFC 1700)

this is a completely different case.

> but adding RFC1918 does not hurt at all

the whole point of internal_networks is to know, where your network ends.

Adding client networks into internal_networks means that internal networks
boundary is enhanced past that host.

That further means, not only the IPs are not checked for *lists (RFC1918
are never checked), but the Received: headers are further checked.

you should not trust Received: headers that come from your clients (they may
be forged).

>pleasee understand what it does

See quote from the wiki:


https://wiki.apache.org/spamassassin/TrustPath

    set 'internal_networks' to include the hosts that act as MX for your
domains, or that may deliver mail internally in your organisation.

    set 'trusted_networks' to include the same hosts and networks as
'internal_networks', with the addition of some hosts that are external to
your organisation which you trust to not be under the control of spammers.
For example, very high-volume mail relays at other ISPs, or mailing list
servers. Note that it doesn't matter if the server relays spam to you from
other hosts; that still means you trust the server not to originate spam,
which is what 'trusted_networks' specifies.


and further:


Why should trusted_networks and internal_networks ever be different?

A mail relay that you want to trust in trusted_networks may itself trust its
own internal dynamic IP networks. You may trust them not to be a spam source
but putting them into your internal_networks list would create a false
positive because then those dynamic IPs would be searched for in the DUL
lists. This is an example where the two lists need to be different.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
On the other hand, you have different fingers.
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding trusted_networks

Matus UHLAR - fantomas
In reply to this post by Benny Pedersen-2
>Matus UHLAR - fantomas skrev den 2018-06-16 16:37:
>>not external networks. only external mail servers you trust not to
>>forge e-mail
>>headers. They may send spam but are not the spam sources.

On 16.06.18 19:06, Benny Pedersen wrote:
>not correct
>
>spamassassin need to know all wan ips your own servers use, it does
>not need to protect forgin senders ips or even trustness of forgin

see the docs:

    A trusted host could conceivably relay spam, but will not originate it, and
    will not forge header data. DNS blacklist checks will never query for hosts
    on these networks.

adding client IPs means you trust them not to forge mail headers, which is
a bad thing for clients. Infected clients WILL send mail with forged
headers.

>spf is a better forgin protector

SPF is checked on internal_networks boundary.

for SPF check to work properly, you MUST configure your internal_networks
properly - SPF is checked where message enters your network, primary or
backup servers.

For SPF check to be done on proper IP, all your servers in your mail routing
should be in internal_networks and nothing more.



--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.