Mail::SpamAssassin::Conf(3)

Index for
Section 3

Alphabetical
listing for M

Bottom of
page

Mail::SpamAssassin::CoUnsfe(r3)Contributed
NAME
Mail::SpamAssassin::Conf - SpamAssassin configuration file

SYNOPSIS
# a comment

rewrite_header Subject *****SPAM*****

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

score A_HREF_TO_REMOVE 2.0

lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com

DESCRIPTION
SpamAssassin is configured using 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.
NOTE: using the "#" character in the regular expression rules requires
escaping. i.e.: "\#"

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 below, default values are listed in parentheses.

USER PREFERENCES
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.

SCORING OPTIONS

required_score n.nn (default: 5)
Set the score 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. This option was
previously known as "required_hits" and that name is still accepted,
but is deprecated.

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 (score set 0). The second score is used
when Bayes is disabled, but network tests are enabled (score set 1).
The third score is used when Bayes is enabled and network tests are
disabled (score set 2). The fourth score is used when Bayes is enabled
and network tests are enabled (score set 3).

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

If any of the score values are surrounded by parenthesis '()', then all
of the scores in the line are considered to be relative to the already
set score. ie: '(3)' means increase the score for this rule by 3
points in all score sets. '(3) (0) (3) (0)' means increase the score
for this rule by 3 in score sets 0 and 2 only.

If no score is given for a test by the end of the configuration, a
default score is assigned: a score of 1.0 is used for all tests, except
those who names begin with 'T_' (this is used to indicate a rule in
testing) which receive 0.01.

Note that test names which begin with '__' are indirect rules used to
compose meta-match rules and can also act as prerequisites to other
rules. They are not scored or listed in the 'tests hit' reports, but
assigning a score of 0 to an indirect rule will disable it from
running.

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. If you want to whitelist your own domain, be
aware that spammers will often impersonate the domain of the recipient.
The recommended solution is to instead use "whitelist_from_rcvd" as
explained below.

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

In addition, the "envelope sender" data, taken from the SMTP envelope
data where this is available, is looked up.

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 internet to your internal 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 "internal_networks" be correct. For
simple cases, it will be, but for a complex network, or 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.

whitelist_allows_relays add@ress.com
Specify addresses which are in "whitelist_from_rcvd" that sometimes
send through a mail relay other than the listed ones. By default mail
with a From address that is in "whitelist_from_rcvd" that does not
match the relay will trigger a forgery rule. Including the address in
"whitelist_allows_relay" prevents that.

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

The specified email address does not have to match exactly the address
previously used in a whitelist_from_rcvd line as it is compared to the
address in the header.

e.g.

whitelist_allows_relays joe@example.com fred@example.com
whitelist_allows_relays *@example.com

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.

The headers checked for whitelist addresses are as follows: if
"Resent-To" or "Resent-Cc" are set, use those; otherwise check all
addresses taken from the following set of headers:

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

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".

BASIC MESSAGE TAGGING OPTIONS

rewrite_header { subject | from | to } STRING
By default, suspected spam messages will not have the "Subject", "From"
or "To" lines tagged to indicate spam. By setting this option, the
header will be tagged with "STRING" to indicate that a message is spam.
For the From or To headers, this will take the form of an RFC 2822
comment following the address in parantheses. For the Subject header,
this will be prepended to the original subject. Note that you should
only use the _REQD_ and _SCORE_ tags when rewriting the Subject header
unless "report_safe" is 0. Otherwise, you may not be able to remove the
SpamAssassin markup via the normal methods.

Parentheses are not permitted in STRING if rewriting the From or To
headers. (They will be converted to square brackets.)

If "rewrite_header subject" is used, but the message being rewritten
does not already contain a "Subject" header, one will be created.

A null value for "STRING" will remove any existing rewrite for the
specified header.

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). header_name is restricted to the character set
[A-Za-z0-9_-].

