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 2005/06/28 04:24:42 UTC

[Spamassassin Wiki] Trivial Update of "TrustedRelays" 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/TrustedRelays

The comment on the change is:
a little more clarification

------------------------------------------------------------------------------
   * '''Trusted''' relay at friend.example.com [212.17.35.14]
   * '''Trusted''' and '''internal''' relay at dmz.example.com [150.51.53.1]
   * '''Trusted''' and '''internal''' localhost handover at internal.example.com [127.0.0.1]
+ 
+ A side note: the header lines for 'evil', 'chaos', and 'loser' could all be faked, for all we know, since who knows if an untrusted host is running legitimate MTA software, or is under the control of a spammer?  Therefore, it's unwise to trust things you find in untrusted headers.  One exception to this is discussed below in 'DNSBL lookups and 'firsttrusted'', however.
  
  Here's what SpamAssassin's trust path algorithm makes of this (pasted from "spamassassin -D -t" output):
  
@@ -101, +103 @@

  
  == DNSBL lookups and 'firsttrusted' ==
  
- DNSBL rules support '-firsttrusted' and '-untrusted' as special-case keywords to control IP address selection.  These keywords do NOT refer to the trust status of the lines themselves!  They refer to the trust status of the data that will be looked up in the DNSBL.
+ DNSBL rules support '-firsttrusted' and '-untrusted' as special-case keywords to control IP address selection.  These keywords do not refer to the trust status of the lines themselves!  They refer to the trust status of the data that will be looked up in the DNSBL.
  
  This hinges on a key border case.  The most recent 'untrusted' header line is in an interesting grey area -- the '''host''' it discusses is an untrusted host, but the '''data''' recorded about that host is, in itself, trustworthy.
  
- Above, for example, 193.120.149.226 is listed as an untrusted host and is therefore listed in the 'X-Spam-Relays-Untrusted' pseudoheader.  However, its IP address was ''recorded'' by a trusted host, so the IP address ''is'' trustworthy.
+ Above, for example, 193.120.149.226 is listed as an untrusted host and is therefore listed in the 'X-Spam-Relays-Untrusted' pseudoheader.  However, its IP address was ''recorded'' by a trusted host, so the IP address data ''is'' trustworthy.
  
- This is the only 'grey area', however.  All the other hosts listed in the 'X-Spam-Relays-Untrusted' pseudoheader were both untrusted themselves, and their details were not recorded by a trusted host; both the lines themselves and the IP addresses are not trustworthy, since they could have been generated by a spamware application creating fake header data.
+ This is the only 'grey area', however.  All the other hosts listed in the 'X-Spam-Relays-Untrusted' pseudoheader were both untrusted themselves, and their details were not recorded by a trusted host; both the lines themselves and the IP addresses are not trustworthy, since they could have been generated by a spamware application creating fake header data.  It's especially important not to trust that data for rules that could give negative points, since spammers can, and will, attempt to fake their way their your whitelisting rules.