FreeBSD Manual Pages

home | help

Mail::S...n::Conf(3) User Contributed Perl Documentation Mail::S...n::Conf(3)

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/spamassas-
sin" 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/under-
scores, 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 auto-
matically delete or discard messages marked as spam, as your users will
complain, but if you choose to do so, only delete messages with an ex-
ceptionally high score such as 15.0 or higher. This option was previ-
ously 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. "SYM-
BOLIC_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 de-
fault 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 run-
ning.

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 "wel-
comelist_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 metacharac-
ters 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 "Re-
sent-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 "enve-
lope_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 dis-
tribution 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 wel-
comelist_from line, which implies that a wildcard only matches liter-
ally 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 match-
ing 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-insensi-
tive.

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 (op-
tionally 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 spec-
ify "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 sim-
ple cases, it will be, but for a complex network you may get better re-
sults 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 un-
til 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 un-
til 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_wel-
comelist_from_rcvd entry, so for example a distribution wel-
comelist_from_rcvd can be overridden in a local.cf file, or an individ-
ual 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 (incor-
rectly) 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 distri-
bution blocklist_from can be overridden in a local.cf file, or an indi-
vidual 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 (Re-
sent-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 for-
mat 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 "Re-
sent-To" or "Resent-Cc" are set, use those; otherwise check all ad-
dresses 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 (Re-
sent-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 (incor-
rectly) as spam. This is different from "welcomelist_from" and "wel-
comelist_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-authoriza-
tion 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 "wel-
comelist_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 en-
tries 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 do-
mains. 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 exam-
ple:

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) deter-
mines 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 en-
list_uri_host settings.

Enlisting to lists named 'BLOCK' and 'WELCOME' have their shorthand di-
rectives 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 do-
mains. Removing an unlisted name is ignored (is not an error). List-
name 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@some-
where.com", "*@isp.com", or "*.domain.net" will all work. Specifi-
cally, "*" 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 "en-
list_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 com-
ment 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 Spa-
mAssassin 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 _SUBJPRE-
FIX_" 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 multi-
ple .cf files, which are interpreted in alphabetic order.

"string" can contain tags as explained below in the TEMPLATE TAGS sec-
tion. 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-Ver-
sion 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 multi-
ple .cf files, which are interpreted in alphabetic order, so
"clear_headers" in a later file will remove all added headers from pre-
viously interpreted configuration files, which may or may not be de-
sired.

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 set-
ting 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 ad-
dition, a header named X-Spam-Report will be added to spam. You can
use the remove_header option to remove that header after setting re-
port_safe to 0.

See report_safe_copy_headers if you want to copy headers from the orig-
inal mail into tagged messages.

report_wrap_width (default: 75)
This option sets the wrap width for description lines in the X-Spam-Re-
port 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 in-
coming 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 per-
mitted by default.

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

The rules "CHARSET_FARAWAY", "CHARSET_FARAWAY_BODY", and "CHARSET_FAR-
AWAY_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 de-
clared character set in a Content-Type header, but if the decoding at-
tempt fails a module Encode::Detect::Detector is consulted (if avail-
able) 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 (prefer-
ably 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 informa-
tion.

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 cur-
rently 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 overlap-
ping 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 sequen-
tial 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, re-
gardless 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) net-
work 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 block-
lists, 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 ad-
dresses 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, regard-
less 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. Ex-
amples 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 it-
self, as defined by your trusted_networks and internal_networks config-
uration.

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 in-
cluded in msa_networks you should treat the MSA as trusted but not in-
ternal, however if the MSA is also acting as an MX or intermediate re-
lay 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-au-
thenticated users in msa_networks. Doing so will result in unknown ex-
ternal 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 ad-
dress 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_originat-
ing_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 re-
solving 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), SpamAssas-
sin 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 net-
work connection is down, and in some cases it can wrongly guess that
DNS is unavailable because a test connection failed, what causes dis-
abling 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 num-
ber. 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 as-
sumed. When an IPv6 address is specified along with a port number, the
address must be enclosed in brackets to avoid parsing ambiguity regard-
ing a colon separator. A scoped link-local IP address is allowed (as-
suming 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 pro-
vided 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 num-
bers 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 configura-
tion 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 ran-
domization 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_lo-
cal_ports_avoid.

If the resulting set of port numbers is empty, then SpamAssassin does
not apply its ports randomization logic, but instead leaves the operat-
ing 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. noro-
tate, NoEDNS) to counteract a previously enabled option. Option names
are not case-sensitive. The dns_options directive may appear in con-
figuration files multiple times, the last setting prevails.

Option v4 declares resolver capable of returning IPv4 (A) records. Op-
tion 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 speci-
fied 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 de-
fault. Allowing UDP payload size larger than 512 bytes can avoid trun-
cation 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 sec-
onds, 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 colli-
sions 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_re-
striction. 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 pur-
pose of an explicit "allow" entry is to be able to override a previ-
ously 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_restric-
tion' 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 tem-
porarily 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/spa-
massassin (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 SpamAs-
sassin. This is a master on/off switch for all Bayes-related opera-
tions.

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

See the documentation for the "Mail::SpamAssassin::Plugin::AutoLearn-
Threshold" plugin module for details on how Bayes auto-learning is im-
plemented 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. Addi-
tionally 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 key-
words 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 cur-
rently 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 gath-
ered regarding its usefulness.

See also option "bayes_ignore_header" for a fine-grained control on in-
dividual 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, suf-
fixed 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 key-
words are interpreted sequentially, adding or removing items from the
final set as they appear in their order in "bayes_token_sources" direc-
tive(s).

bayes_ignore_header header_name
If you receive mail filtered by upstream mail systems, like a spam-fil-
tering 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-insensi-
tive. 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 fre-
quently occur in ham. For example, one might read messages from a pre-
ferred bookstore but also get unwanted spam messages from other book-
stores. 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 re-
ceive ham messages containing potentially spammy words might fear that
some spam messages might be in danger of being marked as ham. The ad-
dresses 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 num-
ber 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 ("spa-
massassin -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 ex-
piry 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 to-
kens 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 expira-
tions, 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 to-
kens from a bayes database. The value is observed on a best-effort ba-
sis, exact timing promises are not necessarily kept. If a bayes datas-
tore 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 expira-
tions, 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 al-
lowed 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 ex-
ceeded, 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 'mas-
ter_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 sup-
ply 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 de-
termine the final score. The behaviour is similar to short-circuiting
with attribute 'on', as implemented by a Shortcircuit plugin. A syn-
thetic 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 pro-
cessing 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, integra-
tion 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 sensi-
ble "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; how-
ever, 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 avail-
able 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 gener-
ate 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 us-
ing 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 fol-
lowing:

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 signa-
tures) appear to indicate that they are safe to use. However, it may
choose the wrong headers in some mailserver configurations. (More dis-
cussion of this can be found in bug 2142 and bug 4747 in the SpamAssas-
sin 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 transac-
tion.

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 con-
tain 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 "Re-
ceived" 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/spamassas-
sin" 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 host-
name 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 de-
fault, this is determined dynamically as whatever the host running Spa-
mAssassin 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" configu-
ration 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 separa-
tors.

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}| [[:up-
per:]][[: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 do-
ing. 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 decod-
ing of quoted-printable or base-64 encoded strings, and will preserve
all whitespace inside the header string. The ":raw" may also be ap-
plied to pseudo-headers e.g. "ALL:raw" will return a pristine (unmodi-
fied) header section.

Appending a modifier ":addr" to a header field name will cause every-
thing 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 'Re-
turn-Path'.

Appending a modifier ":name" to a header field name will cause every-
thing 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 'Re-
sent-Sender' counterparts.

It is syntactically permitted to append more than one modifier to a
header field name, although currently most combinations achieve no ad-
ditional effect, for example "From:addr:raw" or "From:raw:addr" is cur-
rently the same as "From:addr" .

For example, appending ":addr" to a header name will result in exam-
ple@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 docu-
mented above. Also similar that return headers added by specific re-
lays: ALL-TRUSTED, ALL-INTERNAL, ALL-UNTRUSTED, ALL-EXTERNAL.
"ToCc" can be used to mean the contents of both the 'To' and 'Cc' head-
ers.
"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-Mes-
sage-Id' or to 'X-Message-Id', then uses its own one in the 'Mes-
sage-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-In-
ternal" and "X-Spam-Relays-External" represent a portable, pre-parsed
representation of the message's network path, as recorded in the Re-
ceived headers, divided into 'trusted' vs 'untrusted' and 'internal' vs
'external' sets. See "https://wiki.apache.org/spamassassin/Truste-
dRelays" for more details.

"op" is either "=~" (contains regular expression) or "!~" (does not
contain regular expression), and "pattern" is a valid Perl regular ex-
pression, 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 alphanu-
merics 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 un-
dergoing QA, and these are given a very low score.

If you add or modify a test, please be sure to run a sanity check af-
terwards 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. "argu-
ments" 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 Re-
ceived: 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/as-
signments/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 op-
tions). No trailing period is needed, and will be removed if spec-
ified.

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 de-
scribing why the IP is listed, typically a hyperlink to a database en-
try.

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 normal-
ize_charset setting will also affect how raw bytes are presented.
Rules in .cf files should be written portably - to match "a with um-
laut" 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 infor-
mation.

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 accu-
rately 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 expres-
sion. 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 ex-
pression. 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 mes-
sage 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 expres-
sion. 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 under-
scores). 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-sensi-
tive.

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::Plu-
gin::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 behav-
iour. 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 check-
ing system or if -L is used, therefore its score should not be mod-
ified.

niceThe 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 try-
ing 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 prior-
ity values are run before positive priority values). The default test
priority is 0 (zero).

The values "-99999999999999" and "-99999999999998" have a special mean-
ing 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://perl-
doc.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. How-
ever, 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 regres-
sion 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 de-
coded/stripped mime-part is truncated approx to this size. Helps scan-
ning large messages safely, so it's not necessary to skip them com-
pletely. 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 ap-
proaches 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 de-
fault 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, NN, ... International domain names may be specified in
ASCII-compatible encoding (ACE), e.g. xn--p1ai, xn--qxam, or with Uni-
code labels encoded as UTF-8 octets, e.g. NN, I<micro>I>>.

util_rb_2tld 2tld-1.tld 2tld-2.tld ...
This option maintains list of valid 2nd-level TLDs in the Registry-
Boundaries code. 2TLDs include things like co.uk, fed.us, etc. Inter-
national domain names may be specified in ASCII-compatible encoding
(ACE), or with Unicode labels encoded as UTF-8 octets.

util_rb_3tld 3tld1.some.tld 3tld2.other.tld ...
This option maintains list of valid 3rd-level TLDs in the Registry-
Boundaries code. 3TLDs include things like demon.co.uk, plc.co.im,
etc. International domain names may be specified in ASCII-compatible
encoding (ACE), or with Unicode labels encoded as UTF-8 octets.

clear_util_rb
Empty internal list of valid TLDs (including 2nd and 3rd level) which
RegistryBoundaries code uses. Only useful if you want to override the
standard lists supplied by sa-update.

bayes_path /path/filename (default: ~/.spamassassin/bayes)
This is the directory and filename for Bayes databases. Several data-
bases 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", "~/.spamassas-
sin/bayes_toks", etc.

By default, each user has their own in their "~/.spamassassin" direc-
tory with mode 0700/0600. For system-wide SpamAssassin use, you may
want to reduce disk space usage by sharing this across all users. How-
ever, Bayes appears to be more effective with individual user data-
bases.

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 re-
sulting 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 exam-
ple, 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 then 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 compo-
nents 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 at-
tribute 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 user-
name.

Example: "ldap://localhost:389/dc=koehntopp,dc=de?saconfig?uid=__USER-
NAME__"

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 re-
trieve 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 user-
name.

_DOMAIN_
The portion after the @ as derived from the current user's user-
name, 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 user-
name 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 [Mail::SpamAssassin::Plugin::]ModuleName [/path/module.pm]
Load a SpamAssassin plugin module. The "ModuleName" is the perl module
name, used to create the plugin object itself.

Module naming is strict, name must only contain alphanumeric characters
or underscores. File must have .pm extension.

"/path/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 rela-
tive 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 ModuleName [/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. Cur-
rently only catches regexps which contain '||', or which begin or end
with a '|'. Also ignore rules with "some" combinatorial explosions.

geodb_module STRING
This option tells SpamAssassin which geolocation module to use. If not
specified, all supported ones are tried in this order:

Plugins can override this internally if required.

MaxMind::DB::Reader (same as GeoIP2::Database::Reader)
Geo::IP
IP::Country::DB_File (not used unless geodb_options path set)
IP::Country::Fast

geodb_options dbtype:/path/to/db ...
Supported dbtypes:

city - use City database country - use Country database isp - try load-
ing ISP database asn - try loading ASN database

Append full database path with colon, for example:
isp:/opt/geoip/isp.mmdb

Plugins can internally request all types they require, geodb_options is
only needed if the default location search (described below) does not
work.

GeoIP/GeoIP2 searches these files/directories:

country:
GeoIP2-Country.mmdb, GeoLite2-Country.mmdb
GeoIP.dat (and v6 version)
city:
GeoIP2-City.mmdb, GeoLite2-City.mmdb
GeoIPCity.dat, GeoLiteCity.dat (and v6 versions)
isp:
GeoIP2-ISP.mmdb
GeoIPISP.dat, GeoLiteISP.dat (and v6 versions)
directories:
/usr/local/share/GeoIP
/usr/share/GeoIP
/var/lib/GeoIP
/opt/share/GeoIP

geodb_search_path /path/to/GeoIP ...
Alternative to geodb_options. Overrides the default list of directories
to search for default filenames.

PREPROCESSING OPTIONS
include filename
Include configuration lines from "filename". Relative paths are con-
sidered 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-run-
ning SpamAssassin engine. Note: The version used is in the inter-
nal SpamAssassin version format which is "x.yyyzzz", where x is ma-
jor version, y is minor version, and z is maintenance version. So
3.0.0 is 3.000000, and 3.4.80 is 3.004080.

perl_version
(Introduced in 3.4.1) This will be replaced with the version num-
ber of the currently-running perl engine. Note: The version used
is in the $] version format which is "x.yyyzzz", where x is major
version, y is minor version, and z is maintenance version. So
5.8.8 is 5.008008, and 5.10.0 is 5.010000. Use to protect rules
that incorporate RE syntax elements introduced in later versions of
perl, such as the "++" non-backtracking match introduced in perl
5.10. For example:

# Avoid lint error on older perl installs
# Check SA version first to avoid warnings on checking perl_version on older SA
if version > 3.004001 && perl_version >= 5.018000
body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
endif

Note that the above will still generate a warning on perl older
than 5.10.0; to avoid that warning do this instead:

# Avoid lint error on older perl installs
if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
body INVALID_RE_SYNTAX_IN_PERL_5_8 /\w++/
endif

Warning: a can() test is only defined for perl 5.10.0!

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. Inter-
nally 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)".

