Differences between revisions 2 and 3
Revision 2 as of 2006-09-17 18:44:15
Size: 1172
Editor: JohnHardin
Comment: ALL_TRUSTED is now a wiki rule page
Revision 3 as of 2009-09-20 23:16:22
Size: 1172
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
First off, do '''not''' simply set the rule's score to 0 to disable it. This situation is a symptom of a deeper problem, and that's just treating the symptom instead of curing the disease. While the obvious case of the ["ALL_TRUSTED"] misfires will be fixed, there's a whole load of other rules that will still be failing quietly. First off, do '''not''' simply set the rule's score to 0 to disable it. This situation is a symptom of a deeper problem, and that's just treating the symptom instead of curing the disease. While the obvious case of the [[ALL_TRUSTED]] misfires will be fixed, there's a whole load of other rules that will still be failing quietly.
Line 9: Line 9:
In some cases, your Received header formats may be unparseable by SA, resulting in the ["ALL_TRUSTED"] errors persisting after you've set {{{trusted_networks}}}. In that case, post to the users list with some sample messages to raise the issue, or (if your MTA allows you to change these formats, like qmail) just change your MTA's Received header format to match the de-facto standards in general use. In some cases, your Received header formats may be unparseable by SA, resulting in the [[ALL_TRUSTED]] errors persisting after you've set {{{trusted_networks}}}. In that case, post to the users list with some sample messages to raise the issue, or (if your MTA allows you to change these formats, like qmail) just change your MTA's Received header format to match the de-facto standards in general use.

Fixing ALL_TRUSTED errors

I'm seeing the rule ALL_TRUSTED firing on spam mails, and giving them negative points. What should I do?

First off, do not simply set the rule's score to 0 to disable it. This situation is a symptom of a deeper problem, and that's just treating the symptom instead of curing the disease. While the obvious case of the ALL_TRUSTED misfires will be fixed, there's a whole load of other rules that will still be failing quietly.

What's happening, is that your network setup is too complex for SpamAssassin to correctly infer the edge of your network automatically, and it's getting it wrong. NAT boxes have a tendency to cause this. The correct fix is to set trusted_networks as described in TrustPath.

In some cases, your Received header formats may be unparseable by SA, resulting in the ALL_TRUSTED errors persisting after you've set trusted_networks. In that case, post to the users list with some sample messages to raise the issue, or (if your MTA allows you to change these formats, like qmail) just change your MTA's Received header format to match the de-facto standards in general use.

FixingAllTrusted (last edited 2009-09-20 23:16:22 by localhost)