Linux.pl: Przeglądarka stron manuala

Mail::SpamAssassin::CoUserpContributed Perl DocumMail::SpamAssassin::Conf(3pm)

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/mail/spamassassin" directories.

The following web page lists the most important configuration settings
used to configure SpamAssassin; novices are encouraged to read it
first:

https://wiki.apache.org/spamassassin/ImportantInitialConfigItems

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

Test names ("SYMBOLIC_TEST_NAME") can only contain
alphanumerics/underscores, can not start with digit, and must be less
than 128 characters.

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.

WELCOMELIST AND BLOCKLIST OPTIONS
welcomelist_from user@example.com
Previously whitelist_from which will work interchangeably until
4.1.

Used to welcomelist 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
"welcomelist_auth" or other authenticated welcomelisting methods,
or "welcomelist_from_rcvd".

Welcomelist and blocklist 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
"welcomelist_from" lines are also OK.

The headers checked for welcomelist 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.

welcomelist_from joe@example.com fred@example.com
welcomelist_from *@example.com

unwelcomelist_from user@example.com
Previously unwelcomelist_from which will work interchangeably until
4.1.

Used to remove a default welcomelist_from entry, so for example a
distribution welcomelist_from can be overridden in a local.cf file,
or an individual user can override a welcomelist_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 welcomelist_from line, which implies that a wildcard only
matches literally the same wildcard (not 'any' address).

e.g.

unwelcomelist_from joe@example.com fred@example.com
unwelcomelist_from *@example.com

welcomelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
Previously whitelist_from_rcvd which will work interchangeably
until 4.1.

Works similarly to welcomelist_from, except that in addition to
matching a sender address, a relay's rDNS name or its IP address
must match too for the welcomelisting rule to fire. The first
parameter is a sender's e-mail address to welcomelist, 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 a TCP-info information
field as provided in a FROM clause of a trace information (i.e. in
a 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 a domain component of that hostname,
or an IP address (optionally followed by a slash and a prefix
length) in square brackets. The address prefix (mask) length with a
slash may stand within brackets along with an address, or may
follow the bracketed address. Reverse DNS lookup is done by an MTA,
not by SpamAssassin.

For backward compatibility as an alternative to a CIDR notation, an
IPv4 address in brackets may be truncated on classful boundaries to
cover whole subnets, e.g. "[10.1.2.3]", "[10.1.2]", "[10.1]",
"[10]".

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.0/24]", 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.

welcomelist_from_rcvd joe@example.com example.com
welcomelist_from_rcvd *@* mail.example.org
welcomelist_from_rcvd *@axkit.org [192.0.2.123]
welcomelist_from_rcvd *@axkit.org [192.0.2.0/24]
welcomelist_from_rcvd *@axkit.org [192.0.2.0]/24
welcomelist_from_rcvd *@axkit.org [2001:db8:1234::/48]
welcomelist_from_rcvd *@axkit.org [2001:db8:1234::]/48

def_welcomelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
Previously def_whitelist_from_rcvd which will work interchangeably
until 4.1.

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

welcomelist_allows_relays user@example.com
Previously whitelist_allows_relays which will work interchangeably
until 4.1.

Specify addresses which are in "welcomelist_from_rcvd" that
sometimes send through a mail relay other than the listed ones. By
default mail with a From address that is in "welcomelist_from_rcvd"
that does not match the relay will trigger a forgery rule.
Including the address in "welcomelist_allows_relay" prevents that.

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

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

e.g.

welcomelist_allows_relays joe@example.com fred@example.com
welcomelist_allows_relays *@example.com

unwelcomelist_from_rcvd user@example.com
Previously unwhitelist_from_rcvd which will work interchangeably
until 4.1.

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

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

e.g.

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

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

unblocklist_from user@example.com
Previously unblacklist_from which will work interchangeably until
4.1.

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

e.g.

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

welcomelist_to user@example.com
Previously whitelist_to which will work interchangeably until 4.1.

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

There are three levels of To-welcomelisting, "welcomelist_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 welcomelist 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.

blocklist_to user@example.com
Previously blacklist_auth which will work interchangeably until
4.1.

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

welcomelist_auth user@example.com
Previously whitelist_auth which will work interchangeably until
4.1.

Used to specify addresses which send mail that is often tagged
(incorrectly) as spam. This is different from "welcomelist_from"
and "welcomelist_from_rcvd" in that it first verifies that the
message was sent by an authorized sender for the address, before
welcomelisting.

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 "welcomelist_auth" is roughly equivalent to specifying
duplicate "welcomelist_from_spf", "welcomelist_from_dk", and
"welcomelist_from_dkim" lines for each of the addresses specified.

