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, [email protected] ; 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.
