You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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.

'*Comment: auto detection appears to be broken in non-NAT networks as well. I'm seeing this in 3.1.x, but it may affect other versions. If you are having trouble with this, please follow the instructions to manually set TrustedNetworks and see if it fixes your problem.*'

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)

If you have these warning signs frequently, and have your gateway MX behind a NAT, you probably need to manually configure trusted_networks. See the [http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Conf.html 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.

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

That line will specify that the host at 123.12.34.56, and all hosts in the 123.12.35.0 - 123.12.35.255 address range, are to be trusted.

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

Well, trusting too few is in many ways just as bad as trusting too many. Many SpamAssassin rules try to perform checks against the untrusted host that delivered mail to the first trusted server. If there's too few or too many hosts that SA trusts, these tests will be examining the wrong host. Both situations contribute greatly to false negative problems, and to a lesser extent false positive problems.

Why doesn't the auto detection just work for all networks?

Unfortunately there's limits to what one can automatically discover about a network from just email headers.

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.

The problem is how can you tell if that first non-private IP is part of the local network? You can't.

You could be dealing with a network in which the gateway MX is part of a DMZ which is not address translated, in which case that non-private IP is local. On the other hand, you could be dealing with a network where the gateway MX is address translated, in which case that non-private IP is outside the local network.

Thus, SpamAssassin has to make an assumption. That assumption works for some NAT networks, and not for others. You can change the assumption, but at that point you're just changing which of the two ambiguous cases will need manual configuration.

If you really want to be on the safe side, just declare your trusted_networks manually, and you'll avoid the auto detection situation entirely.

How can I optimize the trusted_networks setting?

If you want to configure SpamAssassin with more information, you can:

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

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

Can you explain more about what SpamAssassin does with this info?

Take a look at TrustedRelays.

  • No labels