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:
| No Format |
|---|
add_header all RelaysUntrusted _RELAYSUNTRUSTED_
|
| Wiki Markup |
|---|
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 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:
...
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.
...
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.