e.g.

welcomelist_auth joe@example.com fred@example.com
welcomelist_auth *@example.com

def_welcomelist_auth user@example.com
Previously def_whitelist_auth which will work interchangeably until
4.1.

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

unwelcomelist_auth user@example.com
Previously unwhitelist_auth which will work interchangeably until
4.1.

Used to remove a "welcomelist_auth" or "def_welcomelist_auth"
entry. The specified email address has to match exactly the address
previously used.

e.g.

unwelcomelist_auth joe@example.com fred@example.com
unwelcomelist_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 exclamation 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 'BLOCK' and 'WELCOME' have their shorthand
directives blocklist_uri_host and welcomelist_uri_host and
corresponding default rules, but the names 'BLOCK' and 'WELCOME'
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.

enlist_addrlist (listname) user@example.com
Adds one or more addresses to a named list of addresses. The named
list can then be consulted through a check_from_in_list() or a
check_to_in_list() 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.

Listed addresses are 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
"enlist_addrlist" lines are also OK.

Enlisting an address to the list named blocklist_to is synonymous
to using the directive blocklist_to.

Enlisting an address to the list named blocklist_from is synonymous
to using the directive blocklist_from.

Enlisting an address to the list named welcomelist_to is synonymous
to using the directive welcomelist_to.

Enlisting an address to the list named welcomelist_from is
synonymous to using the directive welcomelist_from.

e.g.

enlist_addrlist (PAYPAL_ADDRESS) service@paypal.com
enlist_addrlist (PAYPAL_ADDRESS) *@paypal.co.uk

blocklist_uri_host host-or-domain ...
Previously blacklist_uri_host which will work interchangeably until
4.1.

Is a shorthand for a directive: enlist_uri_host (BLOCK) host ...

Please see directives enlist_uri_host and delist_uri_host for
details.

welcomelist_uri_host host-or-domain ...
Previously whitelist_uri_host which will work interchangeably until
4.1.

Is a shorthand for a directive: enlist_uri_host (WELCOME) 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 parentheses.
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.

subjprefix
Add a prefix in emails Subject if a rule is matched. To enable
this option "rewrite_header Subject" config option must be enabled
as well.

The check "if can(Mail::SpamAssassin::Conf::feature_subjprefix)"
should be used to silence warnings in previous SpamAssassin
versions.

To be able to use this feature a "add_header all Subjprefix
_SUBJPREFIX_" configuration line could be needed when the glue
between the MTA and SpamAssassin rewrites the email content.

Here is an example on how to use this feature:

rewrite_header Subject *****SPAM*****
add_header all Subjprefix _SUBJPREFIX_
body OLEMACRO_MALICE eval:check_olemacro_malice()
describe OLEMACRO_MALICE Dangerous Office Macro
score OLEMACRO_MALICE 5.0
if can(Mail::SpamAssassin::Conf::feature_subjprefix)
subjprefix OLEMACRO_MALICE [VIRUS]
endif

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.

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.

report_wrap_width (default: 75)
This option sets the wrap width for description lines in the
X-Spam-Report header, not accounting for tab width.

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: 1)
Whether to decode non- UTF-8 and non-ASCII textual parts and recode
them to UTF-8 before the text is given over to rules processing.
The character set used for attempted decoding is primarily based on
a declared character set in a Content-Type header, but if the
decoding attempt fails a module Encode::Detect::Detector is
consulted (if available) to provide a guess based on the actual
text, and decoding is re-attempted. Even if the option is enabled
no unnecessary decoding and re-encoding work is done when possible
(like with an all-ASCII text with a US-ASCII or extended ASCII
character set declaration, e.g. UTF-8 or ISO-8859-nn or Windows-
nnnn).

Unicode support in old versions of perl or in a core module Encode
is likely to be buggy in places, so if the normalize_charset
function is enabled it is advised to stick to more recent versions
of perl (preferably 5.12 or later). The module
Encode::Detect::Detector is optional, when necessary it will be
used if it is available.

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 blocklist checks
will never query for hosts on these networks.

See "https://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 module Net::CIDR::Lite is installed, it's also possible to use
dash separated IP range format (e.g. 192.168.1.1-192.168.255.255).

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 regardless 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:

o If the 'from' host has an IP address in a private (RFC 1918)
network range, then it's trusted

o If there are authentication tokens in the received header, and
the previous host was trusted, then this host is also trusted

