SpamAssassin allows a large number of customization of user preferences. This page presents all the tunning you can add to SpamAssassin when it checks your emails for spam. Spam filtering

Name
Synopsis
Description
Tags
User preferences

Version options
Whitelist and blacklist options
Scoring options
Message tagging options
Language options
Network test options
Learning options
Deprecated options

Privileged preferences
Administrator preferences
Locali[sz]ation

Name

Mail::SpamAssassin::Conf - SpamAssassin configuration file

Synopsis

Description

SpamAssassin is configured using some traditional UNIX-style configuration files, loaded from the /usr/share/spamassassin and /etc/mail/spamassassin directories.

The "#" character starts a comment, which continues until end of line.

Whitespace in the files is not significant, but please note that starting a line with whitespace is deprecated, as we reserve its use for multi-line rule definitions, at some point in the future.

Currently, each rule or configuration setting must fit on one-line; multi-line settings are not supported yet.

Paths can use "~" to refer to the user's home directory.

Where appropriate, default values are listed in parentheses.

Tags

The following "tags" can be used as placeholders in certain options specified below. They will be replaced by the corresponding value when they are used.

Some tags can take an argument (in parentheses). The argument is optional, and the default is shown below.

_YESNOCAPS_		"YES"/"NO" for is/isn't spam
_YESNO_		"Yes"/"No" for is/isn't spam
_HITS_		message score
_REQD_		message threshold
_VERSION_		version (eg. 2.55)
_SUBVERSION_		sub-version (eg. 1.187-2003-05-15-exp)
_HOSTNAME_		hostname
_BAYES_		bayes score
_AWL_		AWL modifier
_DATE_		rfc-2822 date of scan
_STARS(*)_		one * (use any character) for each score point (50 at most)
_RELAYSTRUSTED_		relays used and deemed to be trusted
_RELAYSUNTRUSTED_		relays used that can not be trusted
_AUTOLEARN_		autolearn status ("ham", "no", "spam")
_TESTS(,)_		tests hit separated by , (or other separator)
_TESTSSCORES(,)_		as above, except with scores appended (eg. AWL=-3.0,...)
_DCCB_		DCC's "Brand"
_DCCR_		DCC's results
_PYZOR_		Pyzor results
_RBL_		full results for positive RBL queries in DNS URI format
_LANGUAGES_		possible languages of mail
_PREVIEW_		content preview
_REPORT_		terse report of tests hits (for header reports)
_SUMMARY_		summary of tests hit for standard report (for body reports)
_CONTACTADDRESS_		contents of the 'report_contact' setting

User preferences

User preferences are read from the file ~/.spamassassin/user_prefs, in the sub-directory .spamassassin located in every user's home-dir.

The following options can be used in both site-wide ("local.cf") and user-specific ("user_prefs") configuration files to customize how SpamAssassin handles incoming email messages.

Version options

require_version n.nn

Indicates that the entire file, from this line on, requires a certain version of SpamAssassin to run. If an older or newer version of SpamAssassin tries to read configuration from this file, it will output a warning instead, and ignore it.

version_tag string

This tag is appended to the SA version in the X-Spam-Status header. You should include it when modify your ruleset, especially if you plan to distribute it. A good choice for string is your last name or your initials followed by a number which you increase with each change.

e.g.

version_tag myrules1 # version=2.41-myrules1

Whitelist and blacklist options

whitelist_from add@ress.com

Used to specify addresses which send mail that is often tagged (incorrectly) as spam; it also helps if they are addresses of big companies with lots of lawyers. This way, if spammers impersonate them, they'll get into big trouble, so it doesn't provide a shortcut around SpamAssassin.

Whitelist and blacklist addresses are now file-glob-style patterns, so "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all work. Specifically, "*" and "?" are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons.

Multiple addresses per line, separated by spaces, is OK. Multiple "whitelist_from" lines is also OK.

The headers checked for whitelist addresses are as follows: if "Resent-From" is set, use that; otherwise check all addresses taken from the following set of headers:

Envelope-Sender
Resent-Sender
X-Envelope-From
From

e.g.

whitelist_from joe@example.com fred@example.com
whitelist_from *@example.com

unwhitelist_from add@ress.com

Used to override a default whitelist_from entry, so for example a distribution whitelist_from can be overridden in a local.cf file, or an individual user can override a whitelist_from entry in their own "user_prefs" file. The specified email address has to match exactly the address previously used in a whitelist_from line. e.g.

unwhitelist_from joe@example.com fred@example.com
unwhitelist_from *@example.com

whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net

Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS.

This string is matched against the reverse DNS lookup used during the handover from the untrusted internet to your trusted network's mail exchangers. It can either be the full hostname, or the domain component of that hostname. In other words, if the host that connected to your MX had an IP address that mapped to 'sendinghost.spamassassin.org', you should specify "sendinghost.spamassassin.org" or just "spamassassin.org" here.

Note that this requires that "trusted_networks" be correct. For simple cases, it will be, but for a complex network, or if you're running with DNS checks off or with "-L", you may get better results by setting that parameter.

