Page History

SpamAssassin, by default, will automatically attempt to figure out which Received: headers were inserted by mailservers in your network, and which were not. This auto detection works pretty well for most networks, but when Network Address Translation (NAT) is involved there are two possible configurations that SpamAssassin cannot automatically detect the difference between. One case is where your MX has a publicly routed IP, and the other where it does not. Looking at Received: headers alone, SA cannot distinguish between the two, so it assumes your MX has a public IP. Also, if you have a large or complex network topology, it's strongly recommended you set this (most ISPs, for instance).

The common symptoms of a broken Trust path include:

...

• \["ALL_TRUSTED"\] matching spam email from the outside or other untrusted mail.
• Dialup/Dynamic IP RBLs misfiring for properly relayed mail.
• Dialup/Dynamic IP RBLs not catching direct-delivered mail.
• whitelist_from_rcvd fails to match.
• SPF tests misfiring (failing when they should pass and vice versa).
• False positives on non-spam mail coming from "dynamic" or "dialup" addresses in your own network.
• AutoWhitelist mismatches on forged mail due to confusion about the source IP.
  

Your trust path can be tested by adding the following to your SpamAssassin config:

add_header all RelaysUntrusted _RELAYSUNTRUSTED_

This will add headers similar to "{{X-Spam-RelaysUntrusted: \[ip=140.211.11.3 rdns=hermes.apache.org....}}".  The first IP address is the IP which will be used for network tests like RBLs and SPF.

If you see these warning signs frequently, you probably need to manually configure trusted_networks. See the Mail::Spamassassin::Conf\] manpage for details. Generally you want trusted_networks set to contain all the mailservers you control that add Received: headers, and nothing else. For proper operation of DUL and SPF tests on authenticated mail submission see [DynablockIssues]submission from dynamic/"dialup" hosts, see DynablockIssues.

Here's an example trusted_networks line that could be added to /etc/mail/spamassassin/local.cf to specify trust:

trusted_networks 123.12.34.56 123.12.35/24 127.0.0.1

That line will specify that the host at 123.12.34.56, the local host 127.0.0.1, and all hosts in the 123.12.35.0 - 123.12.35.255 address range, are to be trusted. (In SpamAssassin 3.2.x, it will no longer be necessary to specify 127.0.0.1; it'll automatically be trusted implicitly.)

Why doesn't SpamAssassin default to not trusting any hosts?

...

It's pretty obvious that any RFC 1918 (which obsoleted RFC 1597) private IP's in the most recent Received: header are part of the local network. From there, tracking backwards in terms of time, each additional private IP can be safely assumed to be a part of the local network until you hit the first non-private IP.

...

• 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.
  

By giving SpamAssassin more info about your network setup, it can perform some tests better, increase accuracy, and reduce load.

...

Take a look at TrustedRelays.

Note that the trust path information is used by both network and non-net rules, so even if you're not running with network rules enabled (the "-L" switch), it's worth configuring this.

Note that each of trusted_networks and internal_networks default to taking the value of the other if unset. See the Mail::SpamAssassin::Conf man page for details. Therefore once either is set then either must be fully declared. For example if several IPs are placed in trusted_networks that value list will be defaulted into internal_networks if internal_networks is not set. But if internal_networks is set to even a single IP value then this will not occur. In that case processing which depends upon a correct internal_networks configuration such as RCVD_IN_SORBS_DUL will not be triggered. If you set both trusted_networks and internal_networks then both must be fully specified. A simpler configuration is to set only the trusted_networks parameter and allow the internal_networks parameter to default to that value. An easy trap to fall into is to only partially specify one or the other.

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.