GNU.WIKI: The GNU/Linux Knowledge Base

  [HOME] [PHP Manual] [HowTo] [ABS] [MAN1] [MAN2] [MAN3] [MAN4] [MAN5] [MAN6] [MAN7] [MAN8] [MAN9]

  [0-9] [Aa] [Bb] [Cc] [Dd] [Ee] [Ff] [Gg] [Hh] [Ii] [Jj] [Kk] [Ll] [Mm] [Nn] [Oo] [Pp] [Qq] [Rr] [Ss] [Tt] [Uu] [Vv] [Ww] [Xx] [Yy] [Zz]


NAME

       Mail::SpamAssassin::Conf - SpamAssassin configuration file

SYNOPSIS

         # a comment

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

         full PARA_A_2_C_OF_1618         /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
         describe PARA_A_2_C_OF_1618     Claims compliance with senate bill 1618

         header FROM_HAS_MIXED_NUMS      From =~ /\d+[a-z]+\d+\S*@/i
         describe FROM_HAS_MIXED_NUMS    From: contains numbers mixed in with letters

         score A_HREF_TO_REMOVE          2.0

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

         lang pt_BR report O programa detetor de Spam ZOE [...]

DESCRIPTION

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

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

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

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.

USER PREFERENCES

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

   SCORING OPTIONS
       required_score n.nn (default: 5)
           Set the score required before a mail is considered spam.  "n.nn"
           can be an integer or a real number.  5.0 is the default setting,
           and is quite aggressive; it would be suitable for a single-user
           setup, but if you're an ISP installing SpamAssassin, you should
           probably set the default to be more conservative, like 8.0 or 10.0.
           It is not recommended to automatically delete or discard messages
           marked as spam, as your users will complain, but if you choose to
           do so, only delete messages with an exceptionally high score such
           as 15.0 or higher. This option was previously known as
           "required_hits" and that name is still accepted, but is deprecated.

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

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

           If four valid scores are listed, then the score that is used
           depends on how SpamAssassin is being used. The first score is used
           when both Bayes and network tests are disabled (score set 0). The
           second score is used when Bayes is disabled, but network tests are
           enabled (score set 1). The third score is used when Bayes is
           enabled and network tests are disabled (score set 2). The fourth
           score is used when Bayes is enabled and network tests are enabled
           (score set 3).

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

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

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

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

   WHITELIST AND BLACKLIST OPTIONS
       whitelist_from user@example.com
           Used to whitelist sender addresses which send mail that is often
           tagged (incorrectly) as spam.

           Use of this setting is not recommended, since it blindly trusts the
           message, which is routinely and easily forged by spammers and phish
           senders. The recommended solution is to instead use
           "whitelist_auth" or other authenticated whitelisting methods, or
           "whitelist_from_rcvd".

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

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

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

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

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

           e.g.

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

       unwhitelist_from user@example.com
           Used to override a default whitelist_from entry, so for example a
           distribution whitelist_from can be overridden in a local.cf file,
           or an individual user can override a whitelist_from entry in their
           own "user_prefs" file.  The specified email address has to match
           exactly (although case-insensitively) the address previously used
           in a whitelist_from line, which implies that a wildcard only
           matches literally the same wildcard (not 'any' address).

           e.g.

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

       whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
           Works similarly to whitelist_from, except that in addition to
           matching a sender address, a relay's rDNS name or its IP address
           must match too for the whitelisting rule to fire. The first
           parameter is a sender's e-mail address to whitelist, and the second
           is a string to match the relay's rDNS, or its IP address. Matching
           is case-insensitive.

           This second parameter is matched against the TCP-info information
           field as provided in a FROM clause of a trace information (i.e. the
           Received header field, see RFC 5321). Only the Received header
           fields inserted by trusted hosts are considered. This parameter can
           either be a full hostname, or the domain component of that
           hostname, or an IP address in square brackets.  The reverse DNS
           lookup is done by a MTA, not by SpamAssassin.

           In case of an IPv4 address in brackets, it may be truncated on
           classful boundaries to cover whole subnets, e.g. "[10.1.2.3]",
           "[10.1.2]", "[10.1]", "[10]".  CIDR notation is currently not
           supported, nor is IPv6. The matching on IP address is mainly
           provided to cover rare cases where whitelisting of a sending MTA is
           desired which does not have a correct reverse DNS configured.

           In other words, if the host that connected to your MX had an IP
           address 192.0.2.123 that mapped to 'sendinghost.example.org', you
           should specify "sendinghost.example.org", or "example.org", or
           "[192.0.2.123]" or "[192.0.2]" here.

           Note that this requires that "internal_networks" be correct.  For
           simple cases, it will be, but for a complex network you may get
           better results by setting that parameter.

           It also requires that your mail exchangers be configured to perform
           DNS reverse lookups on the connecting host's IP address, and to
           record the result in the generated Received header field according
           to RFC 5321.

           e.g.

             whitelist_from_rcvd joe@example.com  example.com
             whitelist_from_rcvd *@axkit.org      sergeant.org
             whitelist_from_rcvd *@axkit.org      [192.0.2.123]

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

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

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

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

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

           e.g.

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

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

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

           e.g.

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

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

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

           e.g.

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

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

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

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

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

       more_spam_to user@example.com
           See above.

       all_spam_to user@example.com
           See above.

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

       whitelist_auth user@example.com
           Used to specify addresses which send mail that is often tagged
           (incorrectly) as spam.  This is different from "whitelist_from" and
           "whitelist_from_rcvd" in that it first verifies that the message
           was sent by an authorized sender for the address, before
           whitelisting.

           Authorization is performed using one of the installed sender-
           authorization schemes: SPF (using
           "Mail::SpamAssassin::Plugin::SPF"), or DKIM (using
           "Mail::SpamAssassin::Plugin::DKIM").  Note that those plugins must
           be active, and working, for this to operate.

           Using "whitelist_auth" is roughly equivalent to specifying
           duplicate "whitelist_from_spf", "whitelist_from_dk", and
           "whitelist_from_dkim" lines for each of the addresses specified.

           e.g.

             whitelist_auth joe@example.com fred@example.com
             whitelist_auth *@example.com

       def_whitelist_auth user@example.com
           Same as "whitelist_auth", but used for the default whitelist
           entries in the SpamAssassin distribution.  The whitelist score is
           lower, because these are often targets for spammer spoofing.

       unwhitelist_auth user@example.com
           Used to override a "whitelist_auth" entry. The specified email
           address has to match exactly the address previously used in a
           "whitelist_auth" line.

           e.g.

             unwhitelist_auth joe@example.com fred@example.com
             unwhitelist_auth *@example.com

       enlist_uri_host (listname) host ...
           Adds one or more host names or domain names to a named list of URI
           domains.  The named list can then be consulted through a
           check_uri_host_listed() eval rule implemented by the WLBLEval
           plugin, which takes the list name as an argument. Parenthesis
           around a list name are literal - a required syntax.

           Host names may optionally be prefixed by an exclamantion mark '!',
           which produces false as a result if this entry matches. This makes
           it easier to exclude some subdomains when their superdomain is
           listed, for example:

             enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com

           No wildcards are supported, but subdomains do match implicitly.
           Lists are independent. Search for each named list starts by looking
           up the full hostname first, then leading fields are progressively
           stripped off (e.g.: sub.example.com, example.com, com) until a
           match is found or we run out of fields. The first matching entry
           (the most specific) determines if a lookup yielded a true (no '!'
           prefix) or a false (with a '!' prefix) result.

           If an URL found in a message contains an IP address in place of a
           host name, the given list must specify the exact same IP address
           (instead of a host name) in order to match.

           Use the delist_uri_host directive to neutralize previous
           enlist_uri_host settings.

           Enlisting to lists named 'BLACK' and 'WHITE' have their shorthand
           directives blacklist_uri_host and whitelist_uri_host and
           corresponding default rules, but the names 'BLACK' and 'WHITE' are
           otherwise not special or reserved.

       delist_uri_host [ (listname) ] host ...
           Removes one or more specified host names from a named list of URI
           domains.  Removing an unlisted name is ignored (is not an error).
           Listname is optional, if specified then just the named list is
           affected, otherwise hosts are removed from all URI host lists
           created so far. Parenthesis around a list name are a required
           syntax.

           Note that directives in configuration files are processed in
           sequence, the delist_uri_host only applies to previously listed
           entries and has no effect on enlisted entries in yet-to-be-
           processed directives.

           For convenience (similarity to the enlist_uri_host directive)
           hostnames may be prefixed by a an exclamation mark, which is
           stripped off from each name and has no meaning here.

       blacklist_uri_host host-or-domain ...
           Is a shorthand for a directive:  enlist_uri_host (BLACK) host ...

           Please see directives enlist_uri_host and delist_uri_host for
           details.

       whitelist_uri_host host-or-domain ...
           Is a shorthand for a directive:  enlist_uri_host (BLACK) host ...

           Please see directives enlist_uri_host and delist_uri_host for
           details.

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

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

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

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

       add_header { spam | ham | all } header_name string
           Customized headers can be added to the specified type of messages
           (spam, ham, or "all" to add to either).  All headers begin with
           "X-Spam-" (so a "header_name" Foo will generate a header called
           X-Spam-Foo).  header_name is restricted to the character set
           [A-Za-z0-9_-].

           The order of "add_header" configuration options is preserved,
           inserted headers will follow this order of declarations. When
           combining "add_header" with "clear_headers" and "remove_header",
           keep in mind that "add_header" appends a new header to the current
           list, after first removing any existing header fields of the same
           name. Note also that "add_header", "clear_headers" and
           "remove_header" may appear in multiple .cf files, which are
           interpreted in alphabetic order.

           "string" can contain tags as explained below in the TEMPLATE TAGS
           section.  You can also use "
" and "	" 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 "
" disables any further automatic
           wrapping (ie: long header lines are possible). The lines will still
           be properly folded (marked as continuing) though.

           You can customize existing headers with add_header (only the
           specified subset of messages will be changed).

           See also "clear_headers" and "remove_header" for removing headers.

           Here are some examples (these are the defaults, note that Checker-
           Version can not be changed or removed):

             add_header spam Flag _YESNOCAPS_
             add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
             add_header all Level _STARS(*)_
             add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_

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

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

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

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

           "add_header", "clear_headers" and "remove_header" may appear in
           multiple .cf files, which are interpreted in alphabetic order, so
           "clear_headers" in a later file will remove all added headers from
           previously interpreted configuration files, which may or may not be
           desired.

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

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

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

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

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

   LANGUAGE OPTIONS
       ok_locales xx [ yy zz ... ]        (default: all)
           This option is used to specify which locales are considered OK for
           incoming mail.  Mail using the character sets that are allowed by
           this option will not be marked as possibly being spam in a foreign
           language.

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

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

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

           Examples:

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

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

           Select the locales to allow from the list below:

           en   - Western character sets in general
           ja   - Japanese character sets
           ko   - Korean character sets
           ru   - Cyrillic character sets
           th   - Thai character sets
           zh   - Chinese (both simplified and traditional) character sets
       normalize_charset ( 0 | 1)        (default: 0)
           Whether to detect character sets and normalize message content to
           Unicode.  Requires the Encode::Detect module, HTML::Parser version
           3.46 or later, and Perl 5.8.5 or later.

   NETWORK TEST OPTIONS
       trusted_networks IPaddress[/masklen] ...   (default: none)
           What networks or hosts are 'trusted' in your setup.  Trusted in
           this case means that relay hosts on these networks are considered
           to not be potentially operated by spammers, open relays, or open
           proxies.  A trusted host could conceivably relay spam, but will not
           originate it, and will not forge header data. DNS blacklist checks
           will never query for hosts on these networks.

           See "http://wiki.apache.org/spamassassin/TrustPath" for more
           information.

           MXes for your domain(s) and internal relays should also be
           specified using the "internal_networks" setting. When there are
           'trusted' hosts that are not MXes or internal relays for your
           domain(s) they should only be specified in "trusted_networks".

           The "IPaddress" can be an IPv4 address (in a dot-quad form), or an
           IPv6 address optionally enclosed in square brackets. Scoped link-
           local IPv6 addresses are syntactically recognized but the interface
           scope is currently ignored (e.g. [fe80::1234%eth0] ) and should be
           avoided.

           If a "/masklen" is specified, it is considered a CIDR-style
           'netmask' length, specified in bits.  If it is not specified, but
           less than 4 octets of an IPv4 address are specified with a trailing
           dot, an implied netmask length covers all addresses in remaining
           octets (i.e. implied masklen is /8 or /16 or /24).  If masklen is
           not specified, and there is not trailing dot, then just a single IP
           address specified is used, as if the masklen were "/32" with an
           IPv4 address, or "/128" in case of an IPv6 address.

           If a network or host address is prefaced by a "!" the matching
           network or host will be excluded from the list even if a less
           specific (shorter netmask length) subnet is later specified in the
           list. This allows a subset of a wider network to be exempt. In case
           of specifying overlapping subnets, specify more specific subnets
           first (tighter matching, i.e. with a longer netmask length),
           followed by less specific (shorter netmask length) subnets to get
           predictable results regarless of the search algorithm used - when
           Net::Patricia module is installed the search finds the tightest
           matching entry in the list, while a sequential search as used in
           absence of the module Net::Patricia will find the first matching
           entry in the list.

           Note: 127.0.0.0/8 and ::1 are always included in trusted_networks,
           regardless of your config.

           Examples:

              trusted_networks 192.168.0.0/16        # all in 192.168.*.*
              trusted_networks 192.168.              # all in 192.168.*.*
              trusted_networks 212.17.35.15          # just that host
              trusted_networks !10.0.1.5 10.0.1/24   # all in 10.0.1.* but not 10.0.1.5
              trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
                # 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64

           This operates additively, so a "trusted_networks" line after
           another one will append new entries to the list of trusted
           networks.  To clear out the existing entries, use
           "clear_trusted_networks".

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

           If neither "trusted_networks" or "internal_networks" is set, a
           basic inference algorithm is applied.  This works as follows:

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

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

           ·   Otherwise this host, and all further hosts, are consider
               untrusted.

       clear_trusted_networks
           Empty the list of trusted networks.

       internal_networks IPaddress[/masklen] ...   (default: none)
           What networks or hosts are 'internal' in your setup.   Internal
           means that relay hosts on these networks are considered to be MXes
           for your domain(s), or internal relays.  This uses the same syntax
           as "trusted_networks", above - see there for details.

           This value is used when checking 'dial-up' or dynamic IP address
           blocklists, in order to detect direct-to-MX spamming.

           Trusted relays that accept mail directly from dial-up connections
           (i.e. are also performing a role of mail submission agents - MSA)
           should not be listed in "internal_networks". List them only in
           "trusted_networks".

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

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

           Every entry in "internal_networks" must appear in
           "trusted_networks"; in other words, "internal_networks" is always a
           subset of the trusted set.

           Note: 127/8 and ::1 are always included in internal_networks,
           regardless of your config.

       clear_internal_networks
           Empty the list of internal networks.

       msa_networks IPaddress[/masklen] ...   (default: none)
           The networks or hosts which are acting as MSAs in your setup (but
           not also as MX relays). This uses the same syntax as
           "trusted_networks", above - see there for details.

           MSA means that the relay hosts on these networks accept mail from
           your own users and authenticates them appropriately.  These relays
           will never accept mail from hosts that aren't authenticated in some
           way. Examples of authentication include, IP lists, SMTP AUTH, POP-
           before-SMTP, etc.

           All relays found in the message headers after the MSA relay will
           take on the same trusted and internal classifications as the MSA
           relay itself, as defined by your trusted_networks and
           internal_networks configuration.

           For example, if the MSA relay is trusted and internal so will all
           of the relays that precede it.

           When using msa_networks to identify an MSA it is recommended that
           you treat that MSA as both trusted and internal.  When an MSA is
           not included in msa_networks you should treat the MSA as trusted
           but not internal, however if the MSA is also acting as an MX or
           intermediate relay you must always treat it as both trusted and
           internal and ensure that the MSA includes visible auth tokens in
           its Received header to identify submission clients.

           Warning: Never include an MSA that also acts as an MX (or is also
           an intermediate relay for an MX) or otherwise accepts mail from
           non-authenticated users in msa_networks.  Doing so will result in
           unknown external relays being trusted.

       clear_msa_networks
           Empty the list of msa networks.

       originating_ip_headers header ...   (default: X-Yahoo-Post-IP
       X-Originating-IP X-Apparently-From X-SenderIP)
           A list of header field names from which an originating IP address
           can be obtained. For example, webmail servers may record a client
           IP address in X-Originating-IP.

           These IP addresses are virtually appended into the Received: chain,
           so they are used in RBL checks where appropriate.

           Currently the IP addresses are not added into X-Spam-Relays-*
           header fields, but they may be in the future.

       clear_originating_ip_headers
           Empty the list of 'originating IP address' header field names.

       always_trust_envelope_sender ( 0 | 1 )   (default: 0)
           Trust the envelope sender even if the message has been passed
           through one or more trusted relays.  See also
           "envelope_sender_header".

       skip_rbl_checks ( 0 | 1 )   (default: 0)
           Turning on the skip_rbl_checks setting will disable the DNSEval
           plugin, which implements Real-time Block List (or: Blackhole List)
           (RBL) lookups.

           By default, SpamAssassin will run RBL checks. Individual blocklists
           may be disabled selectively by setting a score of a corresponding
           rule to 0.

           See also a related configuration parameter skip_uribl_checks, which
           controls the URIDNSBL plugin (documented in the URIDNSBL man page).

       dns_available { yes | no | test[: domain1 domain2...] }   (default:
       yes)
           Tells SpamAssassin whether DNS resolving is available or not. A
           value yes indicates DNS resolving is available, a value no
           indicates DNS resolving is not available - both of these values
           apply unconditionally and skip initial DNS tests, which can be slow
           or unreliable.

           When the option value is a test (with or without arguments),
           SpamAssassin will query some domain names on the internet during
           initialization, attempting to determine if DNS resolving is working
           or not. A space-separated list of domain names may be specified
           explicitly, or left to a built-in default of a dozen or so domain
           names. From an explicit or a default list a subset of three domain
           names is picked randomly for checking. The test queries for NS
           records of these domain: if at least one query returns a success
           then SpamAssassin considers DNS resolving as available, otherwise
           not.

           The problem is that the test can introduce some startup delay if a
           network connection is down, and in some cases it can wrongly guess
           that DNS is unavailable because a test connection failed, what
           causes disabling several DNS-dependent tests.

           Please note, the DNS test queries for NS records, so specify domain
           names, not host names.

           Since version 3.4.0 of SpamAssassin a default setting for option
           dns_available is yes. A default in older versions was test.

       dns_server ip-addr-port  (default: entries provided by Net::DNS)
           Specifies an IP address of a DNS server, and optionally its port
           number.  The dns_server directive may be specified multiple times,
           each entry adding to a list of available resolving name servers.
           The ip-addr-port argument can either be an IPv4 or IPv6 address,
           optionally enclosed in brackets, and optionally followed by a colon
           and a port number. In absence of a port number a standard port
           number 53 is assumed. When an IPv6 address is specified along with
           a port number, the address must be enclosed in brackets to avoid
           parsing ambiguity regarding a colon separator,

           Examples :
            dns_server 127.0.0.1
            dns_server 127.0.0.1:53
            dns_server [127.0.0.1]:53
            dns_server [::1]:53

           In absence of dns_server directives, the list of name servers is
           provided by Net::DNS module, which typically obtains the list from
           /etc/resolv.conf, but this may be platform dependent. Please
           consult the Net::DNS::Resolver documentation for details.

       clear_dns_servers
           Empty the list of explicitly configured DNS servers through a
           dns_server directive, falling back to Net::DNS -supplied defaults.

       dns_local_ports_permit ranges...
           Add the specified ports or ports ranges to the set of allowed port
           numbers that can be used as local port numbers when sending DNS
           queries to a resolver.

           The argument is a whitespace-separated or a comma-separated list of
           single port numbers n, or port number pairs (i.e. m-n) delimited by
           a '-', representing a range. Allowed port numbers are between 1 and
           65535.

           Directives dns_local_ports_permit and dns_local_ports_avoid are
           processed in order in which they appear in configuration files.
           Each directive adds (or subtracts) its subsets of ports to a
           current set of available ports.  Whatever is left in the set by the
           end of configuration processing is made available to a DNS
           resolving client code.

           If the resulting set of port numbers is empty (see also the
           directive dns_local_ports_none), then SpamAssassin does not apply
           its ports randomization logic, but instead leaves the operating
           system to choose a suitable free local port number.

           The initial set consists of all port numbers in the range
           1024-65535.  Note that system config files already modify the set
           and remove all the IANA registered port numbers and some other
           ranges, so there is rarely a need to adjust the ranges by site-
           specific directives.

           See also directives dns_local_ports_permit and
           dns_local_ports_none.

       dns_local_ports_avoid ranges...
           Remove specified ports or ports ranges from the set of allowed port
           numbers that can be used as local port numbers when sending DNS
           queries to a resolver.

           Please see directive dns_local_ports_permit for details.

       dns_local_ports_none
           Is a fast shorthand for:

             dns_local_ports_avoid 1-65535

           leaving the set of available DNS query local port numbers empty. In
           all respects (apart from speed) it is equivalent to the shown
           directive, and can be freely mixed with dns_local_ports_permit and
           dns_local_ports_avoid.

           If the resulting set of port numbers is empty, then SpamAssassin
           does not apply its ports randomization logic, but instead leaves
           the operating system to choose a suitable free local port number.

           See also directives dns_local_ports_permit and
           dns_local_ports_avoid.

       dns_test_interval n   (default: 600 seconds)
           If dns_available is set to test, the dns_test_interval time in
           number of seconds will tell SpamAssassin how often to retest for
           working DNS.  A numeric value is optionally suffixed by a time unit
           (s, m, h, d, w, indicating seconds (default), minutes, hours, days,
           weeks).

       dns_options opts   (default: norotate, nodns0x20, edns=4096)
           Provides a (whitespace or comma -separated) list of options
           applying to DNS resolving. Available options are: rotate, dns0x20
           and edns (or edns0). Option name may be negated by prepending a no
           (e.g. norotate, NoEDNS) to counteract a previously enabled option.
           Option names are not case-sensitive. The dns_options directive may
           appear in configuration files multiple times, the last setting
           prevails.

           Option edns (or edsn0) may take a value which specifies a
           requestor's acceptable UDP payload size according to EDNS0
           specifications (RFC 6891, ex RFC 2671) e.g. edns=4096. When EDNS0
           is off (noedns or edns=512) a traditional implied UDP payload size
           is 512 bytes, which is also a minimum allowed value for this
           option. When the option is specified but a value is not provided, a
           conservative default of 1220 bytes is implied. It is recommended to
           keep edns enabled when using a local recursive DNS server which
           supports EDNS0 (like most modern DNS servers do), a suitable
           setting in this case is edns=4096, which is also a default.
           Allowing UDP payload size larger than 512 bytes can avoid
           truncation of resource records in large DNS responses (like in TXT
           records of some SPF and DKIM responses, or when an unreasonable
           number of A records is published by some domain). The option should
           be disabled when a recursive DNS server is only reachable through
           non- RFC 6891 compliant middleboxes (such as some old-fashioned
           firewall) which bans DNS UDP payload sizes larger than 512 bytes. A
           suitable value when a non-local recursive DNS server is used and a
           middlebox does allow EDNS0 but blocks fragmented IP packets is
           perhaps 1220 bytes, allowing a DNS UDP packet to fit within a
           single IP packet in most cases (a slightly less conservative range
           would be 1280-1410 bytes).

           Option rotate causes SpamAssassin to choose a DNS server at random
           from all servers listed in "/etc/resolv.conf" every
           dns_test_interval seconds, effectively spreading the load over all
           currently available DNS servers when there are many spamd workers.

           Option dns0x20 enables randomization of letters in a DNS query
           label according to draft-vixie-dnsext-dns0x20, decreasing a chance
           of collisions of responses (by chance or by a malicious intent) by
           increasing spread as provided by a 16-bit query ID and up to 16
           bits of a port number, with additional bits as encoded by flipping
           case (upper/lower) of letters in a query. The number of additional
           random bits corresponds to the number of letters in a query label.
           Should work reliably with all mainstream DNS servers - do not turn
           on if you see frequent info messages "dns: no callback for id:" in
           the log, or if RBL or URIDNS lookups do not work for no apparent
           reason.

       dns_query_restriction (allow|deny) domain1 domain2 ...
           Option allows disabling of rules which would result in a DNS query
           to one of the listed domains. The first argument must be a literal
           "allow" or "deny", remaining arguments are domains names.

           Most DNS queries (with some exceptions) are subject to
           dns_query_restriction.  A domain to be queried is successively
           stripped-off of its leading labels (thus yielding a series of its
           parent domains), and on each iteration a check is made against an
           associative array generated by dns_query_restriction options.
           Search stops at the first match (i.e. the tightest match), and the
           matching entry with its "allow" or "deny" value then controls
           whether a DNS query is allowed to be launched.

           If no match is found an implicit default is to allow a query. The
           purpose of an explicit "allow" entry is to be able to override a
           previously configured "deny" on the same domain or to override an
           entry (possibly yet to be configured in subsequent config
           directives) on one of its parent domains.  Thus an 'allow
           zen.spamhaus.org' with a 'deny spamhaus.org' would permit DNS
           queries on a specific DNS BL zone but deny queries to other zones
           under the same parent domain.

           Domains are matched case-insensitively, no wildcards are
           recognized, there should be no leading or trailing dot.

           Specifying a block on querying a domain name has a similar effect
           as setting a score of corresponding DNSBL and URIBL rules to zero,
           and can be a handy alternative to hunting for such rules when a
           site policy does not allow certain DNS block lists to be queried.

           Example:
             dns_query_restriction deny  dnswl.org surbl.org
             dns_query_restriction allow zen.spamhaus.org
             dns_query_restriction deny  spamhaus.org mailspike.net
           spamcop.net

       clear_dns_query_restriction
           The option removes any entries entered by previous
           'dns_query_restriction' options, leaving the list empty, i.e.
           allowing DNS queries for any domain (including any DNS BL zone).

   LEARNING OPTIONS
       use_learner ( 0 | 1 )         (default: 1)
           Whether to use any machine-learning classifiers with SpamAssassin,
           such as the default 'BAYES_*' rules.  Setting this to 0 will
           disable use of any and all human-trained classifiers.

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

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

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

           See the documentation for the
           "Mail::SpamAssassin::Plugin::AutoLearnThreshold" plugin module for
           details on how Bayes auto-learning is implemented by default.

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

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

       bayes_ignore_from user@example.com
           Bayesian classification and autolearning will not be performed on
           mail from the listed addresses.  Program "sa-learn" will also
           ignore the listed addresses if it is invoked using the
           "--use-ignores" option.  One or more addresses can be listed, see
           "whitelist_from".

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

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

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

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

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

       bayes_sql_override_username
           Used by BayesStore::SQL storage implementation.

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

       bayes_use_hapaxes        (default: 1)
           Should the Bayesian classifier use hapaxes (words/tokens that occur
           only once) when classifying?  This produces significantly better
           hit-rates.

       bayes_journal_max_size        (default: 102400)
           SpamAssassin will opportunistically sync the journal and the
           database.  It will do so once a day, but will sync more often if
           the journal file size goes above this setting, in bytes.  If set to
           0, opportunistic syncing will not occur.

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

       bayes_auto_expire             (default: 1)
           If enabled, the Bayes system will try to automatically expire old
           tokens from the database.  Auto-expiry occurs when the number of
           tokens in the database surpasses the bayes_expiry_max_db_size
           value. If a bayes datastore backend does not implement individual
           key/value expirations, the setting is silently ignored.

       bayes_token_ttl               (default: 3w, i.e. 3 weeks)
           Time-to-live / expiration time in seconds for tokens kept in a
           Bayes database.  A numeric value is optionally suffixed by a time
           unit (s, m, h, d, w, indicating seconds (default), minutes, hours,
           days, weeks).

           If bayes_auto_expire is true and a Bayes datastore backend supports
           it (currently only Redis), this setting controls deletion of
           expired tokens from a bayes database. The value is observed on a
           best-effort basis, exact timing promises are not necessarily kept.
           If a bayes datastore backend does not implement individual
           key/value expirations, the setting is silently ignored.

       bayes_seen_ttl                (default: 8d, i.e. 8 days)
           Time-to-live / expiration time in seconds for 'seen' entries (i.e.
           mail message digests with their status) kept in a Bayes database.
           A numeric value is optionally suffixed by a time unit (s, m, h, d,
           w, indicating seconds (default), minutes, hours, days, weeks).

           If bayes_auto_expire is true and a Bayes datastore backend supports
           it (currently only Redis), this setting controls deletion of
           expired 'seen' entries from a bayes database. The value is observed
           on a best-effort basis, exact timing promises are not necessarily
           kept. If a bayes datastore backend does not implement individual
           key/value expirations, the setting is silently ignored.

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

   MISCELLANEOUS OPTIONS
       time_limit n   (default: 300)
           Specifies a limit on elapsed time in seconds that SpamAssassin is
           allowed to spend before providing a result. The value may be
           fractional and must not be negative, zero is interpreted as
           unlimited. The default is 300 seconds for consistency with the
           spamd default setting of --timeout-child .

           This is a best-effort advisory setting, processing will not be
           abruptly aborted at an arbitrary point in processing when the time
           limit is exceeded, but only on reaching one of locations in the
           program flow equipped with a time test. Currently equipped with the
           test are the main checking loop, asynchronous DNS lookups, plugins
           which are calling external programs.  Rule evaluation is guarded by
           starting a timer (alarm) on each set of compiled rules.

           When a message is passed to Mail::SpamAssassin::parse, a deadline
           time is established as a sum of current time and the "time_limit"
           setting.

           This deadline may also be specified by a caller through an option
           'master_deadline' in $suppl_attrib on a call to parse(), possibly
           providing a more accurate deadline taking into account past and
           expected future processing of a message in a mail filtering setup.
           If both the config option as well as a 'master_deadline' option in
           a call are provided, the shorter time limit of the two is used
           (since version 3.3.2).  Note that spamd (and possibly third-party
           callers of SpamAssassin) will supply the 'master_deadline' option
           in a call based on its --timeout-child option (or equivalent),
           unlike the command line "spamassassin", which has no such command
           line option.

           When a time limit is exceeded, most of the remaining tests will be
           skipped, as well as auto-learning. Whatever tests fired so far will
           determine the final score. The behaviour is similar to short-
           circuiting with attribute 'on', as implemented by a Shortcircuit
           plugin. A synthetic hit on a rule named TIME_LIMIT_EXCEEDED with a
           near-zero default score is generated, so that the report will
           reflect the event. A score for TIME_LIMIT_EXCEEDED may be provided
           explicitly in a configuration file, for example to achieve
           whitelisting or blacklisting effect for messages with long
           processing times.

           The "time_limit" option is a useful protection against excessive
           processing time on certain degenerate or unusually long or complex
           mail messages, as well as against some DoS attacks. It is also
           needed in time-critical pre-queue filtering setups (e.g. milter,
           proxy, integration with MTA), where message processing must finish
           before a SMTP client times out.  RFC 5321 prescribes in section
           4.5.3.2.6 the 'DATA Termination' time limit of 10 minutes, although
           it is not unusual to see some SMTP clients abort sooner on waiting
           for a response. A sensible "time_limit" for a pre-queue filtering
           setup is maybe 50 seconds, assuming that clients are willing to
           wait at least a minute.

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

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

           Note that different platforms require different locking systems.

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

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

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

       fold_headers ( 0 | 1 )        (default: 1)
           By default, headers added by SpamAssassin will be whitespace
           folded.  In other words, they will be broken up into multiple lines
           instead of one very long one and each continuation line will have a
           tabulator prepended to mark it as a continuation of the preceding
           one.

           The automatic wrapping can be disabled here.  Note that this can
           generate very long lines.  RFC 2822 required that header lines do
           not exceed 998 characters (not counting the final CRLF).

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

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

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

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

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

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

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

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

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

           example:

               envelope_sender_header X-SA-Exim-Mail-From

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

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

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

       report_charset CHARSET        (default: unset)
           Set the MIME Content-Type charset used for the text/plain report
           which is attached to spam mail messages.

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

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

           Tags can be included as explained above.

       clear_report_template
           Clear the report template.

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

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

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

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

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

       clear_unsafe_report_template
           Clear the unsafe_report template.

       mbox_format_from_regex
           Set a specific regular expression to be used for mbox file From
           separators.

           For example, this setting will allow sa-learn to process emails
           stored in a kmail 2 mbox:

           mbox_format_from_regex /^From \S+  ?[[:upper:]][[:lower:]]{2}(?:,
           \d\d [[:upper:]][[:lower:]]{2} \d{4} [0-2]\d:\d\d:\d\d [+-]\d{4}|
           [[:upper:]][[:lower:]]{2} [ 1-3]\d [ 0-2]\d:\d\d:\d\d \d{4})/

RULE DEFINITIONS AND PRIVILEGED SETTINGS

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

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

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

       redirector_pattern  /pattern/modifiers
           A regex pattern that matches both the redirector site portion, and
           the target site portion of a URI.

           Note: The target URI portion must be surrounded in parentheses and
                 no other part of the pattern may create a backreference.

           Example:
           http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude

             redirector_pattern    /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i

       header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset:
       STRING]
           Define a test.  "SYMBOLIC_TEST_NAME" is a symbolic test name, such
           as 'FROM_ENDS_IN_NUMS'.  "header" is the name of a mail header
           field, such as 'Subject', 'To', 'From', etc.  Header field names
           are matched case-insensitively (conforming to RFC 5322 section
           1.2.2), except for all-capitals metaheader fields such as ALL,
           MESSAGEID, ALL-TRUSTED.

           Appending a modifier ":raw" to a header field name will inhibit
           decoding of quoted-printable or base-64 encoded strings, and will
           preserve all whitespace inside the header string.  The ":raw" may
           also be applied to pseudo-headers e.g. "ALL:raw" will return a
           pristine (unmodified) header section.

           Appending a modifier ":addr" to a header field name will cause
           everything except the first email address to be removed from the
           header field.  It is mainly applicable to header fields 'From',
           'Sender', 'To', 'Cc' along with their 'Resent-*' counterparts, and
           the 'Return-Path'.

           Appending a modifier ":name" to a header field name will cause
           everything except the first display name to be removed from the
           header field. It is mainly applicable to header fields containing a
           single mail address: 'From', 'Sender', along with their
           'Resent-From' and 'Resent-Sender' counterparts.

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

           For example, appending ":addr" to a header name will result in
           example@foo in all of the following cases:

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

           For example, appending ":name" to a header name will result in "Foo
           Blah" (without quotes) in all of the following cases:

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

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

           "ALL" can be used to mean the text of all the message's headers.
           Note that all whitespace inside the headers, at line folds, is
           currently compressed into a single space (' ') character. To obtain
           a pristine (unmodified) header section, use "ALL:raw" - the :raw
           modifier is documented above.
           "ToCc" can be used to mean the contents of both the 'To' and 'Cc'
           headers.
           "EnvelopeFrom" is the address used in the 'MAIL FROM:' phase of the
           SMTP transaction that delivered this message, if this data has been
           made available by the SMTP server.  See "envelope_sender_header"
           for more information on how to set this.
           "MESSAGEID" is a symbol meaning all Message-Id's found in the
           message; some mailing list software moves the real 'Message-Id' to
           'Resent-Message-Id' or to 'X-Message-Id', then uses its own one in
           the 'Message-Id' header. The value returned for this symbol is the
           text from all 3 headers, separated by newlines.
           "X-Spam-Relays-Untrusted", "X-Spam-Relays-Trusted",
           "X-Spam-Relays-Internal" and "X-Spam-Relays-External" represent a
           portable, pre-parsed representation of the message's network path,
           as recorded in the Received headers, divided into 'trusted' vs
           'untrusted' and 'internal' vs 'external' sets.  See
           "http://wiki.apache.org/spamassassin/TrustedRelays" for more
           details.

           "op" is either "=~" (contains regular expression) or "!~" (does not
           contain regular expression), and "pattern" is a valid Perl regular
           expression, with "modifiers" as regexp modifiers in the usual
           style.   Note that multi-line rules are not supported, even if you
           use "x" as a modifier.  Also note that the "#" character must be
           escaped ("\#") or else it will be considered to be the start of a
           comment and not part of the regexp.

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

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

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

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

       header SYMBOLIC_TEST_NAME exists:header_field_name
           Define a header field existence test.  "header_field_name" is the
           name of a header field to test for existence.  Not to be confused
           with a test for a nonempty header field body, which can be
           implemented by a "header SYMBOLIC_TEST_NAME header =~ /\S/" rule as
           described above.

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

       header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone' [, 'sub-test'])
           Check a DNSBL (a DNS blacklist or whitelist).  This will retrieve
           Received: headers from the message, extract the IP addresses,
           select which ones are 'untrusted' based on the "trusted_networks"
           logic, and query that DNSBL zone.  There's a few things to note:

           duplicated or private IPs
               Duplicated IPs are only queried once and reserved IPs are not
               queried.  Private IPs are those listed in
               <http://www.iana.org/assignments/ipv4-address-space>,
               <http://duxcw.com/faq/network/privip.htm>,
               <http://duxcw.com/faq/network/autoip.htm>, or
               <http://tools.ietf.org/html/rfc5735> as private.

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

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

           the 'zone' argument
               This is the root zone of the DNSBL.

               The domain name is considered to be a fully qualified domain
               name (i.e. not subject to DNS resolver's search or default
               domain options).  No trailing period is needed, and will be
               removed if specified.

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

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

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

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

               In addition, you can test all untrusted IP addresses by placing
               '-untrusted' at the end of the set name.   Important note --
               this does NOT include the IP address from the most recent
               'untrusted line', as used in '-firsttrusted' above.  That's
               because we're talking about the trustworthiness of the IP
               address data, not the source header line, here; and in the case
               of the most recent header (the 'firsttrusted'), that data can
               be trusted.  See the Wiki page at
               "http://wiki.apache.org/spamassassin/TrustedRelays" for more
               information on this.

           Selecting just the last external IP
               By using '-lastexternal' at the end of the set name, you can
               select only the external host that connected to your internal
               network, or at least the last external host with a public IP.

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

       header SYMBOLIC_TEST_NAME eval:check_rbl_sub('set', 'sub-test')
           Create a sub-test for 'set'.  If you want to look up a multi-
           meaning zone like relays.osirusoft.com, you can then query the
           results from that zone using the zone ID from the original query.
           The sub-test may either be an IPv4 dotted address for RBLs that
           return multiple A records or a non-negative decimal number to
           specify a bitmask for RBLs that return a single A record containing
           a bitmask of results, a SenderBase test beginning with "sb:", or
           (if none of the preceding options seem to fit) a regular
           expression.

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

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

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

       body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
           Define a body eval test.  See above.

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

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

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

           The 'raw body' of a message is the raw data inside all textual
           parts. The text will be decoded from base64 or quoted-printable
           encoding, but HTML tags and line breaks will still be present.
           Multiline expressions will need to be used to match strings that
           are broken by line breaks.

       rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
           Define a raw-body eval test.  See above.

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

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

       full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
           Define a full message eval test.  See above.

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

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

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

       meta SYMBOLIC_TEST_NAME boolean arithmetic expression
           Can also define an arithmetic expression in terms of other tests,
           with an unhit test having the value "0" and a hit test having a
           nonzero value.  The value of a hit meta test is that of its
           arithmetic expression.  The value of a hit eval test is that
           returned by its method.  The value of a hit header, body, rawbody,
           uri, or full test which has the "multiple" tflag is the number of
           times the test hit.  The value of any other type of hit test is
           "1".

           For example:

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

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

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

       reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ... ]
           Defines the name of a test that should be "reused" during the
           scoring process. If a message has an X-Spam-Status header that
           shows a hit for this rule or any of the old rule names given, a hit
           will be added for this rule when mass-check --reuse is used.
           Examples:

           "reuse SPF_PASS"

           "reuse MY_NET_RULE_V2 MY_NET_RULE_V1"

           The actual logic for reuse tests is done by
           Mail::SpamAssassin::Plugin::Reuse.

       tflags SYMBOLIC_TEST_NAME flags
           Used to set flags on a test. Parameter is a space-separated list of
           flag names or flag name = value pairs.  These flags are used in the
           score-determination back end system for details of the test's
           behaviour.  Please see "bayes_auto_learn" for more information
           about tflag interaction with those systems. The following flags can
           be set:

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

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

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

           learn
               The test requires training before it can be used.

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

           autolearn_force
               The test will be subject to less stringent autolearn
               thresholds.

               Normally, SpamAssassin will require 3 points from the header
               and 3 points from the body to be auto-learned as spam. This
               option keeps the threshold at 6 points total but changes it to
               have no regard to the source of the points.

           multiple
               The test will be evaluated multiple times, for use with meta
               rules.  Only affects header, body, rawbody, uri, and full
               tests.

           maxhits=N
               If multiple is specified, limit the number of hits found to N.
               If the rule is used in a meta that counts the hits (e.g.
               __RULENAME > 5), this is a way to avoid wasted extra work (use
               "tflags multiple maxhits=6").

               For example:

                 uri      __KAM_COUNT_URIS /^./
                 tflags   __KAM_COUNT_URIS multiple maxhits=16
                 describe __KAM_COUNT_URIS A multiple match used to count URIs in a message

                 meta __KAM_HAS_0_URIS (__KAM_COUNT_URIS == 0)
                 meta __KAM_HAS_1_URIS (__KAM_COUNT_URIS >= 1)
                 meta __KAM_HAS_2_URIS (__KAM_COUNT_URIS >= 2)
                 meta __KAM_HAS_3_URIS (__KAM_COUNT_URIS >= 3)
                 meta __KAM_HAS_4_URIS (__KAM_COUNT_URIS >= 4)
                 meta __KAM_HAS_5_URIS (__KAM_COUNT_URIS >= 5)
                 meta __KAM_HAS_10_URIS (__KAM_COUNT_URIS >= 10)
                 meta __KAM_HAS_15_URIS (__KAM_COUNT_URIS >= 15)

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

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

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

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

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

           The values <-99999999999999> and <-99999999999998> have a special
           meaning internally, and should not be used.

ADMINISTRATOR SETTINGS

       These settings differ from the ones above, in that they are considered
       'more privileged' -- even more than the ones in the PRIVILEGED SETTINGS
       section.  No matter what "allow_user_rules" is set to, these can never
       be set from a user's "user_prefs" file when spamc/spamd is being used.
       However, all settings can be used by local programs run directly by the
       user.

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

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

           e.g.

             version_tag myrules1    # version=2.41-myrules1

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

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

       rbl_timeout t [t_min] [zone]       (default: 15 3)
           All DNS queries are made at the beginning of a check and we try to
           read the results at the end.  This value specifies the maximum
           period of time (in seconds) to wait for a DNS query.  If most of
           the DNS queries have succeeded for a particular message, then
           SpamAssassin will not wait for the full period to avoid wasting
           time on unresponsive server(s), but will shrink the timeout
           according to a percentage of queries already completed.  As the
           number of queries remaining approaches 0, the timeout value will
           gradually approach a t_min value, which is an optional second
           parameter and defaults to 0.2 * t.  If t is smaller than t_min, the
           initial timeout is set to t_min.  Here is a chart of queries
           remaining versus the timeout in seconds, for the default 15 second
           / 3 second timeout setting:

             queries left  100%  90%  80%  70%  60%  50%  40%  30%  20%  10%   0%
             timeout        15   14.9 14.5 13.9 13.1 12.0 10.7  9.1  7.3  5.3  3

           For example, if 20 queries are made at the beginning of a message
           check and 16 queries have returned (leaving 20%), the remaining 4
           queries should finish within 7.3 seconds since their query started
           or they will be timed out.  Note that timed out queries are only
           aborted when there is nothing else left for SpamAssassin to do -
           long evaluation of other rules may grant queries additional time.

           If a parameter 'zone' is specified (it must end with a letter,
           which distinguishes it from other numeric parametrs), then the
           setting only applies to DNS queries against the specified DNS
           domain (host, domain or RBL (sub)zone).  Matching is case-
           insensitive, the actual domain may be a subdomain of the specified
           zone.

       util_rb_tld tld1 tld2 ...
           This option allows the addition of new TLDs to the
           RegistrarBoundaries code.  Updates to the list usually happen when
           new versions of SpamAssassin are released, but sometimes it's
           necessary to add in new TLDs faster than a release can occur.  TLDs
           include things like com, net, org, etc.

       util_rb_2tld 2tld-1.tld 2tld-2.tld ...
           This option allows the addition of new 2nd-level TLDs (2TLD) to the
           RegistrarBoundaries code.  Updates to the list usually happen when
           new versions of SpamAssassin are released, but sometimes it's
           necessary to add in new 2TLDs faster than a release can occur.
           2TLDs include things like co.uk, fed.us, etc.

       util_rb_3tld 3tld1.some.tld 3tld2.other.tld ...
           This option allows the addition of new 3rd-level TLDs (3TLD) to the
           RegistrarBoundaries code.  Updates to the list usually happen when
           new versions of SpamAssassin are released, but sometimes it's
           necessary to add in new 3TLDs faster than a release can occur.
           3TLDs include things like demon.co.uk, plc.co.im, etc.

       bayes_path /path/filename     (default: ~/.spamassassin/bayes)
           This is the directory and filename for Bayes databases.  Several
           databases will be created, with this as the base directory and
           filename, with "_toks", "_seen", etc. appended to the base.  The
           default setting results in files called
           "~/.spamassassin/bayes_seen", "~/.spamassassin/bayes_toks", etc.

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

       bayes_file_mode          (default: 0700)
           The file mode bits used for the Bayesian filtering database files.

           Make sure you specify this using the 'x' mode bits set, as it may
           also be used to create directories.  However, if a file is created,
           the resulting file will not have any execute bits set (the umask is
           set to 111). The argument is a string of octal digits, it is
           converted to a numeric value internally.

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

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

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

       bayes_sql_username
           Used by BayesStore::SQL storage implementation.

           This option gives the username used by the above DSN.

       bayes_sql_password
           Used by BayesStore::SQL storage implementation.

           This option gives the password used by the above DSN.

       bayes_sql_username_authorized ( 0 | 1 )  (default: 0)
           Whether to call the services_authorized_for_username plugin hook in
           BayesSQL.  If the hook does not determine that the user is allowed
           to use bayes or is invalid then the database will not be
           initialized.

           NOTE: By default the user is considered invalid until a plugin
           returns a true value.  If you enable this, but do not have a proper
           plugin loaded, all users will turn up as invalid.

           The username passed into the plugin can be affected by the
           bayes_sql_override_username config option.

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

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

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

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

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

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

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

           _USERNAME_
               The current user's username.

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

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

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

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

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

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

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

       user_scores_ldap_username
           This is the Bind DN used to connect to the LDAP server.  It
           defaults to the empty string (""), allowing anonymous binding to
           work.

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

       user_scores_ldap_password
           This is the password used to connect to the LDAP server.  It
           defaults to the empty string ("").

       user_scores_fallback_to_global        (default: 1)
           Fall back to global scores and settings if userprefs can't be
           loaded from SQL or LDAP, instead of passing the message through
           unprocessed.

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

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

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

       tryplugin PluginModuleName [/path/module.pm]
           Same as "loadplugin", but silently ignored if the .pm file cannot
           be found in the filesystem.

       ignore_always_matching_regexps         (Default: 0)
           Ignore any rule which contains a regexp which always matches.
           Currently only catches regexps which contain '||', or which begin
           or end with a '|'.  Also ignore rules with "some" combinatorial
           explosions.

PREPROCESSING OPTIONS

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

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

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

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

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

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

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

           has(Name::Of::Package::function_name)
               This is a function call that returns 1 if the perl package
               named "Name::Of::Package" includes a function called
               "function_name", or "undef" otherwise.  Note that packages can
               be SpamAssassin plugins or built-in classes, there's no
               difference in this respect.  Internally this invokes
               UNIVERSAL::can.

           can(Name::Of::Package::function_name)
               This is a function call that returns 1 if the perl package
               named "Name::Of::Package" includes a function called
               "function_name" and that function returns a true value when
               called with no arguments, otherwise "undef" is returned.

               Is similar to "has", except that it also calls the named
               function, testing its return value (unlike the perl function
               UNIVERSAL::can).  This makes it possible for a 'feature'
               function to determine its result value at run time.

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

           For example:

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

                   loadplugin MyPlugin plugintest.pm

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

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

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

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

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

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')
        _RELAYSTRUSTED_   relays used and deemed to be trusted (see the
                          'X-Spam-Relays-Trusted' pseudo-header)
        _RELAYSUNTRUSTED_ relays used that can not be trusted (see the
                          'X-Spam-Relays-Untrusted' pseudo-header)
        _RELAYSINTERNAL_  relays used and deemed to be internal (see the
                          'X-Spam-Relays-Internal' pseudo-header)
        _RELAYSEXTERNAL_  relays used and deemed to be external (see the
                          'X-Spam-Relays-External' pseudo-header)
        _LASTEXTERNALIP_  IP address of client in the external-to-internal
                          SMTP handover
        _LASTEXTERNALRDNS_ reverse-DNS of client in the external-to-internal
                          SMTP handover
        _LASTEXTERNALHELO_ HELO string used by client in the external-to-internal
                          SMTP handover
        _AUTOLEARN_       autolearn status ("ham", "no", "spam", "disabled",
                          "failed", "unavailable")
        _AUTOLEARNSCORE_  portion of message score used by autolearn
        _TESTS(,)_        tests hit separated by "," (or other separator)
        _TESTSSCORES(,)_  as above, except with scores appended (eg. AWL=-3.0,...)
        _SUBTESTS(,)_     subtests (start with "__") hit separated by ","
                          (or other separator)
        _DCCB_            DCC's "Brand"
        _DCCR_            DCC's results
        _PYZOR_           Pyzor results
        _RBL_             full results for positive RBL queries in DNS URI format
        _LANGUAGES_       possible languages of mail
        _PREVIEW_         content preview
        _REPORT_          terse report of tests hit (for header reports)
        _SUMMARY_         summary of tests hit for standard report (for body reports)
        _CONTACTADDRESS_  contents of the 'report_contact' setting
        _HEADER(NAME)_    includes the value of a message header.  value is the same
                          as is found for header rules (see elsewhere in this doc)
        _TIMING_          timing breakdown report
        _ADDEDHEADERHAM_  resulting header fields as requested by add_header for spam
        _ADDEDHEADERSPAM_ resulting header fields as requested by add_header for ham
        _ADDEDHEADER_     same as ADDEDHEADERHAM for ham or ADDEDHEADERSPAM for spam

       If a tag reference uses the name of a tag which is not in this list or
       defined by a loaded plugin, the reference will be left intact and not
       replaced by any value.

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

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

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

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

           Results in message header:

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

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

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

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

           Results in message header:

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

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

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

           For example, preference file entry:

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

           Results in message header:

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

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

LOCALI[SZ]ATION

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

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

SEE ALSO

       "Mail::SpamAssassin" "spamassassin" "spamd"



  All copyrights belong to their respective owners. Other content (c) 2014-2018, GNU.WIKI. Please report site errors to webmaster@gnu.wiki.
Page load time: 0.118 seconds. Last modified: November 04 2018 12:49:43.