On Tue, 28 May 2019 15:42:05 +0000 David Jones wrote: > On 5/27/19 5:13 PM, hg user wrote: > > The server was installed and configured by a "zimbra man", a person > > I fully trust. Since I manage a commercial antivirus/antispam > > solution that is not properly working for the italian language, I > > was tasked to join the project in order to understand if we could > > switch from the proprietary solution to spamassassin. > > > > I'm now in the process of double-checking the configuration of > > spamassassin and feeding the bayes engine... > > > > Testing the system I noticed that spamassassin logged the internal > > MTAs (including the antivirus server) as external and I asked *the > > zimbra man* to correct the configuration. He replied it was not > > necessary. Sorry I didn't specify I asked the person in charge of > > the system. > > > > In the end, I need to think about the answer of RW: spamassassin is > > run by amavis but with no internal servers defined, it uses my > > internal one as the external. Received header needs some more care, > > and probably also the list of stop words should be expanded. > > Probably there is a ratio behind some decisions taken by the > > developers, but I can't fully understand how the destination > > address can help on whether a message is spam or not, at least > > not 6 times. > > The internal_networks and trusted_networks are _very important_ to be > set correctly for a number of reasons, not just Bayes. This gives SA > the proper "view" to the outside/Internet. Keep in mind > internal_networks is not literally your RFC 1918 internal_networks > and the trusted_networks are not only ones that you managed/control. > > Internal_networks is any public or private IP space that you trust to > not forge the Received or synthetic received headers like > X-Originating-IP.
Not really, internal_networks is there to establish which relay is the last-external. > > Trusted_networks can be external/public networks that you know won't > change or forge the Received or synthetic received headers. > > I have recently added all Google and Office 365 IP blocks to my > trusted_networks to better detect last-external client IPs. You need to add them to internal_networks to affect the last-external. > This > allows for deep Received header inspection since I know that Google > and Microsoft aren't going to forge those headers. Very interesting > information comes out into the open as a result of this. You always get deep checks because allowing spammers to forge their way into blocklists and other spam tests is harmless. Adding external addresses to trusted_networks prevents unnecessary blocklist look-ups and allows whitelist tests to run on the first-trusted relay.
