Re: Question regarding trusted_networks
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, uh...@fantomas.sk ; 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.
Re: Question regarding trusted_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. 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, uh...@fantomas.sk ; 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.
Re: Question regarding trusted_networks
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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steadier Work: https://linkedin.com/in/billcole
Re: Question regarding trusted_networks
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.
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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, uh...@fantomas.sk ; 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)
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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, uh...@fantomas.sk ; 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.
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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
Re: Question regarding trusted_networks
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 :)
Question regarding trusted_networks
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