o 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: none)
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.

A default list may be supplied via sa-update, use
"clear_originating_ip_headers" to clear and override the settings
if needed.

clear_originating_ip_headers
Empty the list of 'originating IP address' header field names.
Useful if you want to override the standard list supplied by sa-
update.

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: Blockhole 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. A scoped link-local
IP address is allowed (assuming underlying modules allow it).

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
dns_server fe80::1%lo0
dns_server [fe80::1%lo0]: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: v4, v6, norotate, nodns0x20, edns=4096)
Provides a (whitespace or comma -separated) list of options
applying to DNS resolving. Available options are: v4, v6, 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 v4 declares resolver capable of returning IPv4 (A) records.
Option v6 declares resolver capable of returning IPv6 (AAAA)
records. One would set nov6 if the resolver is filtering AAAA
responses. NOTE: these options only refer to resolving capabilies,
there is no other meaning like whether the IP address of resolver
itself is IPv4 or IPv6.

Option edns (or edns0) 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.

Special wildcard "dns_query_restriction deny *" is supported to
block all queries except allowed ones.

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

dns_block_rule RULE domain
If rule named RULE is hit, DNS queries to specified domain are
temporarily blocked. Intended to be used with rules that check RBL
return codes for specific blocked status. For example:

urirhssub URIBL_BLOCKED multi.uribl.com. A 1
dns_block_rule URIBL_BLOCKED multi.uribl.com

Block status is maintained across all processes by empty statefile
named "dnsblock_multi.uribl.com" in global state dir:
home_dir_for_helpers/.spamassassin, $HOME/.spamassassin,
/var/lib/spamassassin (localstate), depending which is found and
writable.

dns_block_time (default: 300)
dns_block_rule query blockage will last this many seconds.

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_token_sources (default: header visible invisible uri)
Controls which sources in a mail message can contribute tokens
(e.g. words, phrases, etc.) to a Bayes classifier. The argument is
a space-separated list of keywords: header, visible, invisible,
uri, mimepart), each of which may be prefixed by a no to indicate
its exclusion. Additionally two reserved keywords are allowed: all
and none (or: noall). The list of keywords is processed
sequentially: a keyword all adds all available keywords to a set
being built, a none or noall clears the set, other non-negated
keywords are added to the set, and negated keywords are removed
from the set. Keywords are case-insensitive.

The default set is: header visible invisible uri, which is
equivalent for example to: All NoMIMEpart. The reason why mimepart
is not currently in a default set is that it is a newer source
(introduced with SpamAssassin version 3.4.1) and not much
experience has yet been gathered regarding its usefulness.

See also option "bayes_ignore_header" for a fine-grained control on
individual header fields under the umbrella of a more general
keyword header here.

Keywords imply the following data sources:

header - tokens collected from a message header section
visible - words from visible text (plain or HTML) in a message body
invisible - hidden/invisible text in HTML parts of a message body
uri - URIs collected from a message body
mimepart - digests (hashes) of all MIME parts (textual or non-
textual) of a message, computed after Base64 and quoted-printable
decoding, suffixed by their Content-Type
all - adds all the above keywords to the set being assembled
none or noall - removes all keywords from the set

The "bayes_token_sources" directive may appear multiple times, its
keywords are interpreted sequentially, adding or removing items
from the final set as they appear in their order in
"bayes_token_sources" directive(s).

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. Header matching is
case-insensitive. 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
"welcomelist_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
welcomelisting or blocklisting 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.
"https://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: UTF-8)
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})/

parse_dkim_uris ( 0 | 1 ) (default: 1)
If this option is set to 1 and the message contains DKIM headers,
the headers will be parsed for URIs to process alongside URIs found
in the body with some rules and modules (ex. URIDNSBL)

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

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

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

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. Also similar that return headers
added by specific relays: ALL-TRUSTED, ALL-INTERNAL, ALL-UNTRUSTED,
ALL-EXTERNAL.
"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
"https://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 header specified matches multiple headers, their text will
be concatenated with embedded \n's. Therefore you may wish to use
"/m" if you use "^" or "$" in your regular expression.

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 registered by a "Mail::SpamAssassin::Plugin" 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 blocklist or welcomelist). 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
"https://www.iana.org/assignments/ipv4-address-space", or
"https://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 welcomelist), 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
"https://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, or 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. Parts
declared as text/html will be rendered from HTML to text.

