Additional Spamassassin links


sample Mail::SpamAssassin::Conf - SpamAssassin configuration file:

# a comment, might describe what the following statment does
rewrite_header Subject          *****SPAM*****
welcomelist_from
whitelist_from MyFriend@nicedomain.org
blacklist_from thespammer@anyWhere.com

report_contact Postmaster@Real-World-Systems.com
report_hostname Real-World-Systems.com

#content based:
score SUBJ_DOLLARS      2.7 # was 1.4 Subject starts with dollar amount 
score ADVANCE_FEE_1     1.7 # was 0.0  Appears to be advance fee fraud (Nigerian 419)
#from a black list
score RCVD_IN_SORBS_DUL 1.7 # was 0.9  RBL: SORBS: sent directly from dynamic IP address 

full     PARA_A_2_C_OF_1618         /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
describe PARA_A_2_C_OF_1618     Claims compliance with senate bill 1618
header   FROM_HAS_MIXED_NUMS      From =~ /\d+[a-z]+\d+\S*@/i
describe FROM_HAS_MIXED_NUMS    From: contains numbers mixed in with letters
lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com
lang pt_BR report O programa detetor de Spam ZOE […]

User Preferences

SpamAssassin is configured using traditional UNIX-style configuration files, loaded from

  1. /usr/share/spamassassin
  2. /etc/mail/spamassassin
  3. ~/.spamassassin/user_perfs

# starts a comment.
 If # is part of a rule or configuration option, it must be escaped with a backslash. i.e.: \#

Whitespace in the files is not significant.
Do not begin a line with whitespace as future versions will use this to indicate a multi-line rule definitions.

Each rule or configuration setting must fit on one-line (as of 3.1.x).

File and directory paths can use ~ to refer to the user's home directory.
No other shell-style path extensions such as globing or ~user/ are supported.

The following are permitted for site-wide (local.cf) and user-specific (user_prefs) files

It is important to consider the result of the SpamAssasin evaluation of a message.
If SA evaluates a message as spam it will modify the email, this may affect wether the email is delivered, held, rejected or discarded by a follow-on process.

If spam is only modified by SA and delivered, false positives (i.e. defining a nice message (ham) as spam ) has minor impact.
If a follow-on process moves spam to a holding directory, a false positive is more of a problem.
If a follow-on process rejects or discards spam without notifying the receipient, a false positive is a bad thing! This type of processing is not recommended (previously known as required_hits )

A false negative (i.e. failure to declare a message as spam) can have detrimental effects if the message is an attack.

Scoring Options

next section.

Whitelist and Blacklist options


The levels of To whitelisting:

For deploying SpamAssassin system-wide where some users don't want their mail filtered. as whitelist_from.

Users in the whitelist_to level may still get some spammish mails blocked, users in all_spam_to should never get mail blocked.

The headers checked for whitelist addresses are : Resent-To and Resent-Cc otherwise all addresses are checked from

 To             CC      Apparently-To            Delivered-To    Envelope-To     
 X-Real-To              Apparently-Resent-To     X-Delivered-To  Envelope-Recipients      X-Envelope-To 
 X-Original-To  X-Rcpt-To       

Basic Message Tagging Options