"string" can contain tags as explained below in the TEMPLATE 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.

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, note that Checker-
Version can not be changed or removed):

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
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.

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.

See report_safe_copy_headers if you want to copy headers from the
original mail into tagged messages.

LANGUAGE 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 (both Traditional and Simplified)
zh.big5 - Chinese (Traditional only)
zh.gb2312 - Chinese (Simplified only)

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 (Distributed Checksum
Clearinghouse) is a system similar to Razor.

dcc_timeout n (default: 10)
How many seconds you wait for DCC to complete, before scanning
continues without the DCC results.

dcc_body_max NUMBER
dcc_fuz1_max NUMBER
dcc_fuz2_max NUMBER
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 scanning
continues without the Pyzor 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 [option ...]
Additional options for the pyzor(1) command line. Note that for
security, only characters in the ranges A-Z, a-z, 0-9, -, _ and / are
permitted.

spamcop_from_address add@ress.com (default: none)
This address is used during manual reports to SpamCop as the From:
address. You can use your normal email address. If this is not set, a
guess will be used as the From: address in SpamCop reports.

spamcop_to_address add@ress.com (default: generic reporting address)
Your customized SpamCop report submission address. You need to obtain
this address by registering at "http://www.spamcop.net/". If this is
not set, SpamCop reports will go to a generic reporting address for
SpamAssassin users and your reports will probably have less weight in
the SpamCop system.

spamcop_max_report_size (default: 50)
The size (in kilobytes) at which SpamAssassin will truncate messages
reported to SpamCop. The default is the maximum size SpamCop will
accept at the time of release.

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. A
trusted host could conceivably relay spam, but will not originate it,
and will not forge header data. DNS blacklist checks will never query
for hosts on these networks.

MXes for your domain(s) and internal relays should also be specified
using the "internal_networks" setting. When there are 'trusted' hosts
that are not MXes or internal relays for your domain(s) they should
only be specified in "trusted_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 "trusted_networks" is not set and "internal_networks" is, the value
of "internal_networks" will be used for this parameter.

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 private network range,
then it's trusted

* if any addresses of the 'by' host is in a private network range,
then it's trusted

clear_trusted_networks
Empty the list of trusted networks.

internal_networks ip.add.re.ss[/mask] ... (default: none)
What networks or hosts are 'internal' in your setup. Internal means
that relay hosts on these networks are considered to be MXes for your
domain(s), or internal relays. This uses the same format as
"trusted_networks", above.

This value is used when checking 'dial-up' or dynamic IP address
blocklists, in order to detect direct-to-MX spamming. Trusted relays
that accept mail directly from dial-up connections should not be listed
in "internal_networks". List them only in "trusted_networks".

If "trusted_networks" is set and "internal_networks" is not, the value
of "trusted_networks" will be used for this parameter.

If neither "trusted_networks" or "internal_networks" is set, no
addresses will be considered local; in other words, any relays past the
machine where SpamAssassin is running will be considered external.

clear_internal_networks
Empty the list of internal 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

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 DNS 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 DNS query. If most of the DNS 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.

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 or 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: domain1.tld domain2.tld domain3.tld

Please note, the DNS test queries for NS records.

SpamAssassin's network rules are run in parallel. This can cause
overhead in terms of the number of file descriptors required; it is
recommended that the minimum limit on file descriptors be raised to at
least 256 for safety.

LEARNING OPTIONS

use_bayes ( 0 | 1 ) (default: 1)
Whether to use the naive-Bayesian-style classifier built into
SpamAssassin. This is a master on/off switch for all Bayes-related
operations.

use_bayes_rules ( 0 | 1 ) (default: 1)
Whether to use rules using the naive-Bayesian-style classifier built
into SpamAssassin. This allows you to disable the rules while leaving
auto and manual learning enabled.

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.

auto_whitelist_db_modules Module ... (default: see below)
What database modules should be used for the auto-whitelist storage
database file. The first named module that can be loaded from the
perl include path will be used. The format is:

PreferredModuleName SecondBest ThirdBest ...

ie. a space-separated list of perl module names. The default is:

DB_File GDBM_File NDBM_File SDBM_File

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:

- rules with tflags set to 'learn' (the Bayesian rules)

- rules with tflags set to 'userconf' (user white/black-listing rules, etc)

- rules with tflags set to 'noautolearn'

Also note that auto-training occurs using scores from either scoreset 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_ignore_from add@ress.com
Bayesian classification and autolearning will not be performed on mail
from the listed addresses. Program "sa-learn" will also ignore the
listed addresses if it is invoked using the "--use-ignores" option.
One or more addresses can be listed, see "whitelist_from".

Spam messages from certain senders may contain many words that
frequently occur in ham. For example, one might read messages from a
preferred bookstore but also get unwanted spam messages from other
bookstores. If the unwanted messages are learned as spam then any
messages discussing books, including the preferred bookstore and
antiquarian messages would be in danger of being marked as spam. The
addresses of the annoying bookstores would be listed. (Assuming they
were halfway legitimate and didn't send you mail through myriad
affiliates.)

Those who have pieces of spam in legitimate messages or otherwise
receive ham messages containing potentially spammy words might fear
that some spam messages might be in danger of being marked as ham. The
addresses of the spam mailing lists, correspondents, etc. would be
listed.

bayes_ignore_to add@ress.com
Bayesian classification and autolearning will not be performed on mail
to the listed addresses. See "bayes_ignore_from" for details.

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.

bayes_sql_override_username
Used by BayesStore::SQL storage implementation.

If this options is set the BayesStore::SQL module will override the set
username with the value given. This could be useful for implementing
global or group bayes databases.

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 once a day, but will sync more often if the journal file
size goes above this setting, in bytes. If set to 0, opportunistic
syncing will not occur.

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.

MISCELLANEOUS OPTIONS

lock_method type
Select the file-locking method used to protect database files on-disk.
By default, SpamAssassin uses an NFS-safe locking method on UNIX;
however, if you are sure that the database files you'll be using for
Bayes and AWL storage will never be accessed over NFS, a non-NFS-safe
locking system can be selected.

This will be quite a bit faster, but may risk file corruption if the
files are ever accessed by multiple clients at once, and one or more of
them is accessing them through an NFS filesystem.

Note that different platforms require different locking systems.

The supported locking systems for "type" are as follows:

nfssafe - an NFS-safe locking system
flock - simple UNIX "flock()" locking
win32 - Win32 locking using "sysopen (..., O_CREAT|O_EXCL)".

nfssafe and flock are only available on UNIX, and win32 is only
available on Windows. By default, SpamAssassin will choose either
nfssafe or win32 depending on the platform in use.

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 tabulator prepended
to mark it as a continuation of the preceding one.

The automatic wrapping can be disabled here. Note that this can
generate very long lines.

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.

envelope_sender_header Name-Of-Header
SpamAssassin will attempt to discover the address used in the 'MAIL
FROM:' phase of the SMTP transaction that delivered this message, if
this data has been made available by the SMTP server. This is used in
the "EnvelopeFrom" pseudo-header, and for various rules such as SPF
checking.

By default, various MTAs will use different headers, such as the
following:

X-Envelope-From
Envelope-Sender
X-Sender
Return-Path

SpamAssassin will attempt to use these, if some heuristics (such as the
header placement in the message, or the absence of fetchmail
signatures) appear to indicate that they are safe to use. However, it
may choose the wrong headers in some mailserver configurations. (More
discussion of this can be found in bug 2142 in the SpamAssassin
BugZilla.)

To avoid this heuristic failure, the "envelope_sender_header" setting
may be helpful. Name the header that your MTA adds to messages
containing the address used at the MAIL FROM step of the SMTP
transaction.

If the header in question contains "<" or ">" characters at the start
and end of the email address in the right-hand side, as in the SMTP
transaction, these will be stripped.

If the header is not found in a message, or if it's value does not
contain an "@" sign, SpamAssassin will fall back to its default
heuristics.

(Note for MTA developers: we would prefer if the use of a single header
be avoided in future, since that precludes 'downstream' spam scanning.
"http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived" details
a better proposal using the Received headers.)

example:

envelope_sender_header X-SA-Exim-Mail-From

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.

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.

report_hostname ...hostname to use...
Set what _HOSTNAME_ is replaced with in the above report text. By
default, this is determined dynamically as whatever the host running
SpamAssassin calls itself.

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.

RULE DEFINITIONS AND 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.

Appending ":raw" to the header name will inhibit decoding of quoted-
printable or base-64 encoded strings.

Appending ":addr" to the header name will cause everything except the
first email address to be removed from the header. For example, all of
the following will result in "example@foo":

example@foo
example@foo (Foo Blah)
example@foo, example@bar
display: example@foo (Foo Blah), example@bar ;
Foo Blah <example@foo>
"Foo Blah" <example@foo>
"'Foo Blah'" <example@foo>

Appending ":name" to the header name will cause everything except the
first real name to be removed from the header. For example, all of the
following will result in "Foo Blah"

example@foo (Foo Blah)
example@foo (Foo Blah), example@bar
display: example@foo (Foo Blah), example@bar ;
Foo Blah <example@foo>
"Foo Blah" <example@foo>
"'Foo Blah'" <example@foo>

There are several special pseudo-headers that can be specified:

"ALL" can be used to mean the text of all the message's headers.
headers.
"ToCc" can be used to mean the contents of both the 'To' and 'Cc'
transaction that delivered this message, if this data has been made
available by the SMTP server.
"EnvelopeFrom" is the address used in the 'MAIL FROM:' phase of the SMTP
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.
"MESSAGEID" is a symbol meaning all Message-Id's found in the message;

"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. Also note that the "#" character must be escaped ("\#") or
else it will be considered to be the start of a comment and not part of
the regexp.

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, and names have a length of no more than 22
characters, 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' [, 'sub-test'])
Check a DNSBL (a DNS blacklist or whitelist). This will retrieve
Received: headers from the message, extract the IP addresses, select
which ones are 'untrusted' based on the "trusted_networks" logic, and
query that DNSBL zone. There's a few things to note:

duplicated or private IPs
Duplicated IPs are only queried once and private IPs are not
queried. Private IPs are those listed in
<http://www.iana.org/assignments/ipv4-address-space>,
<http://duxcw.com/faq/network/privip.htm>,
<http://duxcw.com/faq/network/autoip.htm>, or
<ftp://ftp.rfc-editor.org/in-notes/rfc3330.txt> as private.

the 'set' argument
This is used as a 'zone ID'. If you want to look up a multiple-
meaning zone like NJABL or SORBS, you can then query the results
from that zone using it; but all check_rbl_sub() calls must use
that zone ID.

Also, if more than one IP address gets a DNSBL hit for a particular
rule, it does not affect the score because rules only trigger once
per message.

the 'zone' argument
This is the root zone of the DNSBL, ending in a period.

the 'sub-test' argument
This optional argument behaves the same as the sub-test argument in
"check_rbl_sub()" below.

selecting all IPs except for the originating one
This is accomplished by placing '-notfirsthop' at the end of the
set name. This is 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
(mail exchange).

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, place
'-firsttrusted' at the end of the set name. 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 placing
'-untrusted' at the end of the set name.

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, a
SenderBase test beginning with "sb:", or (if none of the preceding
options seem to fit) a regular expression.

Note: the set name must be exactly the same for as the main query rule,
including selections like '-notfirsthop' appearing at the end of the
set name.

body SYMBOLIC_TEST_NAME /pattern/modifiers
Define a body pattern test. "pattern" is a Perl regular expression.
Note: as per the header tests, "#" must be escaped ("\#") or else it is
considered the beginning of a comment.

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.
Note: as per the header tests, "#" must be escaped ("\#") or else it is
considered the beginning of a comment.

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. Note: as per the header tests, "#" must be escaped ("\#")
or else it is considered the beginning of a comment.

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

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 message pattern test. "pattern" is a Perl regular
expression. Note: as per the header tests, "#" must be escaped ("\#")
or else it is considered the beginning of a comment.

The full message is the pristine message headers plus the pristine
message body, including all MIME data such as images, other
attachments, MIME boundaries, etc.

full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
Define a full message 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 having
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|noautolearn} ]
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.
Please see "bayes_auto_learn" and "use_auto_whitelist" for more
information about tflag interaction with those systems. 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.

noautolearn
The test will explicitly be ignored when calculating the score for
learning systems.

priority SYMBOLIC_TEST_NAME n
Assign a specific priority to a test. All tests, except for DNS and
Meta tests, are run in priority order. The default test priority is 0
(zero).

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

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.

The version_tag will be lowercased, and any non-alphanumeric or period
character will be replaced by an underscore.

e.g.

version_tag myrules1 # version=2.41-myrules1

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".

use_auto_whitelist ( 0 | 1 ) (default: 1)
Whether to use auto-whitelists. Auto-whitelists track the long-term
average score for each sender and then shift the score of new messages
toward that long-term average. This can increase or decrease the score
for messages, depending on the long-term behavior of the particular
correspondent.

For more information about the auto-whitelist system, please look at
the the "Automatic Whitelist System" section of the README file. The
auto-whitelist is not intended as a general-purpose replacement for
static whitelist entries added to your config files.

Note that certain tests are ignored when determining the final message
score:

- rules with tflags set to 'noautolearn'

auto_whitelist_factory module (default: Mail::SpamAssassin::DBBasedAddrList)
Select alternative whitelist factory module.

~/.spamassassin/auto-whitelist)
auto_whitelist_path /path/to/file (default:
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.

bayes_store_module Name::Of::BayesStore::Module
If this option is set, the module given will be used as an alternate to
the default bayes storage mechanism. It must conform to the published
storage specification (see Mail::SpamAssassin::BayesStore).

bayes_sql_dsn DBI::databasetype:databasename:hostname:port
Used for BayesStore::SQL storage implementation.

This option give the connect string used to connect to the SQL based
Bayes storage.

bayes_sql_username
Used by BayesStore::SQL storage implementation.

This option gives the username used by the above DSN.

bayes_sql_password
Used by BayesStore::SQL storage implementation.

This option gives the password used by the above DSN.

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"

If you load user scores from an LDAP directory, this will set the DSN
used to connect. You have to write the DSN as an LDAP URL, the
components being the host and port to connect to, the base DN for the
seasrch, the scope of the search (base, one or sub), the single
attribute being the multivalued attribute used to hold the
configuration data (space separated pairs of key and value, just as in
a file) and finally the filter being the expression used to filter out
the wanted username. Note that the filter expression is being used in a
sprintf statement with the username as the only parameter, thus is can
hold a single __USERNAME__ expression. This will be replaced with the
username.

Example:
"ldap://localhost:389/dc=koehntopp,dc=de?spamassassinconfig?uid=__USERNAME__"

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_custom_query query
This option gives you the ability to create a custom SQL query to
retrieve user scores and preferences. In order to work correctly your
query should return two values, the preference name and value, in that
order. In addition, there are several "variables" that you can use as
part of your query, these variables will be substituted for the current
values right before the query is run. The current allowed variables
are:

_TABLE_
The name of the table where user scores and preferences are stored.
Currently hardcoded to userpref, to change this value you need to
create a new custom query with the new table name.

_USERNAME_
The current user's username.

_MAILBOX_
The portion before the @ as derived from the current user's
username.

_DOMAIN_
The portion after the @ as derived from the current user's
username, this value may be null.

The query must be one one continuous line in order to parse correctly.

Here are several example queries, please note that these are broken up
for easy reading, in your config it should be one continuous line.

Current default query:
"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' ORDER BY username ASC"

Use global and then domain level defaults:
"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' OR username = '@~'||_DOMAIN_ ORDER BY
username ASC"

Maybe global prefs should override user prefs:
"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' ORDER BY username DESC"

user_awl_dsn DBI:databasetype:databasename:hostname:port
If you load user auto-whitelists from an SQL database, this will set
the DSN used to connect. Example: "DBI:mysql:spamassassin:localhost"

user_awl_sql_username username
The authorized username to connect to the above DSN.

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

user_awl_sql_table tablename
The table user auto-whitelists are stored in, for the above DSN.

user_scores_ldap_username
This is the Bind DN used to connect to the LDAP server.

Example: "cn=master,dc=koehntopp,dc=de"

user_scores_ldap_password
This is the password used to connect to the LDAP server.

loadplugin PluginModuleName [/path/to/module.pm]
Load a SpamAssassin plugin module. The "PluginModuleName" is the perl
module name, used to create the plugin object itself.

"/path/to/module.pm" is the file to load, containing the module's perl
code; if it's specified as a relative path, it's considered to be
relative to the current configuration file. If it is omitted, the
module will be loaded using perl's search path (the @INC array).

See "Mail::SpamAssassin::Plugin" for more details on writing plugins.

PREPROCESSING OPTIONS
include filename
Include configuration lines from "filename". Relative paths are
considered relative to the current configuration file or user
preferences file.

if (conditional perl expression)
Used to support conditional interpretation of the configuration file.
Lines between this and a corresponding "endif" line, will be ignored
unless the conditional expression evaluates as true (in the perl sense;
that is, defined and non-0).

The conditional accepts a limited subset of perl for security -- just
enough to perform basic arithmetic comparisons. The following input is
accepted:

numbers, whitespace, arithmetic operations and grouping
Namely these characters and ranges:

( ) - + * / _ . , < = > ! ~ 0-9 whitespace

version
This will be replaced with the version number of the currently-
running SpamAssassin engine. Note: The version used is in the
internal SpamAssassin version format which is "x.yyyzzz", where x
is major version, y is minor version, and z is maintenance version.
So 3.0.0 is 3.000000, and 3.4.80 is 3.004080.

plugin(Name::Of::Plugin)
This is a function call that returns 1 if the plugin named
"Name::Of::Plugin" is loaded, or "undef" otherwise.

If the end of a configuration file is reached while still inside a "if"
scope, a warning will be issued, but parsing will restart on the next
file.

For example:

if (version > 3.000000)
header MY_FOO ...
endif

loadplugin MyPlugin plugintest.pm

if plugin (MyPlugin)
header MY_PLUGIN_FOO eval:check_for_foo()
score MY_PLUGIN_FOO 0.1
endif

ifplugin PluginModuleName
An alias for "if plugin(PluginModuleName)".

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

Note: The version used is in the internal SpamAssassin version format
which is "x.yyyzzz", where x is major version, y is minor version, and
z is maintenance version. So 3.0.0 is 3.000000, and 3.4.80 is
3.004080.

TEMPLATE TAGS
The following "tags" can be used as placeholders in certain options. 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
_SCORE(PAD)_ message score, if PAD is included and is either spaces or
zeroes, then pad scores with that many spaces or zeroes
(default, none) ie: _SCORE(0)_ makes 2.4 become 02.4,
_SCORE(00)_ is 002.4. 12.3 would be 12.3 and 012.3
respectively.
_REQD_ message threshold
_VERSION_ version (eg. 3.0.0 or 3.1.0-r26142-foo1)
_SUBVERSION_ sub-version/code revision date (eg. 2004-01-10)
_HOSTNAME_ hostname of the machine the mail was processed on
_REMOTEHOSTNAME_ hostname of the machine the mail was sent from, only
available with spamd
_REMOTEHOSTADDR_ ip address of the machine the mail was sent from, only
available with spamd
_BAYES_ bayes score
_TOKENSUMMARY_ number of new, neutral, spammy, and hammy tokens found
_BAYESTC_ number of new tokens found
_BAYESTCLEARNED_ number of seen tokens found
_BAYESTCSPAMMY_ number of spammy tokens found
_BAYESTCHAMMY_ number of hammy tokens found
_HAMMYTOKENS(N)_ the N most significant hammy tokens (default, 5)
_SPAMMYTOKENS(N)_ the N most significant spammy tokens (default, 5)
_AWL_ AWL modifier
_DATE_ rfc-2822 date of scan
_STARS(*)_ one * (use any character) for each score point (note: this
is limited to 50 'stars' to stay on the right side of the RFCs)
_RELAYSTRUSTED_ relays used and deemed to be trusted
_RELAYSUNTRUSTED_ relays used that can not be trusted
_AUTOLEARN_ autolearn status ("ham", "no", "spam", "disabled",
"failed", "unavailable")
_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 hit (for header reports)
_SUMMARY_ summary of tests hit for standard report (for body reports)
_CONTACTADDRESS_ contents of the 'report_contact' setting

The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second argument
which specifies a format. See the HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT
section, below, for details.

HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT

The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second argument
which specifies a format: "_SPAMMYTOKENS(N,FMT)_", "_HAMMYTOKENS(N,FMT)_"
The following formats are available:

short
Only the tokens themselves are listed. For example, preference file
entry:

"add_header all Spammy _SPAMMYTOKENS(2,short)_"

Results in message header:

"X-Spam-Spammy: remove.php, UD:jpg"

Indicating that the top two spammy tokens found are "remove.php" and
"UD:jpg". (The token itself follows the last colon, the text before
the colon indicates something about the token. "UD" means the token
looks like it might be part of a domain name.)

compact
The token probability, an abbreviated declassification distance (see
example), and the token are listed. For example, preference file
entry:

"add_header all Spammy _SPAMMYTOKENS(2,compact)_"

Results in message header:

"0.989-6--remove.php, 0.988-+--UD:jpg"

Indicating that the probabilities of the top two tokens are 0.989 and
0.988, respectively. The first token has a declassification distance
of 6, meaning that if the token had appeared in at least 6 more ham
messages it would not be considered spammy. The "+" for the second
token indicates a declassification distance greater than 9.

long
Probability, declassification distance, number of times seen in a ham
message, number of times seen in a spam message, age and the token are
listed.

For example, preference file entry:

"add_header all Spammy _SPAMMYTOKENS(2,long)_"

Results in message header:

"X-Spam-Spammy: 0.989-6--0h-4s--4d--remove.php,
0.988-33--2h-25s--1d--UD:jpg"

In addition to the information provided by the compact option, the long
option shows that the first token appeared in zero ham messages and
four spam messages, and that it was last seen four days ago. The
second token appeared in two ham messages, 25 spam messages and was
last seen one day ago. (Unlike the "compact" option, the long option
shows declassification distances that are greater than 9.)

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.

SEE ALSO
"Mail::SpamAssassin" "spamassassin" "spamd"

Index for
Section 3

Alphabetical
listing for M

Top of
page

Mail::SpamAssassin::CoUnsfe(r3)Contributed

NAME

SYNOPSIS

DESCRIPTION

USER PREFERENCES

RULE DEFINITIONS AND PRIVILEGED SETTINGS

ADMINISTRATOR SETTINGS

~/.spamassassin/auto-whitelist)

PREPROCESSING OPTIONS

TEMPLATE TAGS

LOCALI[SZ]ATION

SEE ALSO

Mail::SpamAssassin::CoUnsfe(r3)Contributed