e.g.

whitelist_from_rcvd joe@example.com example.com
whitelist_from_rcvd *@axkit.org sergeant.org

def_whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net

Same as "whitelist_from_rcvd", but used for the default whitelist entries in the SpamAssassin distribution. The whitelist score is lower, because these are often targets for spammer spoofing.

unwhitelist_from_rcvd add@ress.com

Used to override a default whitelist_from_rcvd entry, so for example a distribution whitelist_from_rcvd can be overridden in a local.cf file, or an individual user can override a whitelist_from_rcvd entry in their own "user_prefs" file.

The specified email address has to match exactly the address previously used in a whitelist_from_rcvd line.

e.g.

unwhitelist_from_rcvd joe@example.com fred@example.com
unwhitelist_from_rcvd *@axkit.org

blacklist_from add@ress.com

Used to specify addresses which send mail that is often tagged (incorrectly) as non-spam, but which the user doesn't want. Same format as "whitelist_from".

unblacklist_from add@ress.com

Used to override a default blacklist_from entry, so for example a distribution blacklist_from can be overridden in a local.cf file, or an individual user can override a blacklist_from entry in their own "user_prefs" file.

e.g.

unblacklist_from joe@example.com fred@example.com
unblacklist_from *@spammer.com

whitelist_to add@ress.com

If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be whitelisted. Useful if you're deploying SpamAssassin system-wide, and don't want some users to have their mail filtered. Same format as "whitelist_from".

There are three levels of To-whitelisting, "whitelist_to", "more_spam_to" and "all_spam_to". Users in the first level may still get some spammish mails blocked, but users in "all_spam_to" should never get mail blocked.

more_spam_to add@ress.com

See above.

all_spam_to add@ress.com

See above.

blacklist_to add@ress.com

If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be blacklisted. Same format as "blacklist_from".

Scoring options

required_hits n.nn (default: 5)

Set the number of hits required before a mail is considered spam. "n.nn" can be an integer or a real number. 5.0 is the default setting, and is quite aggressive; it would be suitable for a single-user setup, but if you're an ISP installing SpamAssassin, you should probably set the default to be more conservative, like 8.0 or 10.0. It is not recommended to automatically delete or discard messages marked as spam, as your users will complain, but if you choose to do so, only delete messages with an exceptionally high score such as 15.0 or higher.

score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]

Assign scores (the number of points for a hit) to a given test. Scores can be positive or negative real numbers or integers. "SYMBOLIC_TEST_NAME" is the symbolic name used by SpamAssassin for that test; for example, 'FROM_ENDS_IN_NUMS'.

If only one valid score is listed, then that score is always used for a test.

If four valid scores are listed, then the score that is used depends on how SpamAssassin is being used. The first score is used when both Bayes and network tests are disabled. The second score is used when Bayes is disabled, but network tests are enabled. The third score is used when Bayes is enabled and network tests are disabled. The fourth score is used when Bayes is enabled and net- work tests are enabled.

Setting a rule's score to 0 will disable that rule from running.

Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports.

If no score is given for a test, the default score is 1.0, or 0.01 for tests whose names begin with 'T_' (this is used to indicate a rule in testing).

By convention, rule names are be all uppercase and have a length of no more than 22 characters.

Message tagging options

rewrite_subject { 0 | 1 } (default: 0)

By default, the subject lines of suspected spam will not be tagged. This can be enabled here.

fold_headers { 0 | 1 } (default: 1)

By default, headers added by SpamAssassin will be whitespace folded. In other words, they will be broken up into multiple lines instead of one very long one and each other line will have a tabu- lator prepended to mark it as a continuation of the preceding one.

The automatic wrapping can be disabled here (which can generate very long lines).

add_header { spam | ham | all } header_name string

Customized headers can be added to the specified type of messages (spam, ham, or "all" to add to either). All headers begin with "X-Spam-" (so a "header_name" Foo will generate a header called X-Spam-Foo).

"string" can contain tags as explained above in the TAGS section. You can also use "\n" and "\t" in the header to add newlines and tabulators as desired. A backslash has to be written as \\, any other escaped chars will be silently removed.

All headers will be folded if fold_headers is set to 1. Note: Manually adding newlines via "\n" disables any further automatic wrapping (ie: long header lines are possible). The lines will still be properly folded (marked as continuing) though.

For backwards compatibility, some headers are (still) added by default. You can customize existing headers with add_header (only the specified subset of messages will be changed).

See also "clear_headers" for removing headers.

Here are some examples (these are the defaults in 2.60):

add_header spam Flag _YESNOCAPS_
add_header all Status _YESNO_, hits=_HITS_ 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

Headers can be removed from the specified type of messages (spam, ham, or "all" to remove from either). All headers begin with "X-Spam-" (so "header_name" will be appended to "X-Spam-").

See also "clear_headers" for removing all the headers at once.

Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators and developers to debug problems. Without at least one header, it might not even be possible to determine that SpamAssassin is running.

clear_headers

Clear the list of headers to be added to messages. You may use this before any add_header options to prevent the default headers from being added to the message.

Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators and developers to debug problems. Without at least one header, it might not even be possible to determine that SpamAssassin is running.

report_safe_copy_headers header_name ...

If using report_safe, a few of the headers from the original message are copied into the wrapper header (From, To, Cc, Subject, Date, etc.) If you want to have other headers copied as well, you can add them using this option. You can specify multiple headers on the same line, separated by spaces, or you can just use multiple lines.

subject_tag STRING ... (default: *****SPAM*****)

Text added to the "Subject:" line of mails that are considered spam, if "rewrite_subject" is 1. Tags can be used here as with the add_header option. If report_safe is not used (see below), you may only use the _HITS_ and _REQD_ tags, or SpamAssassin will not be able to remove this markup from your message.

report_safe { 0 | 1 | 2 } (default: 1)

If this option is set to 1, if an incoming message is tagged as spam, instead of modifying the original message, SpamAssassin will create a new report message and attach the original message as a message/rfc822 MIME part (ensuring the original message is completely preserved, not easily opened, and easier to recover).

If this option is set to 2, then original messages will be attached with a content type of text/plain instead of message/rfc822. This setting may be required for safety reasons on certain broken mail clients that automatically load attachments without any action by the user. This setting may also make it somewhat more difficult to extract or view the original message.

If this option is set to 0, incoming spam is only modified by adding some "X-Spam-" headers and no changes will be made to the body. In addition, a header named X-Spam-Report will be added to spam. You can use the remove_header option to remove that header after setting report_safe to 0.

report_charset CHARSET (default: unset)

Set the MIME Content-Type charset used for the text/plain report which is attached to spam mail messages.

report ...some text for a report...

Set the report template which is attached to spam mail messages. See the "10_misc.cf" configuration file in "/usr/share/spamassassin" for an example.

If you change this, try to keep it under 78 columns. Each "report" line appends to the existing template, so use "clear_report_template" to restart.

Tags can be included as explained above.

clear_report_template

Clear the report template.

report_contact ...text of contact address...

Set what _CONTACTADDRESS_ is replaced with in the above report text. By default, this is 'the administrator of that system', since the hostname of the system the scanner is running on is also included.

unsafe_report ...some text for a report...

Set the report template which is attached to spam mail messages which contain a non-text/plain part. See the "10_misc.cf" configuration file in "/usr/share/spamassassin" for an example.

Each "unsafe-report" line appends to the existing template, so use "clear_unsafe_report_template" to restart.

Tags can be used in this template (see above for details).

clear_unsafe_report_template

Clear the unsafe_report template.

spamtrap ...some text for spamtrap reply mail...

A template for spam-trap responses. If the first few lines begin with "Xxxxxx: yyy" where Xxxxxx is a header and yyy is some text, they'll be used as headers. See the "10_misc.cf" configuration file in "/usr/share/spamassassin" for an example.

Unfortunately tags can not be used with this option.

clear_spamtrap_template

Clear the spamtrap template.

describe SYMBOLIC_TEST_NAME description ...

Used to describe a test. This text is shown to users in the detailed report.

Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports.

Also note that by convention, rule descriptions should be limited in length to no more than 50 characters.

Laguage options

ok_languages xx [ yy zz ... ] (default: all)

This option is used to specify which languages are considered OK for incoming mail. SpamAssassin will try to detect the language used in the message text.

Note that the language cannot always be recognized with sufficient confidence. In that case, no points will be assigned.

The rule "UNWANTED_LANGUAGE_BODY" is triggered based on how this is set.

In your configuration, you must use the two or three letter language specifier in lowercase, not the English name for the language. You may also specify "all" if a desired language is not listed, or if you want to allow any language. The default setting is "all".

Examples:

ok_languages all		(allow all languages)
ok_languages en		(only allow English)
ok_languages en ja zh		(allow English, Japanese, and Chinese)

Note: if there are multiple ok_languages lines, only the last one is used.

Select the languages to allow from the list below:

af		Afrikaans	am		Amharic	ar		Arabic
be		Byelorussian	bg		Bulgarian	bs		Bosnian
ca		Catalan	cs		Czech	cy		Welsh
da		Danish	de		German	el		Greek
en		English	eo		Esperanto	es		Spanish
et		Estonian	eu		Basque	fa		Persian
fi		Finnish	fr		French	fy		Frisian
ga		Irish Gaelic	gd		Scottish Gaelic	he		Hebrew
hi		Hindi	hr		Croatian	hu		Hungarian
hy		Armenian	id		Indonesian	is		Icelandic
it		Italian	ja		Japanese	ka		Georgian
ko		Korean	la		Latin	lt		Lithuanian
lv		Latvian	mr		Marathi	ms		Malay
ne		Nepali	nl		Dutch	no		Norwegian
pl		Polish	pt		Portuguese	qu		Quechua
rm		Rhaeto-Romance	ro		Romanian	ru		Russian
sa		Sanskrit	sco		Scots	sk		Slovak
sl		Slovenian	sq		Albanian	sr		Serbian
sv		Swedish	sw		Swahili	ta		Tamil
th		Thai	tl		Tagalog	tr		Turkish
uk		Ukrainian	vi		Vietnamese	yi		Yiddish
zh		Chinese

ok_locales xx [ yy zz ... ] (default: all)

This option is used to specify which locales (country codes) are considered OK for incoming mail. Mail using character sets used by languages in these countries will not be marked as possibly being spam in a foreign language.

If you receive lots of spam in foreign languages, and never get any non-spam in these languages, this may help. Note that all ISO-8859-* character sets, and Windows code page character sets, are always permitted by default.

Set this to "all" to allow all character sets. This is the default.

The rules "CHARSET_FARAWAY", "CHARSET_FARAWAY_BODY", and "CHARSET_FARAWAY_HEADERS" are triggered based on how this is set.

Examples:

ok_locales all		(allow all locales)
ok_locales en		(only allow English)
ok_locales en ja zh		(allow English, Japanese, and Chinese)

Note: if there are multiple ok_locales lines, only the last one is used.

Select the locales to allow from the list below:

en		Western character sets in general	ja		Japanese character sets
ko		Korean character sets	ru		Cyrillic character sets
th		Thai character sets	zh		Chinese (both simplified and traditional) character sets

Network test options

use_dcc { 0 | 1 } (default: 1)

Whether to use DCC, if it is available.

dcc_timeout n (default: 10)

How many seconds you wait for dcc to complete before you go on without the results.

dcc_body_max NUMBER
dcc_fuz1_max NUMBER
dcc_fuz2_max NUMBER

DCC (Distributed Checksum Clearinghouse) is a system similar to Razor. This option sets how often a message's body/fuz1/fuz2 checksum must have been reported to the DCC server before SpamAssassin will consider the DCC check as matched.

As nearly all DCC clients are auto-reporting these checksums you should set this to a relatively high value, e.g. 999999 (this is DCC's MANY count).

The default is 999999 for all these options.

use_pyzor { 0 | 1 } (default: 1)

Whether to use Pyzor, if it is available.

pyzor_timeout n (default: 10)

How many seconds you wait for Pyzor to complete before you go on without the results.

pyzor_max NUMBER

Pyzor is a system similar to Razor. This option sets how often a message's body checksum must have been reported to the Pyzor server before SpamAssassin will consider the Pyzor check as matched.

The default is 5.

pyzor_options options

Specify options to the pyzor command. Please note that only [A-Za-z0-9 -/] is allowed (security).

trusted_networks ip.add.re.ss[/mask] ... (default: none)

What networks or hosts are 'trusted' in your setup. Trusted in this case means that relay hosts on these networks are considered to not be potentially operated by spammers, open relays, or open proxies. DNS blacklist checks will never query for hosts on these networks.

If a "/mask" is specified, it's considered a CIDR-style 'netmask', specified in bits. If it is not specified, but less than 4 octets are specified with a trailing dot, that's considered a mask to allow all addresses in the remaining octets. If a mask is not specified, and there is not trailing dot, then just the single IP address specified is used, as if the mask was "/32".

Examples:

trusted_networks 192.168/16 127/8		# all in 192.168.*.* and 127.*.*.*
trusted_networks 212.17.35.15		# just that host
trusted_networks 127.		# all in 127.*.*.*

This operates additively, so a "trusted_networks" line after another one will result in all those networks becoming trusted. To clear out the existing entries, use "clear_trusted_networks".

If you're running with DNS checks enabled, SpamAssassin includes code to infer your trusted networks on the fly, so this may not be necessary. (Thanks to Scott Banister and Andrew Flury for the inspiration for this algorithm.) This inference works as follows:

• if the 'from' IP address is on the same /16 network as the top Received line's 'by' host, it's trusted
• if the address of the 'from' host is in a reserved network range, then it's trusted
• if any addresses of the 'by' host is in a reserved network range, then it's trusted

clear_trusted_networks

Empty the list of trusted networks.

use_razor2 { 0 | 1 } (default: 1)

Whether to use Razor version 2, if it is available.

razor_timeout n (default: 10)

How many seconds you wait for razor to complete before you go on without the results.

use_bayes { 0 | 1 } (default: 1)

Whether to use the naive-Bayesian-style classifier built into SpamAssassin.

skip_rbl_checks { 0 | 1 } (default: 0)

By default, SpamAssassin will run RBL checks. If your ISP already does this for you, set this to 1.

rbl_timeout n (default: 15)

All RBL queries are made at the beginning of a check and we try to read the results at the end. This value specifies the maximum period of time to wait for an RBL query. If most of the RBL queries have succeeded for a particular message, then SpamAssassin will not wait for the full period to avoid wasting time on unresponsive server(s). For the default 15 second timeout, here is a chart of queries remaining versus the effective timeout in seconds:

queries left	100	%	90	%	80	%	70	%	60	%	50	%	40	%	30	%	20	%	10	%	0	%
timeout	15		15		14		14		13		11		10		8		5		3		0

In addition, whenever the effective timeout is lowered due to additional query results returning, the remaining queries are always given at least one more second before timing out, but the wait time will never exceed rbl_timeout.

For example, if 20 queries are made at the beginning of a message check and 16 queries have returned (leaving 20%), the remaining 4 queries must finish within 5 seconds of the beginning of the check or they will be timed out.

check_mx_attempts n (default: 2)

By default, SpamAssassin checks the From: address for a valid MX this many times, waiting 5 seconds each time.

check_mx_delay n (default: 5)

How many seconds to wait before retrying an MX check.

dns_available { yes | test[: name1 name2...] | no } (default: test)

By default, SpamAssassin will query some default hosts on the internet to attempt to check if DNS is working on not. The problem is that it can introduce some delay if your network connection is down, and in some cases it can wrongly guess that DNS is unavailable because the test connections failed. SpamAssassin includes a default set of 13 servers, among which 3 are picked randomly.

You can however specify your own list by specifying:

dns_available test: server1.tld server2.tld server3.tld

Please note, the DNS test queries for MX records so if you specify your own list of servers, please make sure to choose the one(s) which has an associated MX record.

Learning options

auto_whitelist_factor n (default: 0.5, range [0..1])

How much towards the long-term mean for the sender to regress a message. Basically, the algorithm is to track the long-term mean score of messages for the sender ("mean"), and then once we have otherwise fully calculated the score for this message ("score"), we calculate the final score for the message as:

"finalscore" = "score" + ("mean" - "score") * "factor"

So if "factor" = 0.5, then we'll move to half way between the calculated score and the mean. If "factor" = 0.3, then we'll move about 1/3 of the way from the score toward the mean. "factor" = 1 means just use the long-term mean; "factor" = 0 mean just use the calculated score.

bayes_auto_learn ( 0 | 1 ) (default: 1)

Whether SpamAssassin should automatically feed high-scoring mails (or low-scoring mails, for non-spam) into its learning systems. The only learning system supported currently is a naive-Bayesian-style classifier.

Note that certain tests are ignored when determining whether a message should be trained upon:

• auto-whitelist (AWL)
• rules with tflags set to 'learn' (the Bayesian rules)
• rules with tflags set to 'userconf' (user white/black-listing rules, etc.)

Also note that auto-training occurs using scores from either score-set 0 or 1, depending on what scoreset is used during message check. It is likely that the message check and auto-train scores will be different.

bayes_auto_learn_threshold_nonspam n.nn (default: 0.1)

The score threshold below which a mail has to score, to be fed into SpamAssassin's learning systems automatically as a non-spam message.

bayes_auto_learn_threshold_spam n.nn (default: 12.0)

The score threshold above which a mail has to score, to be fed into SpamAssassin's learning systems automatically as a spam message.

Note: SpamAssassin requires at least 3 points from the header, and 3 points from the body to auto-learn as spam. Therefore, the minimum working value for this option is 6.

bayes_ignore_header header_name

If you receive mail filtered by upstream mail systems, like a spam-filtering ISP or mailing list, and that service adds new headers (as most of them do), these headers may provide inappropriate cues to the Bayesian classifier, allowing it to take a "short cut". To avoid this, list the headers using this setting. Example:

bayes_ignore_header X-Upstream-Spamfilter
bayes_ignore_header X-Upstream-SomethingElse

bayes_min_ham_num (Default: 200)
bayes_min_spam_num (Default: 200)

To be accurate, the Bayes system does not activate until a certain number of ham (non-spam) and spam have been learned. The default is 200 of each ham and spam, but you can tune these up or down with these two settings.

bayes_learn_during_report (Default: 1)

The Bayes system will, by default, learn any reported messages ("spamassassin -r") as spam. If you do not want this to happen, set this option to 0.

Deprecated options

always_add_headers { 0 | 1 } (default: 1)

By default, X-Spam-Status and X-Spam-Level will be added to all messages scanned by SpamAssassin. If you don't want to add those headers to non-spam, set this value to 0.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Instead, use the clear_headers and add_header options to customize headers.

always_add_report { 0 | 1 } (default: 0)

When the report_safe option is turned off, mail tagged as spam will include a report in a header named X-Spam-Report. If you set always_add_report to 1, the report will also be included in the X-Spam-Report header for non-spam mail.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the flexible add_header option instead:

add_header all Report _REPORT_

spam_level_stars { 0 | 1 } (default: 1)

By default, a header field called "X-Spam-Level" will be added to the message, with its value set to a number of asterisks equal to the score of the message. In other words, for a message scoring 7.2 points:

X-Spam-Level: *******

This can be useful for MUA rule creation.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the add_header option instead:

add_header all Level _STARS(*)_

spam_level_char { x (some character, unquoted) } (default: *)

By default, the "X-Spam-Level" header will use a '*' character with its length equal to the score of the message. Some people don't like escaping *s though, so you can set the character to anything with this option.

In other words, for a message scoring 7.2 points with this option set to .

X-Spam-Level: .......

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the add_header option instead:

add_header all Level _STARS(.)_

dcc_add_header { 0 | 1 } (default: 0)

DCC processing creates a message header containing the statistics for the message. This option sets whether SpamAssassin will add the heading to messages it processes.

The default is to not add the header.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the add_header option instead:

add_header all DCC _DCCB_: _DCCR_

pyzor_add_header { 0 | 1 } (default: 0)

Pyzor processing creates a message header containing the statistics for the message. This option sets whether SpamAssassin will add the heading to messages it processes.

The default is to not add the header.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the add_header option instead:

add_header all Pyzor _PYZOR_

num_check_received { integer } (default: 9)

How many received lines from and including the original mail relay do we check in RBLs (at least 1 or 2 is recommended).

Note that for checking against dialup lists, you can call "check_rbl()" with a special set name of set-notfirsthop and this rule will only be matched against the relays except for the very first one; this allows SpamAssassin to catch dialup-sent spam, without penalizing people who properly relay through their ISP.

This option is deprecated in version 2.60 and later. It will be removed in a future version. Please use the "trusted_networks" option instead (it is a much better way to control DNSBL-checking behaviour).

use_terse_report { 0 | 1 } (default: 1)

This option is deprecated and does nothing. It will be removed in a future version.

terse_report ...some text for a report...

This option is deprecated and does nothing. It will be removed in a future version.

clear_terse_report_template

This option is deprecated and does nothing. It will be removed in a future version.

Privileged settings

These settings differ from the ones above, in that they are considered 'privileged'. Only users running "spamassassin" from their procmailrc's or forward files, or sysadmins editing a file in "/etc/mail/spamassassin", can use them. "spamd" users cannot use them in their "user_prefs" files, for security and efficiency reasons, unless allow_user_rules is enabled (and then, they may only add rules from below).

allow_user_rules { 0 | 1 } (default: 0)

This setting allows users to create rules (and only rules) in their "user_prefs" files for use with "spamd". It defaults to off, because this could be a severe security hole. It may be possible for users to gain root level access if "spamd" is run as root. It is NOT a good idea, unless you have some other way of ensuring that users' tests are safe. Don't use this unless you are certain you know what you are doing. Furthermore, this option causes spamassassin to recompile all the tests each time it processes a message for a user with a rule in his/her "user_prefs" file, which could have a significant effect on server load. It is not recommended.

Note that it is not currently possible to use "allow_user_rules" to modify an existing system rule from a "user_prefs" file with "spamd".

header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING]

Define a test. "SYMBOLIC_TEST_NAME" is a symbolic test name, such as 'FROM_ENDS_IN_NUMS'. "header" is the name of a mail header, such as 'Subject', 'To', etc.

'ALL' can be used to mean the text of all the message's headers. 'ToCc' can be used to mean the contents of both the 'To' and 'Cc' headers.

'MESSAGEID' is a symbol meaning all Message-Id's found in the message; some mailing list software moves the real Message-Id to 'Resent-Message-Id' or 'X-Message-Id', then uses its own one in the 'Message-Id' header. The value returned for this symbol is the text from all 3 headers, separated by newlines.

"op" is either "=~" (contains regular expression) or "!~" (does not contain regular expression), and "pattern" is a valid Perl regular expression, with "modifiers" as regexp modifiers in the usual style. Note that multi-line rules are not supported, even if you use "x" as a modifier.

If the "[if-unset: STRING]" tag is present, then "STRING" will be used if the header is not found in the mail message.

Test names should not start with a number, and must contain only alphanumerics and underscores. It is suggested that lower-case characters not be used, as an informal convention. Dashes are not allowed.

Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports. Test names which begin with 'T_' are reserved for tests which are undergoing QA, and these are given a very low score.

If you add or modify a test, please be sure to run a sanity check afterwards by running "spamassassin --lint". This will avoid confusing error messages, or other tests being skipped as a side-effect.

header SYMBOLIC_TEST_NAME exists:name_of_header

Define a header existence test. "name_of_header" is the name of a header to test for existence. This is just a very simple version of the above header tests.

header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])

Define a header eval test. "name_of_eval_method" is the name of a method on the "Mail::SpamAssassin::EvalTests" object. "arguments" are optional arguments to the function call.

header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone')

Check a DNSBL (DNS blacklist), also known as RBLs (realtime black- lists). This will retrieve Received headers from the mail, parse the IP addresses, select which ones are 'untrusted' based on the "trusted_networks" logic, and query that blacklist. There's a few things to note:

Duplicated or reserved IPs

These are stripped, and the DNSBLs will not be queried for them. Reserved IPs are those listed in <http://www.iana.org/assignments/ipv4-address-space>, <http://duxcw.com/faq/network/privip.htm>, or <http://duxcw.com/faq/network/autoip.htm>.

The first argument, 'set'

This is used as a 'zone ID'. If you want to look up a multi-meaning zone like relays.osirusoft.com, you can then query the results from that zone using it; but all check_rbl_sub() calls must use that zone ID.

Also, if an IP gets a hit in one lookup in a zone using that ID, any further hits in other rules using that zone ID will not be added to the score.

Selecting all IPs except for the originating one

This is accomplished by naming the set 'foo-notfirsthop'. Useful for querying against DNS lists which list dialup IP addresses; the first hop may be a dialup, but as long as there is at least one more hop, via their outgoing SMTP server, that's legitimate, and so should not gain points. If there is only one hop, that will be queried anyway, as it should be relaying via its outgoing SMTP server instead of sending directly to your MX.

Selecting IPs by whether they are trusted

When checking a 'nice' DNSBL (a DNS whitelist), you cannot trust the IP addresses in Received headers that were not added by trusted relays. To test the first IP address that can be trusted, name the set 'foo-firsttrusted'. That should test the IP address of the relay that connected to the most remote trusted relay.

In addition, you can test all untrusted IP addresses by naming the set 'foo-untrusted'.

Note that this requires that SpamAssassin know which relays are trusted. For simple cases, SpamAssassin can make a good estimate. For complex cases, you may get better results by setting "trusted_networks" manually.

header SYMBOLIC_TEST_NAME eval:check_rbl_txt('set', 'zone')

Same as check_rbl(), except querying using IN TXT instead of IN A records. If the zone supports it, it will result in a line of text describing why the IP is listed, typically a hyperlink to a database entry.

header SYMBOLIC_TEST_NAME eval:check_rbl_sub('set', 'sub-test')

Create a sub-test for 'set'. If you want to look up a multi-meaning zone like relays.osirusoft.com, you can then query the results from that zone using the zone ID from the original query. The sub-test may either be an IPv4 dotted address for RBLs that return multiple A records or a non-negative decimal number to specify a bitmask for RBLs that return a single A record containing a bitmask of results.

body SYMBOLIC_TEST_NAME /pattern/modifiers

Define a body pattern test. "pattern" is a Perl regular expression.

The 'body' in this case is the textual parts of the message body; any non-text MIME parts are stripped, and the message decoded from Quoted-Printable or Base-64-encoded format if necessary. The message Subject header is considered part of the body and becomes the first paragraph when running the rules. All HTML tags and line breaks will be removed before matching.

body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

Define a body eval test. See above.

uri SYMBOLIC_TEST_NAME /pattern/modifiers

Define a uri pattern test. "pattern" is a Perl regular expression.

The 'uri' in this case is a list of all the URIs in the body of the email, and the test will be run on each and every one of those URIs, adjusting the score if a match is found. Use this test instead of one of the body tests when you need to match a URI, as it is more accurately bound to the start/end points of the URI, and will also be faster.

rawbody SYMBOLIC_TEST_NAME /pattern/modifiers

Define a raw-body pattern test. "pattern" is a Perl regular expression.

The 'raw body' of a message is the text, including all textual parts. The text will be decoded from base64 or quoted-printable encoding, but HTML tags and line breaks will still be present.

rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

Define a raw-body eval test. See above.

full SYMBOLIC_TEST_NAME /pattern/modifiers

Define a full-body pattern test. "pattern" is a Perl regular expression.

The 'full body' of a message is the un-decoded text, including all parts (including images or other attachments). SpamAssassin no longer tests full tests against decoded text; use "rawbody" for that.

full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

Define a full-body eval test. See above.

meta SYMBOLIC_TEST_NAME boolean expression

Define a boolean expression test in terms of other tests that have been hit or not hit. For example:

meta META1 TEST1 && !(TEST2 || TEST3)

Note that English language operators ("and", "or") will be treated as rule names, and that there is no "XOR" operator.

meta SYMBOLIC_TEST_NAME boolean arithmetic expression

Can also define a boolean arithmetic expression in terms of other tests, with a hit test having the value "1" and an unhit test hav- ing the value "0". For example:

meta META2 (3 * TEST1 - 2 * TEST2) > 0

Note that Perl builtins and functions, like "abs()", can't be used, and will be treated as rule names.

If you want to define a meta-rule, but do not want its individual sub-rules to count towards the final score unless the entire meta-rule matches, give the sub-rules names that start with '__' (two underscores). SpamAssassin will ignore these for scoring.

tflags SYMBOLIC_TEST_NAME [ { net | nice | learn | userconf } ... ]

Used to set flags on a test. These flags are used in the score-determination back end system for details of the test's behaviour. The following flags can be set:

net

The test is a network test, and will not be run in the mass checking system or if -L is used, therefore its score should not be modified.

nice

The test is intended to compensate for common false positives, and should be assigned a negative score.

userconf

The test requires user configuration before it can be used (like language- specific tests).

learn

The test requires training before it can be used.

Administrator settings

These settings differ from the ones above, in that they are considered 'more privileged' — even more than the ones in the SETTINGS section. No matter what "allow_user_rules" is set to, these can never be set from a user's "user_prefs" file.

test SYMBOLIC_TEST_NAME {ok|fail}

Some string to test against Define a regression testing string. You can have more than one regression test string per symbolic test name. Simply specify a string that you wish the test to match.

These tests are only run as part of the test suite — they should not affect the general running of SpamAssassin.

razor_config filename

Define the filename used to store Razor's configuration settings. Currently this is left to Razor to decide.

pyzor_path STRING

This option tells SpamAssassin specifically where to find the "pyzor" client instead of relying on SpamAssassin to find it in the current PATH. Note that if taint mode is enabled in the Perl interpreter, you should use this, as the current PATH will have been cleared.

dcc_home STRING

This option tells SpamAssassin specifically where to find the dcc homedir. If "dcc_path" is not specified, it will default to looking in "dcc_home/bin" for dcc client instead of relying on SpamAssassin to find it in the current PATH. If it isn't found there, it will look in the current PATH. If a "dccifd" socket is found in "dcc_home", it will use that interface that instead of "dccproc".

dcc_dccifd_path STRING

This option tells SpamAssassin specifically where to find the dccifd socket. If "dcc_dccifd_path" is not specified, it will default to looking in "dcc_home" If a "dccifd" socket is found, it will use it instead of "dccproc".

dcc_path STRING

This option tells SpamAssassin specifically where to find the "dccproc" client instead of relying on SpamAssassin to find it in the current PATH. Note that if taint mode is enabled in the Perl interpreter, you should use this, as the current PATH will have been cleared.

dcc_options options

Specify additional options to the dccproc(8) command. Please note that only [A-Z -] is allowed (security).

The default is "-R".

auto_whitelist_path /path/to/file (default: ~/.spamassassin/auto-whitelist)

Automatic-whitelist directory or file. By default, each user has their own, in their "~/.spamassassin" directory with mode 0700, but for system-wide SpamAssassin use, you may want to share this across all users.

bayes_path /path/to/file (default: ~/.spamassassin/bayes)

Path for Bayesian probabilities databases. Several databases will be created, with this as the base, with "_toks", "_seen" etc. appended to this filename; so the default setting results in files called "~/.spamassassin/bayes_seen", "~/.spamassassin/bayes_toks" etc.

By default, each user has their own, in their "~/.spamassassin" directory with mode 0700/0600, but for system-wide SpamAssassin use, you may want to reduce disk space usage by sharing this across all users. (However it should be noted that Bayesian filtering appears to be more effective with an individual database per user.)

auto_whitelist_file_mode (default: 0700)

The file mode bits used for the automatic-whitelist directory or file.

Make sure you specify this using the 'x' mode bits set, as it may also be used to create directories. However, if a file is created, the resulting file will not have any execute bits set (the umask is set to 111).

bayes_file_mode (default: 0700)

The file mode bits used for the Bayesian filtering database files.

Make sure you specify this using the 'x' mode bits set, as it may also be used to create directories. However, if a file is created, the resulting file will not have any execute bits set (the umask is set to 111).

bayes_use_hapaxes (default: 1)

Should the Bayesian classifier use hapaxes (words/tokens that occur only once) when classifying? This produces significantly better hit-rates, but increases database size by about a factor of 8 to 10.

bayes_use_chi2_combining (default: 1)

Should the Bayesian classifier use chi-squared combining, instead of Robinson/Graham-style naive Bayesian combining? Chi-squared produces more 'extreme' output results, but may be more resistant to changes in corpus size etc.

bayes_journal_max_size (default: 102400)

SpamAssassin will opportunistically sync the journal and the database. It will do so at least once a day, but can also sync if the file size goes above this setting, in bytes. If set to 0, the journal sync will only occur once a day.

bayes_expiry_max_db_size (default: 150000)

What should be the maximum size of the Bayes tokens database? When expiry occurs, the Bayes system will keep either 75% of the maximum value, or 100,000 tokens, whichever has a larger value. 150,000 tokens is roughly equivalent to a 8Mb database file.

bayes_auto_expire (default: 1)

If enabled, the Bayes system will try to automatically expire old tokens from the database. Auto-expiry occurs when the number of tokens in the database surpasses the bayes_expiry_max_db_size value.

bayes_learn_to_journal (default: 0)

If this option is set, whenever SpamAssassin does Bayes learning, it will put the information into the journal instead of directly into the database. This lowers contention for locking the database to execute an update, but will also cause more access to the journal and cause a delay before the updates are actually committed to the Bayes database.

user_scores_dsn DBI:databasetype:databasename:hostname:port

If you load user scores from an SQL database, this will set the DSN used to connect. Example: "DBI:mysql:spamassassin:localhost".

user_scores_sql_username username

The authorized username to connect to the above DSN.

user_scores_sql_password password

The password for the database username, for the above DSN.

user_scores_sql_table tablename

The table user preferences are stored in, for the above DSN.

user_scores_sql_field_username field_username

The field that the username whose preferences you're looking up is stored in. Default: "username".

user_scores_sql_field_preference field_preference

The name of the preference that you're looking for. Default: "preference".

user_scores_sql_field_value field_value

The name of the value you're looking for. Default: "value".

user_scores_sql_field_scope field_scope

The 'scope' field. In Horde this makes the preference a single-module preference or a global preference. There's no real need to change it in other systems. Default: "spamassassin".

Locali[sz]ation

A line starting with the text "lang xx" will only be interpreted if the user is in that locale, allowing test descriptions and templates to be set for that language.

Contact us: Olivier Nicole

Last update: Jun 2004