You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by Apache Wiki <wi...@apache.org> on 2007/01/15 12:01:28 UTC

[Spamassassin Wiki] Update of "TrustPath" by JustinMason

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.

The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/TrustPath

The comment on the change is:
ISPs run into these problems too, even without NAT

------------------------------------------------------------------------------
- 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.
+ 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.  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)
+     * 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. For proper operation of DUL and SPF tests on authenticated mail submission see DynablockIssues.
+ If you see these warning signs frequently, 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. For proper operation of DUL and SPF tests on authenticated mail submission see DynablockIssues.
  
  Here's an example trusted_networks line that could be added to {{{/etc/mail/spamassassin/local.cf}}} to specify trust: