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
lang pt_BR report O programa detetor de Spam ZOE [...]
DESCRIPTION¶
SpamAssassin is configured using traditional UNIX-style configuration files,
loaded from the "/usr/share/spamassassin" and
"/etc/spamassassin" directories.
The following web page lists the most important configuration settings used to
configure SpamAssassin; novices are encouraged to read it first:
http://wiki.apache.org/spamassassin/ImportantInitialConfigItems
The "#" character starts a comment, which continues until end of line.
NOTE: if the "#" character is to be used as part of a rule or
configuration option, it must be escaped with a backslash. 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.
File and directory paths can use "~" to refer to the user's home
directory, but no other shell-style path extensions such as globing or
"~user/" are supported.
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
whose 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 user@example.com
- Used to whitelist sender addresses which send mail that is
often tagged (incorrectly) as spam.
Use of this setting is not recommended, since it blindly trusts the message,
which is routinely and easily forged by spammers and phish senders. The
recommended solution is to instead use "whitelist_auth" or other
authenticated whitelisting methods, or "whitelist_from_rcvd".
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. Matching is
case-insensitive.
Multiple addresses per line, separated by spaces, is OK. Multiple
"whitelist_from" lines are 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. See
"envelope_sender_header".
e.g.
whitelist_from joe@example.com fred@example.com
whitelist_from *@example.com
- unwhitelist_from user@example.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 (although case-insensitively) the address previously used in a
whitelist_from line, which implies that a wildcard only matches literally
the same wildcard (not 'any' address).
e.g.
unwhitelist_from joe@example.com fred@example.com
unwhitelist_from *@example.com
- whitelist_from_rcvd addr@lists.sourceforge.net
sourceforge.net
- Works similarly to whitelist_from, except that in addition
to matching a sender address, a relay's rDNS name or its IP address must
match too for the whitelisting rule to fire. The first parameter is a
sender's e-mail address to whitelist, and the second is a string to match
the relay's rDNS, or its IP address. Matching is case-insensitive.
This second parameter is matched against the TCP-info information field as
provided in a FROM clause of a trace information (i.e. the Received header
field, see RFC 5321). Only the Received header fields inserted by trusted
hosts are considered. This parameter can either be a full hostname, or the
domain component of that hostname, or an IP address in square brackets.
The reverse DNS lookup is done by a MTA, not by SpamAssassin.
In case of an IPv4 address in brackets, it may be truncated on classful
boundaries to cover whole subnets, e.g. "[10.1.2.3]",
"[10.1.2]", "[10.1]", "[10]". CIDR notation
is currently not supported, nor is IPv6. The matching on IP address is
mainly provided to cover rare cases where whitelisting of a sending MTA is
desired which does not have a correct reverse DNS configured.
In other words, if the host that connected to your MX had an IP address
192.0.2.123 that mapped to 'sendinghost.example.org', you should specify
"sendinghost.example.org", or "example.org", or
"[192.0.2.123]" or "[192.0.2]" here.
Note that this requires that "internal_networks" be correct. For
simple cases, it will be, but for a complex network you may get better
results by setting that parameter.
It also requires that your mail exchangers be configured to perform DNS
reverse lookups on the connecting host's IP address, and to record the
result in the generated Received header field according to RFC 5321.
e.g.
whitelist_from_rcvd joe@example.com example.com
whitelist_from_rcvd *@axkit.org sergeant.org
whitelist_from_rcvd *@axkit.org [192.0.2.123]
- 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 user@example.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.
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. Matching is
case-insensitive.
Multiple addresses per line, separated by spaces, is OK. Multiple
"whitelist_allows_relays" lines are 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 user@example.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 user@example.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 user@example.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. The specified email address has to match
exactly the address previously used in a blacklist_from line.
e.g.
unblacklist_from joe@example.com fred@example.com
unblacklist_from *@spammer.com
- whitelist_to user@example.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 user@example.com
- See above.
- all_spam_to user@example.com
- See above.
- blacklist_to user@example.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".
- whitelist_auth user@example.com
- Used to specify addresses which send mail that is often
tagged (incorrectly) as spam. This is different from
"whitelist_from" and "whitelist_from_rcvd" in that it
first verifies that the message was sent by an authorized sender for the
address, before whitelisting.
Authorization is performed using one of the installed sender-authorization
schemes: SPF (using "Mail::SpamAssassin::Plugin::SPF"), or DKIM
(using "Mail::SpamAssassin::Plugin::DKIM"). Note that those
plugins must be active, and working, for this to operate.
Using "whitelist_auth" is roughly equivalent to specifying
duplicate "whitelist_from_spf", "whitelist_from_dk",
and "whitelist_from_dkim" lines for each of the addresses
specified.
e.g.
whitelist_auth joe@example.com fred@example.com
whitelist_auth *@example.com
- def_whitelist_auth user@example.com
- Same as "whitelist_auth", 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_auth user@example.com
- Used to override a "whitelist_auth" entry. The
specified email address has to match exactly the address previously used
in a "whitelist_auth" line.
e.g.
unwhitelist_auth joe@example.com fred@example.com
unwhitelist_auth *@example.com
- enlist_uri_host (listname) host ...
- Adds one or more host names or domain names to a named list
of URI domains. The named list can then be consulted through a
check_uri_host_listed() eval rule implemented by the WLBLEval
plugin, which takes the list name as an argument. Parenthesis around a
list name are literal - a required syntax.
Host names may optionally be prefixed by an exclamantion mark '!', which
produces false as a result if this entry matches. This makes it easier to
exclude some subdomains when their superdomain is listed, for example:
enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com
No wildcards are supported, but subdomains do match implicitly. Lists are
independent. Search for each named list starts by looking up the full
hostname first, then leading fields are progressively stripped off (e.g.:
sub.example.com, example.com, com) until a match is found or we run out of
fields. The first matching entry (the most specific) determines if a
lookup yielded a true (no '!' prefix) or a false (with a '!' prefix)
result.
If an URL found in a message contains an IP address in place of a host name,
the given list must specify the exact same IP address (instead of a host
name) in order to match.
Use the delist_uri_host directive to neutralize previous enlist_uri_host
settings.
Enlisting to lists named 'BLACK' and 'WHITE' have their shorthand directives
blacklist_uri_host and whitelist_uri_host and corresponding default rules,
but the names 'BLACK' and 'WHITE' are otherwise not special or
reserved.
- delist_uri_host [ (listname) ] host ...
- Removes one or more specified host names from a named list
of URI domains. Removing an unlisted name is ignored (is not an error).
Listname is optional, if specified then just the named list is affected,
otherwise hosts are removed from all URI host lists created so far.
Parenthesis around a list name are a required syntax.
Note that directives in configuration files are processed in sequence, the
delist_uri_host only applies to previously listed entries and has no
effect on enlisted entries in yet-to-be-processed directives.
For convenience (similarity to the enlist_uri_host directive) hostnames may
be prefixed by a an exclamation mark, which is stripped off from each name
and has no meaning here.
- blacklist_uri_host host-or-domain ...
- Is a shorthand for a directive: enlist_uri_host (BLACK)
host ...
Please see directives enlist_uri_host and delist_uri_host for details.
- whitelist_uri_host host-or-domain ...
- Is a shorthand for a directive: enlist_uri_host (BLACK)
host ...
Please see directives enlist_uri_host and delist_uri_host for details.
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 if "report_safe" is 0.
Otherwise, you may not be able to remove the SpamAssassin markup via the
normal methods. More information about tags is explained below in the
TEMPLATE TAGS section.
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_-].
The order of "add_header" configuration options is preserved,
inserted headers will follow this order of declarations. When combining
"add_header" with "clear_headers" and
"remove_header", keep in mind that "add_header"
appends a new header to the current list, after first removing any
existing header fields of the same name. Note also that
"add_header", "clear_headers" and
"remove_header" may appear in multiple .cf files, which are
interpreted in alphabetic order.
"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" and "remove_header" 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.
"add_header", "clear_headers" and
"remove_header" may appear in multiple .cf files, which are
interpreted in alphabetic order, so "clear_headers" in a later
file will remove all added headers from previously interpreted
configuration files, which may or may not be desired.
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 ( 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_locales xx [ yy zz ... ] (default: all)
- This option is used to specify which locales are considered
OK for incoming mail. Mail using the character sets that are
allowed by this option 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
- normalize_charset ( 0 | 1) (default: 0)
- Whether to detect character sets and normalize message
content to Unicode. Requires the Encode::Detect module, HTML::Parser
version 3.46 or later, and Perl 5.8.5 or later.
NETWORK TEST OPTIONS¶
- trusted_networks IPaddress[/masklen] ... (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.
See "http://wiki.apache.org/spamassassin/TrustPath" for more
information.
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".
The "IPaddress" can be an IPv4 address (in a dot-quad form), or an
IPv6 address optionally enclosed in square brackets. Scoped link-local
IPv6 addresses are syntactically recognized but the interface scope is
currently ignored (e.g. [fe80::1234%eth0] ) and should be avoided.
If a "/masklen" is specified, it is considered a CIDR-style
'netmask' length, specified in bits. If it is not specified, but less than
4 octets of an IPv4 address are specified with a trailing dot, an implied
netmask length covers all addresses in remaining octets (i.e. implied
masklen is /8 or /16 or /24). If masklen is not specified, and there is
not trailing dot, then just a single IP address specified is used, as if
the masklen were "/32" with an IPv4 address, or "/128"
in case of an IPv6 address.
If a network or host address is prefaced by a "!" the matching
network or host will be excluded from the list even if a less specific
(shorter netmask length) subnet is later specified in the list. This
allows a subset of a wider network to be exempt. In case of specifying
overlapping subnets, specify more specific subnets first (tighter
matching, i.e. with a longer netmask length), followed by less specific
(shorter netmask length) subnets to get predictable results regarless of
the search algorithm used - when Net::Patricia module is installed the
search finds the tightest matching entry in the list, while a sequential
search as used in absence of the module Net::Patricia will find the first
matching entry in the list.
Note: 127.0.0.0/8 and ::1 are always included in trusted_networks,
regardless of your config.
Examples:
trusted_networks 192.168.0.0/16 # all in 192.168.*.*
trusted_networks 192.168. # all in 192.168.*.*
trusted_networks 212.17.35.15 # just that host
trusted_networks !10.0.1.5 10.0.1/24 # all in 10.0.1.* but not 10.0.1.5
trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
# 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64
This operates additively, so a "trusted_networks" line after
another one will append new entries to the list of trusted networks. 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 neither "trusted_networks" or "internal_networks" is
set, a basic inference algorithm is applied. This works as follows:
- •
- If the 'from' host has an IP address in a private (RFC
1918) network range, then it's trusted
- •
- If there are authentication tokens in the received header,
and the previous host was trusted, then this host is also trusted
- •
- Otherwise this host, and all further hosts, are consider
untrusted.
- clear_trusted_networks
- Empty the list of trusted networks.
- internal_networks IPaddress[/masklen] ... (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 syntax
as "trusted_networks", above - see there for details.
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 (i.e. are
also performing a role of mail submission agents - MSA) 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" nor "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.
Every entry in "internal_networks" must appear in
"trusted_networks"; in other words,
"internal_networks" is always a subset of the trusted set.
Note: 127/8 and ::1 are always included in internal_networks, regardless of
your config.
- clear_internal_networks
- Empty the list of internal networks.
- msa_networks IPaddress[/masklen] ... (default: none)
- The networks or hosts which are acting as MSAs in your
setup (but not also as MX relays). This uses the same syntax as
"trusted_networks", above - see there for details.
MSA means that the relay hosts on these networks accept mail from
your own users and authenticates them appropriately. These relays will
never accept mail from hosts that aren't authenticated in some way.
Examples of authentication include, IP lists, SMTP AUTH, POP-before-SMTP,
etc.
All relays found in the message headers after the MSA relay will take on the
same trusted and internal classifications as the MSA relay itself, as
defined by your trusted_networks and internal_networks
configuration.
For example, if the MSA relay is trusted and internal so will all of the
relays that precede it.
When using msa_networks to identify an MSA it is recommended that you treat
that MSA as both trusted and internal. When an MSA is not included in
msa_networks you should treat the MSA as trusted but not internal, however
if the MSA is also acting as an MX or intermediate relay you must always
treat it as both trusted and internal and ensure that the MSA includes
visible auth tokens in its Received header to identify submission clients.
Warning: Never include an MSA that also acts as an MX (or is also an
intermediate relay for an MX) or otherwise accepts mail from
non-authenticated users in msa_networks. Doing so will result in unknown
external relays being trusted.
- clear_msa_networks
- Empty the list of msa networks.
- originating_ip_headers header ... (default: X-Yahoo-Post-IP
X-Originating-IP X-Apparently-From X-SenderIP)
- A list of header field names from which an originating IP
address can be obtained. For example, webmail servers may record a client
IP address in X-Originating-IP.
These IP addresses are virtually appended into the Received: chain, so they
are used in RBL checks where appropriate.
Currently the IP addresses are not added into X-Spam-Relays-* header fields,
but they may be in the future.
- clear_originating_ip_headers
- Empty the list of 'originating IP address' header field
names.
- always_trust_envelope_sender ( 0 | 1 ) (default: 0)
- Trust the envelope sender even if the message has been
passed through one or more trusted relays. See also
"envelope_sender_header".
- skip_rbl_checks ( 0 | 1 ) (default: 0)
- Turning on the skip_rbl_checks setting will disable the
DNSEval plugin, which implements Real-time Block List (or: Blackhole List)
(RBL) lookups.
By default, SpamAssassin will run RBL checks. Individual blocklists may be
disabled selectively by setting a score of a corresponding rule to 0.
See also a related configuration parameter skip_uribl_checks, which controls
the URIDNSBL plugin (documented in the URIDNSBL man page).
- dns_available { yes | no | test[: domain1 domain2...] }
(default: yes)
- Tells SpamAssassin whether DNS resolving is available or
not. A value yes indicates DNS resolving is available, a value
no indicates DNS resolving is not available - both of these values
apply unconditionally and skip initial DNS tests, which can be slow or
unreliable.
When the option value is a test (with or without arguments),
SpamAssassin will query some domain names on the internet during
initialization, attempting to determine if DNS resolving is working or
not. A space-separated list of domain names may be specified explicitly,
or left to a built-in default of a dozen or so domain names. From an
explicit or a default list a subset of three domain names is picked
randomly for checking. The test queries for NS records of these domain: if
at least one query returns a success then SpamAssassin considers DNS
resolving as available, otherwise not.
The problem is that the test can introduce some startup delay if a network
connection is down, and in some cases it can wrongly guess that DNS is
unavailable because a test connection failed, what causes disabling
several DNS-dependent tests.
Please note, the DNS test queries for NS records, so specify domain names,
not host names.
Since version 3.4.0 of SpamAssassin a default setting for option
dns_available is yes. A default in older versions was
test.
- dns_server ip-addr-port (default: entries provided by
Net::DNS)
- Specifies an IP address of a DNS server, and optionally its
port number. The dns_server directive may be specified multiple
times, each entry adding to a list of available resolving name servers.
The ip-addr-port argument can either be an IPv4 or IPv6 address,
optionally enclosed in brackets, and optionally followed by a colon and a
port number. In absence of a port number a standard port number 53 is
assumed. When an IPv6 address is specified along with a port number, the
address must be enclosed in brackets to avoid parsing ambiguity
regarding a colon separator,
Examples :
dns_server 127.0.0.1
dns_server 127.0.0.1:53
dns_server [127.0.0.1]:53
dns_server [::1]:53
In absence of dns_server directives, the list of name servers is
provided by Net::DNS module, which typically obtains the list from
/etc/resolv.conf, but this may be platform dependent. Please consult the
Net::DNS::Resolver documentation for details.
- clear_dns_servers
- Empty the list of explicitly configured DNS servers through
a dns_server directive, falling back to Net::DNS -supplied
defaults.
- dns_local_ports_permit ranges...
- Add the specified ports or ports ranges to the set of
allowed port numbers that can be used as local port numbers when sending
DNS queries to a resolver.
The argument is a whitespace-separated or a comma-separated list of single
port numbers n, or port number pairs (i.e. m-n) delimited by a '-',
representing a range. Allowed port numbers are between 1 and 65535.
Directives dns_local_ports_permit and dns_local_ports_avoid
are processed in order in which they appear in configuration files. Each
directive adds (or subtracts) its subsets of ports to a current set of
available ports. Whatever is left in the set by the end of configuration
processing is made available to a DNS resolving client code.
If the resulting set of port numbers is empty (see also the directive
dns_local_ports_none), then SpamAssassin does not apply its ports
randomization logic, but instead leaves the operating system to choose a
suitable free local port number.
The initial set consists of all port numbers in the range 1024-65535. Note
that system config files already modify the set and remove all the IANA
registered port numbers and some other ranges, so there is rarely a need
to adjust the ranges by site-specific directives.
See also directives dns_local_ports_permit and
dns_local_ports_none.
- dns_local_ports_avoid ranges...
- Remove specified ports or ports ranges from the set of
allowed port numbers that can be used as local port numbers when sending
DNS queries to a resolver.
Please see directive dns_local_ports_permit for details.
- dns_local_ports_none
- Is a fast shorthand for:
dns_local_ports_avoid 1-65535
leaving the set of available DNS query local port numbers empty. In all
respects (apart from speed) it is equivalent to the shown directive, and
can be freely mixed with dns_local_ports_permit and
dns_local_ports_avoid.
If the resulting set of port numbers is empty, then SpamAssassin does not
apply its ports randomization logic, but instead leaves the operating
system to choose a suitable free local port number.
See also directives dns_local_ports_permit and
dns_local_ports_avoid.
- dns_test_interval n (default: 600 seconds)
- If dns_available is set to test, the
dns_test_interval time in number of seconds will tell SpamAssassin how
often to retest for working DNS. A numeric value is optionally suffixed by
a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours,
days, weeks).
- dns_options opts (default: norotate, nodns0x20,
edns=4096)
- Provides a (whitespace or comma -separated) list of options
applying to DNS resolving. Available options are: rotate,
dns0x20 and edns (or edns0). Option name may be
negated by prepending a no (e.g. norotate, NoEDNS) to
counteract a previously enabled option. Option names are not
case-sensitive. The dns_options directive may appear in
configuration files multiple times, the last setting prevails.
Option edns (or edsn0) may take a value which specifies a
requestor's acceptable UDP payload size according to EDNS0 specifications
(RFC 6891, ex RFC 2671) e.g. edns=4096. When EDNS0 is off
(noedns or edns=512) a traditional implied UDP payload size
is 512 bytes, which is also a minimum allowed value for this option. When
the option is specified but a value is not provided, a conservative
default of 1220 bytes is implied. It is recommended to keep edns
enabled when using a local recursive DNS server which supports EDNS0 (like
most modern DNS servers do), a suitable setting in this case is
edns=4096, which is also a default. Allowing UDP payload size
larger than 512 bytes can avoid truncation of resource records in large
DNS responses (like in TXT records of some SPF and DKIM responses, or when
an unreasonable number of A records is published by some domain). The
option should be disabled when a recursive DNS server is only reachable
through non- RFC 6891 compliant middleboxes (such as some old-fashioned
firewall) which bans DNS UDP payload sizes larger than 512 bytes. A
suitable value when a non-local recursive DNS server is used and a
middlebox does allow EDNS0 but blocks fragmented IP packets is
perhaps 1220 bytes, allowing a DNS UDP packet to fit within a single IP
packet in most cases (a slightly less conservative range would be
1280-1410 bytes).
Option rotate causes SpamAssassin to choose a DNS server at random
from all servers listed in "/etc/resolv.conf" every
dns_test_interval seconds, effectively spreading the load over all
currently available DNS servers when there are many spamd workers.
Option dns0x20 enables randomization of letters in a DNS query label
according to draft-vixie-dnsext-dns0x20, decreasing a chance of collisions
of responses (by chance or by a malicious intent) by increasing spread as
provided by a 16-bit query ID and up to 16 bits of a port number, with
additional bits as encoded by flipping case (upper/lower) of letters in a
query. The number of additional random bits corresponds to the number of
letters in a query label. Should work reliably with all mainstream DNS
servers - do not turn on if you see frequent info messages "dns: no
callback for id:" in the log, or if RBL or URIDNS lookups do not work
for no apparent reason.
- dns_query_restriction (allow|deny) domain1 domain2 ...
- Option allows disabling of rules which would result in a
DNS query to one of the listed domains. The first argument must be a
literal "allow" or "deny", remaining arguments are
domains names.
Most DNS queries (with some exceptions) are subject to
dns_query_restriction. A domain to be queried is successively stripped-off
of its leading labels (thus yielding a series of its parent domains), and
on each iteration a check is made against an associative array generated
by dns_query_restriction options. Search stops at the first match (i.e.
the tightest match), and the matching entry with its "allow" or
"deny" value then controls whether a DNS query is allowed to be
launched.
If no match is found an implicit default is to allow a query. The purpose of
an explicit "allow" entry is to be able to override a previously
configured "deny" on the same domain or to override an entry
(possibly yet to be configured in subsequent config directives) on one of
its parent domains. Thus an 'allow zen.spamhaus.org' with a 'deny
spamhaus.org' would permit DNS queries on a specific DNS BL zone but deny
queries to other zones under the same parent domain.
Domains are matched case-insensitively, no wildcards are recognized, there
should be no leading or trailing dot.
Specifying a block on querying a domain name has a similar effect as setting
a score of corresponding DNSBL and URIBL rules to zero, and can be a handy
alternative to hunting for such rules when a site policy does not allow
certain DNS block lists to be queried.
Example:
dns_query_restriction deny dnswl.org surbl.org
dns_query_restriction allow zen.spamhaus.org
dns_query_restriction deny spamhaus.org mailspike.net spamcop.net
- clear_dns_query_restriction
- The option removes any entries entered by previous
'dns_query_restriction' options, leaving the list empty, i.e. allowing DNS
queries for any domain (including any DNS BL zone).
LEARNING OPTIONS¶
- use_learner ( 0 | 1 ) (default: 1)
- Whether to use any machine-learning classifiers with
SpamAssassin, such as the default 'BAYES_*' rules. Setting this to 0 will
disable use of any and all human-trained classifiers.
- 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.
- 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.
See the documentation for the
"Mail::SpamAssassin::Plugin::AutoLearnThreshold" plugin module
for details on how Bayes auto-learning is implemented by default.
- 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 user@example.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 user@example.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.
- 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. If a
bayes datastore backend does not implement individual key/value
expirations, the setting is silently ignored.
- bayes_token_ttl (default: 3w, i.e. 3 weeks)
- Time-to-live / expiration time in seconds for tokens kept
in a Bayes database. A numeric value is optionally suffixed by a time unit
(s, m, h, d, w, indicating seconds (default), minutes, hours, days,
weeks).
If bayes_auto_expire is true and a Bayes datastore backend supports it
(currently only Redis), this setting controls deletion of expired tokens
from a bayes database. The value is observed on a best-effort basis, exact
timing promises are not necessarily kept. If a bayes datastore backend
does not implement individual key/value expirations, the setting is
silently ignored.
- bayes_seen_ttl (default: 8d, i.e. 8 days)
- Time-to-live / expiration time in seconds for 'seen'
entries (i.e. mail message digests with their status) kept in a Bayes
database. A numeric value is optionally suffixed by a time unit (s, m, h,
d, w, indicating seconds (default), minutes, hours, days, weeks).
If bayes_auto_expire is true and a Bayes datastore backend supports it
(currently only Redis), this setting controls deletion of expired 'seen'
entries from a bayes database. The value is observed on a best-effort
basis, exact timing promises are not necessarily kept. If a bayes
datastore backend does not implement individual key/value expirations, the
setting is silently ignored.
- 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¶
- time_limit n (default: 300)
- Specifies a limit on elapsed time in seconds that
SpamAssassin is allowed to spend before providing a result. The value may
be fractional and must not be negative, zero is interpreted as unlimited.
The default is 300 seconds for consistency with the spamd default setting
of --timeout-child .
This is a best-effort advisory setting, processing will not be abruptly
aborted at an arbitrary point in processing when the time limit is
exceeded, but only on reaching one of locations in the program flow
equipped with a time test. Currently equipped with the test are the main
checking loop, asynchronous DNS lookups, plugins which are calling
external programs. Rule evaluation is guarded by starting a timer (alarm)
on each set of compiled rules.
When a message is passed to Mail::SpamAssassin::parse, a deadline time is
established as a sum of current time and the "time_limit"
setting.
This deadline may also be specified by a caller through an option
'master_deadline' in $suppl_attrib on a call to parse(), possibly
providing a more accurate deadline taking into account past and expected
future processing of a message in a mail filtering setup. If both the
config option as well as a 'master_deadline' option in a call are
provided, the shorter time limit of the two is used (since version 3.3.2).
Note that spamd (and possibly third-party callers of SpamAssassin) will
supply the 'master_deadline' option in a call based on its --timeout-child
option (or equivalent), unlike the command line "spamassassin",
which has no such command line option.
When a time limit is exceeded, most of the remaining tests will be skipped,
as well as auto-learning. Whatever tests fired so far will determine the
final score. The behaviour is similar to short-circuiting with attribute
'on', as implemented by a Shortcircuit plugin. A synthetic hit on a rule
named TIME_LIMIT_EXCEEDED with a near-zero default score is generated, so
that the report will reflect the event. A score for TIME_LIMIT_EXCEEDED
may be provided explicitly in a configuration file, for example to achieve
whitelisting or blacklisting effect for messages with long processing
times.
The "time_limit" option is a useful protection against excessive
processing time on certain degenerate or unusually long or complex mail
messages, as well as against some DoS attacks. It is also needed in
time-critical pre-queue filtering setups (e.g. milter, proxy, integration
with MTA), where message processing must finish before a SMTP client times
out. RFC 5321 prescribes in section 4.5.3.2.6 the 'DATA Termination' time
limit of 10 minutes, although it is not unusual to see some SMTP clients
abort sooner on waiting for a response. A sensible "time_limit"
for a pre-queue filtering setup is maybe 50 seconds, assuming that clients
are willing to wait at least a minute.
- 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 continuation 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. RFC 2822 required that header lines do not exceed 998
characters (not counting the final CRLF).
- 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 and bug 4747 in the SpamAssassin BugZilla.)
To avoid this heuristic failure, the "envelope_sender_header"
setting may be helpful. Name the header that your MTA or MDA 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 issue a warning in the logs and
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, storing the envelope sender at each hop in the
"Received" header.)
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_default_prefs.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_default_prefs.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.
- mbox_format_from_regex
- Set a specific regular expression to be used for mbox file
From separators.
For example, this setting will allow sa-learn to process emails stored in a
kmail 2 mbox:
mbox_format_from_regex /^From \S+ ?[[:upper:]][[:lower:]]{2}(?:, \d\d
[[:upper:]][[:lower:]]{2} \d{4} [0-2]\d:\d\d:\d\d [+-]\d{4}|
[[:upper:]][[:lower:]]{2} [ 1-3]\d [ 0-2]\d:\d\d:\d\d \d{4})/
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/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".
- redirector_pattern /pattern/modifiers
- A regex pattern that matches both the redirector site
portion, and the target site portion of a URI.
Note: The target URI portion must be surrounded in parentheses and
no other part of the pattern may create a backreference.
Example: http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude
redirector_pattern /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i
- 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 field, such as 'Subject', 'To', 'From', etc. Header field
names are matched case-insensitively (conforming to RFC 5322 section
1.2.2), except for all-capitals metaheader fields such as ALL, MESSAGEID,
ALL-TRUSTED.
Appending a modifier ":raw" to a header field name will inhibit
decoding of quoted-printable or base-64 encoded strings, and will preserve
all whitespace inside the header string. The ":raw" may also be
applied to pseudo-headers e.g. "ALL:raw" will return a pristine
(unmodified) header section.
Appending a modifier ":addr" to a header field name will cause
everything except the first email address to be removed from the header
field. It is mainly applicable to header fields 'From', 'Sender', 'To',
'Cc' along with their 'Resent-*' counterparts, and the 'Return-Path'.
Appending a modifier ":name" to a header field name will cause
everything except the first display name to be removed from the header
field. It is mainly applicable to header fields containing a single mail
address: 'From', 'Sender', along with their 'Resent-From' and
'Resent-Sender' counterparts.
It is syntactically permitted to append more than one modifier to a header
field name, although currently most combinations achieve no additional
effect, for example "From:addr:raw" or "From:raw:addr"
is currently the same as "From:addr" .
For example, appending ":addr" to a header name will result in
example@foo in all of the following cases:
- 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>
For example, appending ":name" to a header name will result in
"Foo Blah" (without quotes) in all of the following cases:
- 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. Note that all whitespace inside the headers, at line
folds, is currently compressed into a single space (' ') character. To
obtain a pristine (unmodified) header section, use "ALL:raw" - the
:raw modifier is documented above.
- "ToCc" can be used to mean the contents of both
the 'To' and 'Cc' headers.
- "EnvelopeFrom" is 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. See
"envelope_sender_header" for more information on how to set
this.
- "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 to '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.
- "X-Spam-Relays-Untrusted",
"X-Spam-Relays-Trusted", "X-Spam-Relays-Internal" and
"X-Spam-Relays-External" represent a portable, pre-parsed
representation of the message's network path, as recorded in the Received
headers, divided into 'trusted' vs 'untrusted' and 'internal' vs 'external'
sets. See "http://wiki.apache.org/spamassassin/TrustedRelays" for
more details.
"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 must 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:header_field_name
- Define a header field existence test.
"header_field_name" is the name of a header field to test for
existence. Not to be confused with a test for a nonempty header field
body, which can be implemented by a "header SYMBOLIC_TEST_NAME header
=~ /\S/" rule as described above.
- 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 reserved 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
<http://tools.ietf.org/html/rfc5735> as private.
- the 'set' argument
- This is used as a 'zone ID'. If you want to look up a
multiple-meaning zone like 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.
The domain name is considered to be a fully qualified domain name (i.e. not
subject to DNS resolver's search or default domain options). No trailing
period is needed, and will be removed if specified.
- 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.
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.
In addition, you can test all untrusted IP addresses by placing '-untrusted'
at the end of the set name. Important note -- this does NOT include the IP
address from the most recent 'untrusted line', as used in '-firsttrusted'
above. That's because we're talking about the trustworthiness of the IP
address data, not the source header line, here; and in the case of the
most recent header (the 'firsttrusted'), that data can be trusted. See the
Wiki page at "http://wiki.apache.org/spamassassin/TrustedRelays"
for more information on this.
- Selecting just the last external IP
- By using '-lastexternal' at the end of the set name, you
can select only the external host that connected to your internal network,
or at least the last external host with a public IP.
- 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. Multiline expressions will
need to be used to match strings that are broken by line breaks.
- 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 an arithmetic expression in terms of other
tests, with an unhit test having the value "0" and a hit test
having a nonzero value. The value of a hit meta test is that of its
arithmetic expression. The value of a hit eval test is that returned by
its method. The value of a hit header, body, rawbody, uri, or full test
which has the "multiple" tflag is the number of times the test
hit. The value of any other type of hit test is "1".
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.
- reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ...
]
- Defines the name of a test that should be
"reused" during the scoring process. If a message has an
X-Spam-Status header that shows a hit for this rule or any of the old rule
names given, a hit will be added for this rule when mass-check
--reuse is used. Examples:
"reuse SPF_PASS"
"reuse MY_NET_RULE_V2 MY_NET_RULE_V1"
The actual logic for reuse tests is done by
Mail::SpamAssassin::Plugin::Reuse.
- tflags SYMBOLIC_TEST_NAME flags
- Used to set flags on a test. Parameter is a space-separated
list of flag names or flag name = value pairs. These flags are used in the
score-determination back end system for details of the test's behaviour.
Please see "bayes_auto_learn" 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.
- autolearn_force
- The test will be subject to less stringent autolearn
thresholds.
Normally, SpamAssassin will require 3 points from the header and 3 points
from the body to be auto-learned as spam. This option keeps the threshold
at 6 points total but changes it to have no regard to the source of the
points.
- multiple
- The test will be evaluated multiple times, for use with
meta rules. Only affects header, body, rawbody, uri, and full tests.
- maxhits=N
- If multiple is specified, limit the number of hits
found to N. If the rule is used in a meta that counts the hits (e.g.
__RULENAME > 5), this is a way to avoid wasted extra work (use
"tflags multiple maxhits=6").
For example:
uri __KAM_COUNT_URIS /^./
tflags __KAM_COUNT_URIS multiple maxhits=16
describe __KAM_COUNT_URIS A multiple match used to count URIs in a message
meta __KAM_HAS_0_URIS (__KAM_COUNT_URIS == 0)
meta __KAM_HAS_1_URIS (__KAM_COUNT_URIS >= 1)
meta __KAM_HAS_2_URIS (__KAM_COUNT_URIS >= 2)
meta __KAM_HAS_3_URIS (__KAM_COUNT_URIS >= 3)
meta __KAM_HAS_4_URIS (__KAM_COUNT_URIS >= 4)
meta __KAM_HAS_5_URIS (__KAM_COUNT_URIS >= 5)
meta __KAM_HAS_10_URIS (__KAM_COUNT_URIS >= 10)
meta __KAM_HAS_15_URIS (__KAM_COUNT_URIS >= 15)
- ips_only
- This flag is specific to rules invoking an URIDNSBL plugin,
it is documented there.
- domains_only
- This flag is specific to rules invoking an URIDNSBL plugin,
it is documented there.
- ns
- This flag is specific to rules invoking an URIDNSBL plugin,
it is documented there.
- a
- This flag is specific to rules invoking an URIDNSBL plugin,
it is documented there.
- priority SYMBOLIC_TEST_NAME n
- Assign a specific priority to a test. All tests, except for
DNS and Meta tests, are run in increasing priority value order (negative
priority values are run before positive priority values). The default test
priority is 0 (zero).
The values <-99999999999999> and <-99999999999998> have a
special meaning internally, and should not 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
PRIVILEGED SETTINGS
section. No matter what "allow_user_rules" is set to, these can
never be set from a user's "user_prefs" file when spamc/spamd is
being used. However, all settings can be used by local programs run directly
by the user.
- 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.
- rbl_timeout t [t_min] [zone] (default: 15 3)
- 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 (in seconds) to wait for a 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), but will shrink the timeout according to a percentage of
queries already completed. As the number of queries remaining approaches
0, the timeout value will gradually approach a t_min value, which is an
optional second parameter and defaults to 0.2 * t. If t is smaller than
t_min, the initial timeout is set to t_min. Here is a chart of queries
remaining versus the timeout in seconds, for the default 15 second / 3
second timeout setting:
queries left 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
timeout 15 14.9 14.5 13.9 13.1 12.0 10.7 9.1 7.3 5.3 3
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 should
finish within 7.3 seconds since their query started or they will be timed
out. Note that timed out queries are only aborted when there is nothing
else left for SpamAssassin to do - long evaluation of other rules may
grant queries additional time.
If a parameter 'zone' is specified (it must end with a letter, which
distinguishes it from other numeric parametrs), then the setting only
applies to DNS queries against the specified DNS domain (host, domain or
RBL (sub)zone). Matching is case-insensitive, the actual domain may be a
subdomain of the specified zone.
- util_rb_tld tld1 tld2 ...
- This option allows the addition of new TLDs to the
RegistrarBoundaries code. Updates to the list usually happen when new
versions of SpamAssassin are released, but sometimes it's necessary to add
in new TLDs faster than a release can occur. TLDs include things like com,
net, org, etc.
- util_rb_2tld 2tld-1.tld 2tld-2.tld ...
- This option allows the addition of new 2nd-level TLDs
(2TLD) to the RegistrarBoundaries code. Updates to the list usually happen
when new versions of SpamAssassin are released, but sometimes it's
necessary to add in new 2TLDs faster than a release can occur. 2TLDs
include things like co.uk, fed.us, etc.
- util_rb_3tld 3tld1.some.tld 3tld2.other.tld ...
- This option allows the addition of new 3rd-level TLDs
(3TLD) to the RegistrarBoundaries code. Updates to the list usually happen
when new versions of SpamAssassin are released, but sometimes it's
necessary to add in new 3TLDs faster than a release can occur. 3TLDs
include things like demon.co.uk, plc.co.im, etc.
- bayes_path /path/filename (default:
~/.spamassassin/bayes)
- This is the directory and filename for Bayes databases.
Several databases will be created, with this as the base directory and
filename, with "_toks", "_seen", etc. appended to the
base. 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. For system-wide SpamAssassin use, you may
want to reduce disk space usage by sharing this across all users. However,
Bayes appears to be more effective with individual user databases.
- 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). The
argument is a string of octal digits, it is converted to a numeric value
internally.
- 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). For
example, set this to Mail::SpamAssassin::BayesStore::SQL to use the
generic SQL storage module.
- 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.
- bayes_sql_username_authorized ( 0 | 1 ) (default: 0)
- Whether to call the services_authorized_for_username plugin
hook in BayesSQL. If the hook does not determine that the user is allowed
to use bayes or is invalid then the database will not be initialized.
NOTE: By default the user is considered invalid until a plugin returns a
true value. If you enable this, but do not have a proper plugin loaded,
all users will turn up as invalid.
The username passed into the plugin can be affected by the
bayes_sql_override_username config option.
- 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 search, 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?saconfig?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 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_scores_ldap_username
- This is the Bind DN used to connect to the LDAP server. It
defaults to the empty string (""), allowing anonymous binding to
work.
Example: "cn=master,dc=koehntopp,dc=de"
- user_scores_ldap_password
- This is the password used to connect to the LDAP server. It
defaults to the empty string ("").
- user_scores_fallback_to_global (default: 1)
- Fall back to global scores and settings if userprefs can't
be loaded from SQL or LDAP, instead of passing the message through
unprocessed.
- loadplugin PluginModuleName [/path/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.
- tryplugin PluginModuleName [/path/module.pm]
- Same as "loadplugin", but silently ignored if the
.pm file cannot be found in the filesystem.
- ignore_always_matching_regexps (Default: 0)
- Ignore any rule which contains a regexp which always
matches. Currently only catches regexps which contain '||', or which begin
or end with a '|'. Also ignore rules with "some" combinatorial
explosions.
PREPROCESSING OPTIONS¶
- include filename
- Include configuration lines from "filename".
Relative paths are considered relative to the current configuration file
or user preferences file.
- if (boolean perl expression)
- Used to support conditional interpretation of the
configuration file. Lines between this and a corresponding
"else" or "endif" line will be ignored unless the
expression evaluates as true (in the perl sense; that is, defined and
non-0 and non-empty string).
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.
- has(Name::Of::Package::function_name)
- This is a function call that returns 1 if the perl package
named "Name::Of::Package" includes a function called
"function_name", or "undef" otherwise. Note that
packages can be SpamAssassin plugins or built-in classes, there's no
difference in this respect. Internally this invokes UNIVERSAL::can.
- can(Name::Of::Package::function_name)
- This is a function call that returns 1 if the perl package
named "Name::Of::Package" includes a function called
"function_name" and that function returns a true value
when called with no arguments, otherwise "undef" is returned.
Is similar to "has", except that it also calls the named function,
testing its return value (unlike the perl function UNIVERSAL::can). This
makes it possible for a 'feature' function to determine its result value
at run time.
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)".
- else
- 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 false (in the perl sense; that is, not defined and not 0 and
non-empty string).
- 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.
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.
_YESNO_ "Yes" for spam, "No" for nonspam (=ham)
_YESNO(spam_str,ham_str)_ returns the first argument ("Yes" if missing)
for spam, and the second argument ("No" if missing) for ham
_YESNOCAPS_ "YES" for spam, "NO" for nonspam (=ham)
_YESNOCAPS(spam_str,ham_str)_ same as _YESNO(...)_, but uppercased
_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)
_RULESVERSION_ comma-separated list of rules versions, retrieved from
an '# UPDATE version' comment in rules files; if there is
more than one set of rules (update channels) the order
is unspecified (currently sorted by names of files);
_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)
_DATE_ rfc-2822 date of scan
_STARS(*)_ one "*" (use any character) for each full score point
(note: limited to 50 'stars')
_RELAYSTRUSTED_ relays used and deemed to be trusted (see the
'X-Spam-Relays-Trusted' pseudo-header)
_RELAYSUNTRUSTED_ relays used that can not be trusted (see the
'X-Spam-Relays-Untrusted' pseudo-header)
_RELAYSINTERNAL_ relays used and deemed to be internal (see the
'X-Spam-Relays-Internal' pseudo-header)
_RELAYSEXTERNAL_ relays used and deemed to be external (see the
'X-Spam-Relays-External' pseudo-header)
_LASTEXTERNALIP_ IP address of client in the external-to-internal
SMTP handover
_LASTEXTERNALRDNS_ reverse-DNS of client in the external-to-internal
SMTP handover
_LASTEXTERNALHELO_ HELO string used by client in the external-to-internal
SMTP handover
_AUTOLEARN_ autolearn status ("ham", "no", "spam", "disabled",
"failed", "unavailable")
_AUTOLEARNSCORE_ portion of message score used by autolearn
_TESTS(,)_ tests hit separated by "," (or other separator)
_TESTSSCORES(,)_ as above, except with scores appended (eg. AWL=-3.0,...)
_SUBTESTS(,)_ subtests (start with "__") hit separated by ","
(or other separator)
_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
_HEADER(NAME)_ includes the value of a message header. value is the same
as is found for header rules (see elsewhere in this doc)
_TIMING_ timing breakdown report
_ADDEDHEADERHAM_ resulting header fields as requested by add_header for spam
_ADDEDHEADERSPAM_ resulting header fields as requested by add_header for ham
_ADDEDHEADER_ same as ADDEDHEADERHAM for ham or ADDEDHEADERSPAM for spam
If a tag reference uses the name of a tag which is not in this list or defined
by a loaded plugin, the reference will be left intact and not replaced by any
value.
The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional
second argument which specifies a format. See the
HAMMYTOKENS/SPAMMYTOKENS
TAG FORMAT section, below, for details.
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.
The locales string should specify either both the language and country, e.g.
"lang pt_BR", or just the language, e.g. "lang de".
SEE ALSO¶
"Mail::SpamAssassin" "spamassassin" "spamd"