elseUsed 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) ver-
sion 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.

enable_compat xxxxxx
Define a version compatibility flag.

This creates a function named "Mail::SpamAssassin::Conf::com-
pat_xxxxxx", which returns true. It can be used for example in cf-
files, similarly as existing "feature_" checks:

if can(Mail::SpamAssassin::Conf::compat_xxxxxx)

Name can only consist of [a-zA-Z0-9_] characters.

Mainly used by SpamAssassin distribution to handle backwards compati-
bility issues.

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

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

_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')
_SENDERDOMAIN_ a domain name of the envelope sender address, lowercased
_AUTHORDOMAIN_ a domain name of the author address (the From header
field), lowercased; note that RFC 5322 allows a mail
message to have multiple authors - currently only the
domain name of the first email address is returned
_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)
_FIRSTTRUSTEDIP_ IP address of first trusted client (see RELAYSTRUSTED)
_FIRSTTRUSTEDREVIP_ IP address of first trusted client (in reversed
format suitable for RBL queries)
_LASTEXTERNALIP_ IP address of client in the external-to-internal
SMTP handover
_LASTEXTERNALREVIP_ IP address of client in the external-to-internal
SMTP handover (in reversed format suitable for RBL
queries)
_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)
_SUBTESTSCOLLAPSED(,)_ subtests (start with "__") hit separated by ","
(or other separator) with duplicated rules collapsed
_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)
_SUBJPREFIX_ subject prefix based on rules, to be prepended to Subject
header by SpamAssassin caller
_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 de-
fined by a loaded plugin, the reference will be left intact and not re-
placed by any value.

All template tag names must consist of only uppercase character set
[A-Z0-9_] and not contain consecutive underscores (__).

Additional, plugin specific, template tags can be found in the documenta-
tion for the following plugins:

L<Mail::SpamAssassin::Plugin::ASN>
L<Mail::SpamAssassin::Plugin::AWL>
L<Mail::SpamAssassin::Plugin::TxRep>

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

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

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

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

Results in message header:

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

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

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

"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 to-
ken indicates a declassification distance greater than 9.

longProbability, 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 sec-
ond 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.)

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

Current locale is determined from LANGUAGE, LC_ALL, LC_MESSAGES or LANG en-
vironment variables, first found is used.

The locales string should specify either both the language and country,
e.g. "lang pt_BR", or just the language, e.g. "lang de".

Example:

lang de describe EXAMPLE_RULE Beispielregel

SEE ALSO
Mail::SpamAssassin(3) spamassassin(1) spamd(1)

perl v5.34.1 2023-09-26 Mail::S...n::Conf(3)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=Mail::SpamAssassin::Conf&sektion=3&manpath=FreeBSD+14.0-RELEASE+and+Ports>

home | help

Header And Logo

Peripheral Links

Site Navigation

FreeBSD Manual Pages