Body is processed as a raw byte string, which means Unicode-
specific regex features like \p{} can NOT be used for matching.
The normalize_charset setting will also affect how raw bytes are
presented. Rules in .cf files should be written portably - to
match "a with umlaut" character, look for both LATIN1 and UTF8 raw
byte variants: /(?:\xE4|\xC3\xA4)/

All body paragraphs (double-newline-separated blocks text) are
turned into a linebreaks-removed, whitespace-normalized, single
line. Any lines longer than 2kB are split into shorter separate
lines (from a boundary when possible), this may unexpectedly
prevent pattern from matching. Patterns are matched independently
against each of these lines.

Note that by default the message Subject header is considered part
of the body and becomes the first line when running the rules. If
you don't want to match Subject along with body text, use "tflags
RULENAME nosubject".

See "https://wiki.apache.org/SpamAssassin/WritingRules" for more
information.

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.

Note that the text is split into 2-4kB chunks (from a word boundary
when possible), this may unexpectedly prevent pattern from
matching. Patterns are matched independently against each of these
chunks.

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.

Note that CRLF/LF line endings are matched as the original message
has them. For any full rules that match newlines, it's recommended
to use \r?$ instead of plain $, so it works on all systems.

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.

meta SYMBOLIC_TEST_NAME ... rules_matching(RULEGLOB) ...
Special function that will expand to list of matching rulenames.
Can be used anywhere in expressions. Argument supports glob style
rulename matching (* = anything, ? = one character). Matching is
case-sensitive.

For example, this will hit if at least two __FOO_* rule hits:

body __FOO_1 /xxx/
body __FOO_2 /yyy/
body __FOO_3 /zzz/
meta FOO_META rules_matching(__FOO_*) >= 2

Which would be the same as:

meta FOO_META (__FOO_1 + __FOO_2 + __FOO_3) >= 2

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.

noawl
This flag is specific when using AWL plugin.

Normally, AWL plugin normalizes scores via auto-welcomelist. In
some scenarios it works against the system administrator when
trying to add some rules to correct miss-classified email. When
AWL plugin searches the email and finds the noawl flag it will
exit without normalizing the score nor storing the value in db.

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)

nosubject
Used only for body rules. If specified, Subject header will
not be a part of the matched body text. See body for more
info.

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.

notrim
This flag is specific to rules invoking an URIDNSBL plugin, it
is documented there.

nolog
This flag will hide (sensitive) rule informations from reports

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.

CAPTURING TAGS USING REGEX NAMED CAPTURE GROUPS
SpamAssassin 4.0 supports capturing template tags from regex rules.
The captured tags, along with other standard template tags, can be used
in other rules as a matching string. See TEMPLATE TAGS section for
more info on tags.

Capturing can be done in any body/rawbody/header/uri/full rule that
uses a regex for matching (not eval rules). Standard Perl named
capture group format "(?<NAME>pattern)" must be used, as described in
<https://perldoc.perl.org/perlre#(?%3CNAME%3Epattern)>.

Example, capturing a tag named "BODY_HELLO_NAME":

body __HELLO_NAME /\bHello, (?<BODY_HELLO_NAME>\w+)\b/

The tag can then be used in another rule for matching, using a
%{TAGNAME} template. This would search the captured name in From-
header:

header HELLO_NAME_IN_FROM From =~ /\b%{BODY_HELLO_NAME}\b/i

If any tag that a rule depends on is not found, then the rule is not
run at all. To prevent a literal %{NAME} string from being parsed as a
template, it can be escaped with a backslash: \%{NAME}.

Captured tags can also be used in reports and in other plugins like
AskDNS, with the standard "_BODY_HELLO_NAME_" notation.

Note that at this time there is no automatic dependency tracking for
rule running order. All rules that use named capture groups are
automatically set to priority -10000, so that the tags should always be
ready for any normal rules to use. When rule depends on a tag that
might be set at later stage by a plugin for example, it's priority
should be set manually to a higher value.

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

body_part_scan_size (default: 50000)
Per mime-part scan size limit in bytes for "body" type rules. The
decoded/stripped mime-part is truncated approx to this size. Helps
scanning large messages safely, so it's not necessary to skip them
completely. Disabled with 0.

rawbody_part_scan_size (default: 500000)
Like body_part_scan_size, for "rawbody" type rules.

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 maintains a list of valid TLDs in the
RegistryBoundaries code. Top level domains (TLD) include things
like com, net, org, xn--p1ai, , ... International domain names may
be specified in ASCII-compatible encoding (ACE), e.g. xn--p1ai,
xn--qxam, or with Unicode labels encoded as UTF-8 octets, e.g. , .

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