This chapter is from the book
This chapter is from the book
This chapter is from the book
SpamAssassin Configuration Files
SpamAssassin can be run with the as-shipped configuration files, requiring little or no change. Due to the large number of configuration parameters available, only highlights of the configuration files are presented here. A complete description of all configuration parameters is contained in Appendix E. "SpamAssassin Configuration File." Figures 3.7–3.15 and 3.17 are based on information from http://spamassassin.apache.org .
Configuration File Locations
The SpamAssassin configuration files live by default in /usr/share/spamassassin and /etc/mail/spamassassin. Note that all files with a .cf extension are read in alphabetically at spamassassin startup time. The site-wide configuration is by convention called local.cf and should be placed in /etc/mail/spamassassin. You should not place configuration files in /usr/share/spamassassin, as those files may get deleted during future SpamAssassin upgrades.
The individual user configuration file is called user_prefs and is normally located in the user's home directory in the .spamassassin subdirectory. The ability for individual users to have their own user_prefs is a tunable parameter. Also, with the virtual support available within spamd, user preferences can be located in a variable location, depending upon the mail account's domain and/or username. This makes integration with large mail systems easier.
Configuration File Precedence
You need to be aware that the SpamAssassin rule processing is "last touched wins." In other words, the last setting is the one that is used. So, it is important to know that the files are processed in this order:
- SpamAssassin default rules directory, in alphabetic order (defaults to /usr/share/spamassassin)
- Local rules directory, in alphabetic order (by default /etc/mail/spamassassin)
- Local user_prefs file (user's home directory, in a directory called .spamassassin)
Configuration settings come in different classes. The three classifications of keywords are as follows:
- Those that can be changed globally, by the user and/or system-wide (in other words, both user_prefs and local.cf)
- Options that are changeable with permission of the SpamAssassin administrator (if allow_user_rules is enabled)
-
Settings that can only be changed by the SpamAssassin administrator in local.cf
The following classes of users are allowed to manipulate the privileged commands:
- The administrator via the system-wide /etc/mail/spamassassin file
- Users running spamassassin from their procmailrc or forward files
spamd users are not allowed to change the privileged files unless the administrator has set allow_user_rules to 1.
Please consult Appendix E for a complete list and description of available configuration options for all three classes of keywords (global, administrator permitted, and administrator only).
Unprivileged or Global Keywords
Under the unprivileged class of configuration keywords available to anyone, the available options can be broken down as follows:
Scoring
The scoring keywords define what is to be considered spam and the scores assigned by rules (see Figure 3.7).
Table 3.7. Scoring options.
|
required_score n.nn (default: 5) score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ] |
The required_score defines what SpamAssassin considers to be spam. This value can be adjusted higher or lower, depending upon the point at which you want SpamAssassin to consider a message to be spam. If you feel SpamAssassin is being too aggressive and creating lots of false positives, adjust the score threshold upward. If it is too conservative, letting a lot of spam get through, adjust it downward.
Whitelist and Blacklist
The settings in Figure 3.8 control how SpamAssassin processes and manages whitelists and blacklists as well as the auto-whitelisting feature.
Table 3.8. Whitelist and blacklist options.
|
whitelist_from add@ress.com unwhitelist_from add@ress.com whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net def_whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net whitelist_allows_relays add@ress.com unwhitelist_from_rcvd add@ress.com blacklist_from add@ress.com unblacklist_from add@ress.com whitelist_to add@ress.com more_spam_to add@ress.com all_spam_to add@ress.com blacklist_to add@ress.com |
These settings are a matter of personal preference and should be set as the user and administrator see fit.
Tagging
The options in Figure 3.9 control how headers are added to spam messages and header processing.
Table 3.9. Message tagging and header processing options.
|
rewrite_header { subject | from | to } STRING
add_header { spam | ham | all } header_name string
Defaults to:
add_header spam Flag _YESNOCAPS_
add_header all Status _YESNO_, score=_SCORE__ required=_REQD_ tests=_TESTS_
autolearn=_AUTOLEARN_ version=_VERSION_
add_header all Level _STARS(*)_
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_
remove_header { spam | ham | all } header_name
clear_headers
report_safe { 0 | 1 | 2 } (default: 1)
|
The defaults here are reasonable. If you want to adjust the headers, use the add_header keyword. If you want to tell SpamAssassin not to send a separate email message for every message it has identified as spam, set report_safe to 0, and then only X-Spam- headers will be added to the message.
Language
The keywords in Figure 3.10 define geographic locations and language.
Table 3.10. Location and language options.
|
ok_languages xx [ yy zz ... ] (default: all) ok_locales xx [ yy zz ... ] (default: all) |
The default is set to allow all locations and languages, which should be acceptable for most situations.
Network Test
These settings include Razor, Pyzor, DCC, RBL, trusted networks, and other related areas (see Figure 3.11).
Table 3.11. Network test options.
|
use_dcc ( 0 | 1 ) (default: 1)
dcc_timeout n (default: 10)
dcc_body_max NUMBER (default 999999)
dcc_fuz1_max NUMBER (default: 999999)
dcc_fuz2_max NUMBER (default: 999999)
use_pyzor ( 0 | 1 ) (default: 1)
pyzor_timeout n (default: 10)
pyzor_max NUMBER (default: 5)
pyzor_options [option ...] (default: none)
trusted_networks ip.add.re.ss[/mask] ... (default: none)
clear_trusted_networks
internal_networks ip.add.re.ss[/mask] ... (default: none)
clear_internal_networks
use_razor2 ( 0 | 1 ) (default: 1)
razor_timeout n (default: 10)
skip_rbl_checks { 0 | 1 } (default: 0)
rbl_timeout n (default: 15)
check_mx_attempts n (default: 2)
check_mx_delay n (default: 5)
dns_available { yes | test[: name1 name2...] | no } (default: test)
|
These options control the parameters for various network checking and whether checks happen or not. Trusted networks are networks that you know never emit spam and are exempt from certain tests. This series of parameters also allows you to control timeouts and DNS checks. The defaults are reasonable for most installations.
Learning
The options in Figure 3.12 control the operation of the Bayesian analyzer and whitelisting integration with the Bayesian engine.
Most of the Bayesian learning options are acceptable as shipped and don't need to be adjusted. If there are issues with Bayesian scores, the thresholds can be adjusted via the bayes_auto_learn_threshold parameters. In case you want to turn off the Bayesian processing totally, set use_bayes to 0.
Table 3.12. Bayesian analysis engine options.
|
use_bayes ( 0 | 1 ) (default: 1) use_bayes_rules ( 0 | 1 ) (default: 1) auto_whitelist_factor n (default: 0.5, range [0..1]) auto_whitelist_db_modules Module ... (default: DB_File GDBM_File NDBM_File SDBM_File) bayes_auto_learn ( 0 | 1 ) (default: 1) bayes_auto_learn_threshold_nonspam n.nn (default: 0.1) bayes_auto_learn_threshold_spam n.nn (default: 12.0) bayes_ignore_header header_name bayes_ignore_from add@ress.com bayes_ignore_to add@ress.com bayes_min_ham_num (Default: 200) bayes_min_spam_num (Default: 200) bayes_learn_during_report (Default: 1) bayes_sql_override_username bayes_use_hapaxes (default: 1) bayes_use_chi2_combining (default: 1) bayes_journal_max_size (default: 102400) bayes_expiry_max_db_size (default: 150000) bayes_auto_expire (default: 1) bayes_learn_to_journal (default: 0) |
Miscellaneous
These keywords (Figure 3.13) define the templates for functions and other areas not defined previously.
Table 3.13. Miscellaneous options.
|
lock_method {nfssafe | flock | win32 } (default: no default)
fold_headers { 0 | 1 } (default: 1)
report_safe_copy_headers header_name ...
envelope_sender_header Name-Of-Header
describe SYMBOLIC_TEST_NAME description ...
report_charset CHARSET (default: unset)
report ...some text for a report...
clear_report_template
report_contact ...text of contact address...
report_hostname ...hostname to use...
unsafe_report ...some text for a report...
clear_unsafe_report_template
|
In the miscellaneous category, fold_headers controls whether the headers that SpamAssassin adds are broken up (the default) or kept as one single long line. If a mail client has issues with divided headers, this parameter can be adjusted.
Privileged Parameters
The end user is allowed to create his or her own spam checking rules if certain conditions apply.
Table 3.14. Administrator enabled or privileged settings.
|
allow_user_rules { 0 | 1 } (default: 0)
header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING]
header SYMBOLIC_TEST_NAME exists:name_of_header
header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])
header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone' [, 'sub-test'])
header SYMBOLIC_TEST_NAME eval:check_rbl_txt('set', 'zone')
header SYMBOLIC_TEST_NAME eval:check_rbl_sub('set', 'sub-test')
body SYMBOLIC_TEST_NAME /pattern/modifiers
body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
uri SYMBOLIC_TEST_NAME /pattern/modifiers
rawbody SYMBOLIC_TEST_NAME /pattern/modifiers
rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
full SYMBOLIC_TEST_NAME /pattern/modifiers
full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
meta SYMBOLIC_TEST_NAME boolean expression
meta SYMBOLIC_TEST_NAME boolean arithmetic expression
tflags SYMBOLIC_TEST_NAME [ {net|nice|learn|userconf|noautolearn} ]
priority SYMBOLIC_TEST_NAME n
|
A simple rule is shown in Figure 3.14 for illustrative purposes. More complex rules may require changes to configuration files and are beyond the scope of this book.
Example Rule
We want to create a simple rule that scans the message body and adds 10 points to the spam score if the phrase this is a test of spamassassin is present. Rules can be placed in the user's configuration file if allowed by the administrator. More commonly, they are placed in /etc/mail/spamassassin/local.cf by the administrator, which is the method we use here.
If you want to look at the default rules that are distributed with SpamAssassin, they are located by default in /usr/local/share/spamassassin. Although you can add or update the rules located here, this can cause problems when upgrading to future versions of SpamAssassin. The rules files that are distributed with SpamAssassin 2.63 are shown in Figure 3.15.
Table 3.15. SpamAssassin distributed rules.
|
0_misc.cf 20_anti_ratware.cf 20_body_tests.cf 20_compensate.cf 20_dnsbl_tests.cf 20_fake_helo_tests.cf 20_head_tests.cf 20_html_tests.cf 20_meta_tests.cf 20_phrases.cf 20_porn.cf 20_ratware.cf 20_uri_tests.cf 23_bayes.cf 25_body_tests_es.cf 25_body_tests_pl.cf 25_head_tests_es.cf 25_head_tests_pl.cf 30_text_de.cf 30_text_es.cf 30_text_fr.cf 30_text_it.cf 30_text_pl.cf 30_text_sk.cf 40_myrule.cf 50_scores.cf 60_whitelist.cf |
We update the local.cf file in /etc/mail/spamassassin with our new rule. The rule we want to add in local.cf consists of the following three lines:
body MY_SPAMASSASSIN_RULE /this is a test of spamassassin/is describe MY_SPAMASSASSIN_RULE Test of my spamassassin rule score MY_SPAMASSASSIN_RULE 10
The name of the rule is MY_SPAMASSASSIN_RULE. The line starting with body defines the test to run. In our case, the test is to match the pattern this is a test of spamassassin, ignoring the case of the string (indicated by i) and matching with embedded newlines (indicated by s). The pattern modifiers (our rule has one, is) are Perl regular expressions.
The second line gives a human-readable description to our rule—in our case Test of my spamassassin rule. Finally, the number of points to be added to the score is indicated by score—in our case 10. Note that the score can be any positive, negative, whole, or fractional value.
If SpamAssassin is configured to run this test, and a message is processed by the server that contains the string this is a test of spamassassin, a message similar to that in Figure 3.16 should be sent to the recipient. Sending a message like this is the default method of spam notification under SpamAssassin. The original message is included at the bottom of the message from SpamAssassin.
Table 3.16. Example of SpamAssassin notification message.
|
Subject: Spamassassin rule test From: somebody@example.com Date: Tue, 20 Jul 2004 11:07:27 -0400 To: dale@woody.cushman.avacoda.com Spam detection software, running on the system "woody.cushman.avacoda.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: This is a test of spamassassin. This message should be marked as spam. [...] Content analysis details: (15.0 points, 5.0 required) pts rule name description ---- ----------- -------------------------------------------------- 0.3 NO_REAL_NAME From: does not include a real name 10 MY_SPAMASSASSIN_RULE BODY: Test of my spamassassin rule 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay 1.4 DNS_FROM_RFCI_DSN RBL: From: sender listed in dsn.rfc-ignorant.org Subject: Spamassassin rule test From: somebody@example.com Date: Tue, 20 Jul 2004 11:07:27 -0400 To: dale@woody.cushman.avacoda.com This is a test of spamassassin. This message should be marked as spam. |
SpamAssassin assigned this message a score of 15.0 points, activating the following rules and associated scores:
|
Test |
Score |
|
NO_REAL_NAME |
0.3 |
|
MY_SPAMASSASSIN_RULE |
10 |
|
MSGID_FROM_MTA_SHORT |
3.3 |
|
DNS_FROM_RFCI_DSN |
1.4 |
The tests were activated due to the lack of a name in the From: header, the test rule we built containing the test phrase, the fact that a header was generated by a mail relay, and the fact that the From: sender is listed in a BLS blacklist.