You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by km...@apache.org on 2020/01/29 19:06:00 UTC
svn commit: r1873332 [5/17] - in /spamassassin/site/full/3.4.x: ./ doc/
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt?rev=1873332&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.txt Wed Jan 29 19:05:59 2020
@@ -0,0 +1,2408 @@
+NAME
+ Mail::SpamAssassin::Conf - SpamAssassin configuration file
+
+SYNOPSIS
+ # a comment
+
+ rewrite_header Subject *****SPAM*****
+
+ full PARA_A_2_C_OF_1618 /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
+ describe PARA_A_2_C_OF_1618 Claims compliance with senate bill 1618
+
+ header FROM_HAS_MIXED_NUMS From =~ /\d+[a-z]+\d+\S*@/i
+ describe FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
+
+ score A_HREF_TO_REMOVE 2.0
+
+ lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com
+
+ lang pt_BR report O programa detetor de Spam ZOE [...]
+
+DESCRIPTION
+ SpamAssassin is configured using traditional UNIX-style configuration
+ files, loaded from the "/usr/share/spamassassin" and
+ "/etc/mail/spamassassin" directories.
+
+ The following web page lists the most important configuration settings
+ used to configure SpamAssassin; novices are encouraged to read it first:
+
+ 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.
+
+ Test names ("SYMBOLIC_TEST_NAME") can only contain
+ alphanumerics/underscores, can not start with digit, and must be less
+ than 128 characters.
+
+USER PREFERENCES
+ The following options can be used in both site-wide ("local.cf") and
+ user-specific ("user_prefs") configuration files to customize how
+ SpamAssassin handles incoming email messages.
+
+ SCORING OPTIONS
+ required_score n.nn (default: 5)
+ Set the score required before a mail is considered spam. "n.nn" can
+ be an integer or a real number. 5.0 is the default setting, and is
+ quite aggressive; it would be suitable for a single-user setup, but
+ if you're an ISP installing SpamAssassin, you should probably set
+ the default to be more conservative, like 8.0 or 10.0. It is not
+ recommended to automatically delete or discard messages marked as
+ spam, as your users will complain, but if you choose to do so, only
+ delete messages with an exceptionally high score such as 15.0 or
+ higher. This option was previously known as "required_hits" and that
+ name is still accepted, but is deprecated.
+
+ score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]
+ Assign scores (the number of points for a hit) to a given test.
+ Scores can be positive or negative real numbers or integers.
+ "SYMBOLIC_TEST_NAME" is the symbolic name used by SpamAssassin for
+ that test; for example, 'FROM_ENDS_IN_NUMS'.
+
+ If only one valid score is listed, then that score is always used
+ for a test.
+
+ If four valid scores are listed, then the score that is used depends
+ on how SpamAssassin is being used. The first score is used when both
+ Bayes and network tests are disabled (score set 0). The second score
+ is used when Bayes is disabled, but network tests are enabled (score
+ set 1). The third score is used when Bayes is enabled and network
+ tests are disabled (score set 2). The fourth score is used when
+ Bayes is enabled and network tests are enabled (score set 3).
+
+ Setting a rule's score to 0 will disable that rule from running.
+
+ If any of the score values are surrounded by parenthesis '()', then
+ all of the scores in the line are considered to be relative to the
+ already set score. ie: '(3)' means increase the score for this rule
+ by 3 points in all score sets. '(3) (0) (3) (0)' means increase the
+ score for this rule by 3 in score sets 0 and 2 only.
+
+ If no score is given for a test by the end of the configuration, a
+ default score is assigned: a score of 1.0 is used for all tests,
+ except those whose names begin with 'T_' (this is used to indicate a
+ rule in testing) which receive 0.01.
+
+ Note that test names which begin with '__' are indirect rules used
+ to compose meta-match rules and can also act as prerequisites to
+ other rules. They are not scored or listed in the 'tests hit'
+ reports, but assigning a score of 0 to an indirect rule will disable
+ it from running.
+
+ 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 a TCP-info information
+ field as provided in a FROM clause of a trace information (i.e. in a
+ Received header field, see RFC 5321). Only the Received header
+ fields inserted by trusted hosts are considered. This parameter can
+ either be a full hostname, or a domain component of that hostname,
+ or an IP address (optionally followed by a slash and a prefix
+ length) in square brackets. The address prefix (mask) length with a
+ slash may stand within brackets along with an address, or may follow
+ the bracketed address. Reverse DNS lookup is done by an MTA, not by
+ SpamAssassin.
+
+ For backward compatibility as an alternative to a CIDR notation, an
+ IPv4 address in brackets may be truncated on classful boundaries to
+ cover whole subnets, e.g. "[10.1.2.3]", "[10.1.2]", "[10.1]",
+ "[10]".
+
+ In other words, if the host that connected to your MX had an IP
+ address 192.0.2.123 that mapped to 'sendinghost.example.org', you
+ should specify "sendinghost.example.org", or "example.org", or
+ "[192.0.2.123]", or "[192.0.2.0/24]", or "[192.0.2]" here.
+
+ Note that this requires that "internal_networks" be correct. For
+ simple cases, it will be, but for a complex network you may get
+ better results by setting that parameter.
+
+ It also requires that your mail exchangers be configured to perform
+ DNS reverse lookups on the connecting host's IP address, and to
+ record the result in the generated Received header field according
+ to RFC 5321.
+
+ e.g.
+
+ whitelist_from_rcvd joe@example.com example.com
+ whitelist_from_rcvd *@* mail.example.org
+ whitelist_from_rcvd *@axkit.org [192.0.2.123]
+ whitelist_from_rcvd *@axkit.org [192.0.2.0/24]
+ whitelist_from_rcvd *@axkit.org [192.0.2.0]/24
+ whitelist_from_rcvd *@axkit.org [2001:db8:1234::/48]
+ whitelist_from_rcvd *@axkit.org [2001:db8:1234::]/48
+
+ 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 exclamation mark '!',
+ which produces false as a result if this entry matches. This makes
+ it easier to exclude some subdomains when their superdomain is
+ listed, for example:
+
+ enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com
+
+ No wildcards are supported, but subdomains do match implicitly.
+ Lists are independent. Search for each named list starts by looking
+ up the full hostname first, then leading fields are progressively
+ stripped off (e.g.: sub.example.com, example.com, com) until a match
+ is found or we run out of fields. The first matching entry (the most
+ specific) determines if a lookup yielded a true (no '!' prefix) or a
+ false (with a '!' prefix) result.
+
+ If an URL found in a message contains an IP address in place of a
+ host name, the given list must specify the exact same IP address
+ (instead of a host name) in order to match.
+
+ Use the delist_uri_host directive to neutralize previous
+ enlist_uri_host settings.
+
+ Enlisting to lists named '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.
+
+ enlist_addrlist (listname) user@example.com
+ Adds one or more addresses to a named list of addresses. The named
+ list can then be consulted through a check_from_in_list() or a
+ check_to_in_list() eval rule implemented by the WLBLEval plugin,
+ which takes the list name as an argument. Parenthesis around a list
+ name are literal - a required syntax.
+
+ Listed addresses are file-glob-style patterns, so
+ "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all
+ work. Specifically, "*" and "?" are allowed, but all other
+ metacharacters are not. Regular expressions are not used for
+ security reasons. Matching is case-insensitive.
+
+ Multiple addresses per line, separated by spaces, is OK. Multiple
+ "enlist_addrlist" lines are also OK.
+
+ Enlisting an address to the list named blacklist_to is synonymous to
+ using the directive blacklist_to
+
+ Enlisting an address to the list named blacklist_from is synonymous
+ to using the directive blacklist_from
+
+ Enlisting an address to the list named whitelist_to is synonymous to
+ using the directive whitelist_to
+
+ Enlisting an address to the list named whitelist_from is synonymous
+ to using the directive whitelist_from
+
+ e.g.
+
+ enlist_addrlist (PAYPAL_ADDRESS) service@paypal.com
+ enlist_addrlist (PAYPAL_ADDRESS) *@paypal.co.uk
+
+ 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 parentheses. For the
+ Subject header, this will be prepended to the original subject. Note
+ that you should only use the _REQD_ and _SCORE_ tags when rewriting
+ the Subject header if "report_safe" is 0. Otherwise, you may not be
+ able to remove the SpamAssassin markup via the normal methods. More
+ information about tags is explained below in the TEMPLATE TAGS
+ section.
+
+ Parentheses are not permitted in STRING if rewriting the From or To
+ headers. (They will be converted to square brackets.)
+
+ If "rewrite_header subject" is used, but the message being rewritten
+ does not already contain a "Subject" header, one will be created.
+
+ A null value for "STRING" will remove any existing rewrite for the
+ specified header.
+
+ subjprefix
+ Add a prefix in emails Subject if a rule is matched. To enable this
+ option "rewrite_header Subject" config option must be enabled as
+ well.
+
+ The check "if can(Mail::SpamAssassin::Conf::feature_subjprefix)"
+ should be used to silence warnings in previous SpamAssassin
+ versions.
+
+ To be able to use this feature a "add_header all Subjprefix
+ _SUBJPREFIX_" configuration line could be needed on some setups.
+
+ add_header { spam | ham | all } header_name string
+ Customized headers can be added to the specified type of messages
+ (spam, ham, or "all" to add to either). All headers begin with
+ "X-Spam-" (so a "header_name" Foo will generate a header called
+ X-Spam-Foo). header_name is restricted to the character set
+ [A-Za-z0-9_-].
+
+ The order of "add_header" configuration options is preserved,
+ inserted headers will follow this order of declarations. When
+ combining "add_header" with "clear_headers" and "remove_header",
+ keep in mind that "add_header" appends a new header to the current
+ list, after first removing any existing header fields of the same
+ name. Note also that "add_header", "clear_headers" and
+ "remove_header" may appear in multiple .cf files, which are
+ interpreted in alphabetic order.
+
+ "string" can contain tags as explained below in the TEMPLATE TAGS
+ section. You can also use "\n" and "\t" in the header to add
+ newlines and tabulators as desired. A backslash has to be written as
+ \\, any other escaped chars will be silently removed.
+
+ All headers will be folded if fold_headers is set to 1. Note:
+ Manually adding newlines via "\n" disables any further automatic
+ wrapping (ie: long header lines are possible). The lines will still
+ be properly folded (marked as continuing) though.
+
+ You can customize existing headers with add_header (only the
+ specified subset of messages will be changed).
+
+ See also "clear_headers" and "remove_header" for removing headers.
+
+ Here are some examples (these are the defaults, note that
+ Checker-Version can not be changed or removed):
+
+ add_header spam Flag _YESNOCAPS_
+ add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
+ add_header all Level _STARS(*)_
+ add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_
+
+ remove_header { spam | ham | all } header_name
+ Headers can be removed from the specified type of messages (spam,
+ ham, or "all" to remove from either). All headers begin with
+ "X-Spam-" (so "header_name" will be appended to "X-Spam-").
+
+ See also "clear_headers" for removing all the headers at once.
+
+ Note that X-Spam-Checker-Version is not removable because the
+ version information is needed by mail administrators and developers
+ to debug problems. Without at least one header, it might not even be
+ possible to determine that SpamAssassin is running.
+
+ clear_headers
+ Clear the list of headers to be added to messages. You may use this
+ before any add_header options to prevent the default headers from
+ being added to the message.
+
+ "add_header", "clear_headers" and "remove_header" may appear in
+ multiple .cf files, which are interpreted in alphabetic order, so
+ "clear_headers" in a later file will remove all added headers from
+ previously interpreted configuration files, which may or may not be
+ desired.
+
+ Note that X-Spam-Checker-Version is not removable because the
+ version information is needed by mail administrators and developers
+ to debug problems. Without at least one header, it might not even be
+ possible to determine that SpamAssassin is running.
+
+ report_safe ( 0 | 1 | 2 ) (default: 1)
+ if this option is set to 1, if an incoming message is tagged as
+ spam, instead of modifying the original message, SpamAssassin will
+ create a new report message and attach the original message as a
+ message/rfc822 MIME part (ensuring the original message is
+ completely preserved, not easily opened, and easier to recover).
+
+ If this option is set to 2, then original messages will be attached
+ with a content type of text/plain instead of message/rfc822. This
+ setting may be required for safety reasons on certain broken mail
+ clients that automatically load attachments without any action by
+ the user. This setting may also make it somewhat more difficult to
+ extract or view the original message.
+
+ If this option is set to 0, incoming spam is only modified by adding
+ some "X-Spam-" headers and no changes will be made to the body. In
+ addition, a header named X-Spam-Report will be added to spam. You
+ can use the remove_header option to remove that header after setting
+ report_safe to 0.
+
+ See report_safe_copy_headers if you want to copy headers from the
+ original mail into tagged messages.
+
+ report_wrap_width (default: 70)
+ This option sets the wrap width for description lines in the
+ X-Spam-Report header, not accounting for tab width.
+
+ LANGUAGE OPTIONS
+ ok_locales xx [ yy zz ... ] (default: all)
+ This option is used to specify which locales are considered OK for
+ incoming mail. Mail using the character sets that are allowed by
+ this option will not be marked as possibly being spam in a foreign
+ language.
+
+ If you receive lots of spam in foreign languages, and never get any
+ non-spam in these languages, this may help. Note that all ISO-8859-*
+ character sets, and Windows code page character sets, are always
+ permitted by default.
+
+ Set this to "all" to allow all character sets. This is the default.
+
+ The rules "CHARSET_FARAWAY", "CHARSET_FARAWAY_BODY", and
+ "CHARSET_FARAWAY_HEADERS" are triggered based on how this is set.
+
+ Examples:
+
+ ok_locales all (allow all locales)
+ ok_locales en (only allow English)
+ ok_locales en ja zh (allow English, Japanese, and Chinese)
+
+ Note: if there are multiple ok_locales lines, only the last one is
+ used.
+
+ Select the locales to allow from the list below:
+
+ en - Western character sets in general
+ ja - Japanese character sets
+ ko - Korean character sets
+ ru - Cyrillic character sets
+ th - Thai character sets
+ zh - Chinese (both simplified and traditional) character sets
+
+ normalize_charset ( 0 | 1) (default: 0)
+ Whether to decode non- UTF-8 and non-ASCII textual parts and recode
+ them to UTF-8 before the text is given over to rules processing. The
+ character set used for attempted decoding is primarily based on a
+ declared character set in a Content-Type header, but if the decoding
+ attempt fails a module Encode::Detect::Detector is consulted (if
+ available) to provide a guess based on the actual text, and decoding
+ is re-attempted. Even if the option is enabled no unnecessary
+ decoding and re-encoding work is done when possible (like with an
+ all-ASCII text with a US-ASCII or extended ASCII character set
+ declaration, e.g. UTF-8 or ISO-8859-nn or Windows-nnnn).
+
+ Unicode support in old versions of perl or in a core module Encode
+ is likely to be buggy in places, so if the normalize_charset
+ function is enabled it is advised to stick to more recent versions
+ of perl (preferably 5.12 or later). The module
+ Encode::Detect::Detector is optional, when necessary it will be used
+ if it is available.
+
+ body_part_scan_size (default: 50000)
+ Per mime-part scan size limit in bytes for "body" type rules. The
+ decoded/stripped mime-part is truncated approx to this size. Helps
+ scanning large messages safely, so it's not necessary to skip them
+ completely. Disabled with 0.
+
+ rawbody_part_scan_size (default: 500000)
+ Like body_part_scan_size, for "rawbody" type rules.
+
+ 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 regardless of the search algorithm used - when
+ Net::Patricia module is installed the search finds the tightest
+ matching entry in the list, while a sequential search as used in
+ absence of the module Net::Patricia will find the first matching
+ entry in the list.
+
+ Note: 127.0.0.0/8 and ::1 are always included in trusted_networks,
+ regardless of your config.
+
+ Examples:
+
+ trusted_networks 192.168.0.0/16 # all in 192.168.*.*
+ trusted_networks 192.168. # all in 192.168.*.*
+ trusted_networks 212.17.35.15 # just that host
+ trusted_networks !10.0.1.5 10.0.1/24 # all in 10.0.1.* but not 10.0.1.5
+ trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
+ # 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64
+
+ This operates additively, so a "trusted_networks" line after another
+ one will append new entries to the list of trusted networks. To
+ clear out the existing entries, use "clear_trusted_networks".
+
+ If "trusted_networks" is not set and "internal_networks" is, the
+ value of "internal_networks" will be used for this parameter.
+
+ If neither "trusted_networks" or "internal_networks" is set, a basic
+ inference algorithm is applied. This works as follows:
+
+ * 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. A scoped link-local
+ IP address is allowed (assuming underlying modules allow it).
+
+ Examples : dns_server 127.0.0.1 dns_server 127.0.0.1:53 dns_server
+ [127.0.0.1]:53 dns_server [::1]:53 dns_server fe80::1%lo0 dns_server
+ [fe80::1%lo0]:53
+
+ In absence of *dns_server* directives, the list of name servers is
+ provided by Net::DNS module, which typically obtains the list from
+ /etc/resolv.conf, but this may be platform dependent. Please consult
+ the Net::DNS::Resolver documentation for details.
+
+ clear_dns_servers
+ Empty the list of explicitly configured DNS servers through a
+ *dns_server* directive, falling back to Net::DNS -supplied defaults.
+
+ dns_local_ports_permit ranges...
+ Add the specified ports or ports ranges to the set of allowed port
+ numbers that can be used as local port numbers when sending DNS
+ queries to a resolver.
+
+ The argument is a whitespace-separated or a comma-separated list of
+ single port numbers n, or port number pairs (i.e. m-n) delimited by
+ a '-', representing a range. Allowed port numbers are between 1 and
+ 65535.
+
+ Directives *dns_local_ports_permit* and *dns_local_ports_avoid* are
+ processed in order in which they appear in configuration files. Each
+ directive adds (or subtracts) its subsets of ports to a current set
+ of available ports. Whatever is left in the set by the end of
+ configuration processing is made available to a DNS resolving client
+ code.
+
+ If the resulting set of port numbers is empty (see also the
+ directive *dns_local_ports_none*), then SpamAssassin does not apply
+ its ports randomization logic, but instead leaves the operating
+ system to choose a suitable free local port number.
+
+ The initial set consists of all port numbers in the range
+ 1024-65535. Note that system config files already modify the set and
+ remove all the IANA registered port numbers and some other ranges,
+ so there is rarely a need to adjust the ranges by site-specific
+ directives.
+
+ See also directives *dns_local_ports_permit* and
+ *dns_local_ports_none*.
+
+ dns_local_ports_avoid ranges...
+ Remove specified ports or ports ranges from the set of allowed port
+ numbers that can be used as local port numbers when sending DNS
+ queries to a resolver.
+
+ Please see directive *dns_local_ports_permit* for details.
+
+ dns_local_ports_none
+ Is a fast shorthand for:
+
+ dns_local_ports_avoid 1-65535
+
+ leaving the set of available DNS query local port numbers empty. In
+ all respects (apart from speed) it is equivalent to the shown
+ directive, and can be freely mixed with *dns_local_ports_permit* and
+ *dns_local_ports_avoid*.
+
+ If the resulting set of port numbers is empty, then SpamAssassin
+ does not apply its ports randomization logic, but instead leaves the
+ operating system to choose a suitable free local port number.
+
+ See also directives *dns_local_ports_permit* and
+ *dns_local_ports_avoid*.
+
+ dns_test_interval n (default: 600 seconds)
+ If dns_available is set to *test*, the dns_test_interval time in
+ number of seconds will tell SpamAssassin how often to retest for
+ working DNS. A numeric value is optionally suffixed by a time unit
+ (s, m, h, d, w, indicating seconds (default), minutes, hours, days,
+ weeks).
+
+ dns_options opts (default: 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_token_sources (default: header visible invisible uri)
+ Controls which sources in a mail message can contribute tokens (e.g.
+ words, phrases, etc.) to a Bayes classifier. The argument is a
+ space-separated list of keywords: *header*, *visible*, *invisible*,
+ *uri*, *mimepart*), each of which may be prefixed by a *no* to
+ indicate its exclusion. Additionally two reserved keywords are
+ allowed: *all* and *none* (or: *noall*). The list of keywords is
+ processed sequentially: a keyword *all* adds all available keywords
+ to a set being built, a *none* or *noall* clears the set, other
+ non-negated keywords are added to the set, and negated keywords are
+ removed from the set. Keywords are case-insensitive.
+
+ The default set is: *header* *visible* *invisible* *uri*, which is
+ equivalent for example to: *All* *NoMIMEpart*. The reason why
+ *mimepart* is not currently in a default set is that it is a newer
+ source (introduced with SpamAssassin version 3.4.1) and not much
+ experience has yet been gathered regarding its usefulness.
+
+ See also option "bayes_ignore_header" for a fine-grained control on
+ individual header fields under the umbrella of a more general
+ keyword *header* here.
+
+ Keywords imply the following data sources:
+
+ *header* - tokens collected from a message header section
+ *visible* - words from visible text (plain or HTML) in a message
+ body
+ *invisible* - hidden/invisible text in HTML parts of a message body
+ *uri* - URIs collected from a message body
+ *mimepart* - digests (hashes) of all MIME parts (textual or
+ non-textual) of a message, computed after Base64 and
+ quoted-printable decoding, suffixed by their Content-Type
+ *all* - adds all the above keywords to the set being assembled
+ *none* or *noall* - removes all keywords from the set
+
+ The "bayes_token_sources" directive may appear multiple times, its
+ keywords are interpreted sequentially, adding or removing items from
+ the final set as they appear in their order in "bayes_token_sources"
+ directive(s).
+
+ bayes_ignore_header header_name
+ If you receive mail filtered by upstream mail systems, like a
+ spam-filtering ISP or mailing list, and that service adds new
+ headers (as most of them do), these headers may provide
+ inappropriate cues to the Bayesian classifier, allowing it to take a
+ "short cut". To avoid this, list the headers using this setting.
+ 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})/
+
+ parse_dkim_uris ( 0 | 1 ) (default: 1)
+ If this option is set to 1 and the message contains DKIM headers,
+ the headers will be parsed for URIs to process alongside URIs found
+ in the body with some rules and modules (ex. URIDNSBL)
+
+RULE DEFINITIONS AND PRIVILEGED SETTINGS
+ These settings differ from the ones above, in that they are considered
+ 'privileged'. Only users running "spamassassin" from their procmailrc's
+ or forward files, or sysadmins editing a file in
+ "/etc/mail/spamassassin", can use them. "spamd" users cannot use them in
+ their "user_prefs" files, for security and efficiency reasons, unless
+ "allow_user_rules" is enabled (and then, they may only add rules from
+ below).
+
+ allow_user_rules ( 0 | 1 ) (default: 0)
+ This setting allows users to create rules (and only rules) in their
+ "user_prefs" files for use with "spamd". It defaults to off, because
+ this could be a severe security hole. It may be possible for users
+ to gain root level access if "spamd" is run as root. It is NOT a
+ good idea, unless you have some other way of ensuring that users'
+ tests are safe. Don't use this unless you are certain you know what
+ you are doing. Furthermore, this option causes spamassassin to
+ recompile all the tests each time it processes a message for a user
+ with a rule in his/her "user_prefs" file, which could have a
+ significant effect on server load. It is not recommended.
+
+ Note that it is not currently possible to use "allow_user_rules" to
+ modify an existing system rule from a "user_prefs" file with
+ "spamd".
+
+ redirector_pattern /pattern/modifiers
+ A regex pattern that matches both the redirector site portion, and
+ the target site portion of a URI.
+
+ Note: The target URI portion must be surrounded in parentheses and
+ no other part of the pattern may create a backreference.
+
+ Example:
+ http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude
+
+ redirector_pattern /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i
+
+ header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset:
+ STRING]
+ Define a test. "SYMBOLIC_TEST_NAME" is a symbolic test name, such as
+ 'FROM_ENDS_IN_NUMS'. "header" is the name of a mail header field,
+ such as 'Subject', 'To', 'From', etc. Header field names are matched
+ case-insensitively (conforming to RFC 5322 section 1.2.2), except
+ for all-capitals metaheader fields such as ALL, MESSAGEID,
+ ALL-TRUSTED.
+
+ Appending a modifier ":raw" to a header field name will inhibit
+ decoding of quoted-printable or base-64 encoded strings, and will
+ preserve all whitespace inside the header string. The ":raw" may
+ also be applied to pseudo-headers e.g. "ALL:raw" will return a
+ pristine (unmodified) header section.
+
+ Appending a modifier ":addr" to a header field name will cause
+ everything except the first email address to be removed from the
+ header field. It is mainly applicable to header fields 'From',
+ 'Sender', 'To', 'Cc' along with their 'Resent-*' counterparts, and
+ the 'Return-Path'.
+
+ Appending a modifier ":name" to a header field name will cause
+ everything except the first display name to be removed from the
+ header field. It is mainly applicable to header fields containing a
+ single mail address: 'From', 'Sender', along with their
+ 'Resent-From' and 'Resent-Sender' counterparts.
+
+ It is syntactically permitted to append more than one modifier to a
+ header field name, although currently most combinations achieve no
+ additional effect, for example "From:addr:raw" or "From:raw:addr" is
+ currently the same as "From:addr" .
+
+ For example, appending ":addr" to a header name will result in
+ example@foo in all of the following cases:
+
+ example@foo
+ example@foo (Foo Blah)
+ example@foo, example@bar
+ display: example@foo (Foo Blah), example@bar ;
+ Foo Blah <ex...@foo>
+ "Foo Blah" <ex...@foo>
+ "'Foo Blah'" <ex...@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 <ex...@foo>
+ "Foo Blah" <ex...@foo>
+ "'Foo Blah'" <ex...@foo>
+
+ There are several special pseudo-headers that can be specified:
+
+ "ALL" can be used to mean the text of all the message's headers.
+ Note that all whitespace inside the headers, at line folds, is
+ currently compressed into a single space (' ') character. To obtain
+ a pristine (unmodified) header section, use "ALL:raw" - the :raw
+ modifier is documented above. Also similar that return headers added
+ by specific relays: ALL-TRUSTED, ALL-INTERNAL, ALL-UNTRUSTED,
+ ALL-EXTERNAL.
+ "ToCc" can be used to mean the contents of both the 'To' and 'Cc'
+ headers.
+ "EnvelopeFrom" is the address used in the 'MAIL FROM:' phase of the
+ SMTP transaction that delivered this message, if this data has been
+ made available by the SMTP server. See "envelope_sender_header" for
+ more information on how to set this.
+ "MESSAGEID" is a symbol meaning all Message-Id's found in the
+ message; some mailing list software moves the real 'Message-Id' to
+ 'Resent-Message-Id' or to 'X-Message-Id', then uses its own one in
+ the 'Message-Id' header. The value returned for this symbol is the
+ text from all 3 headers, separated by newlines.
+ "X-Spam-Relays-Untrusted", "X-Spam-Relays-Trusted",
+ "X-Spam-Relays-Internal" and "X-Spam-Relays-External" represent a
+ portable, pre-parsed representation of the message's network path,
+ as recorded in the Received headers, divided into 'trusted' vs
+ 'untrusted' and 'internal' vs 'external' sets. See
+ "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 header specified matches multiple headers, their text will be
+ concatenated with embedded \n's. Therefore you may wish to use "/m"
+ if you use "^" or "$" in your regular expression.
+
+ If the "[if-unset: STRING]" tag is present, then "STRING" will be
+ used if the header is not found in the mail message.
+
+ Test names must not start with a number, and must contain only
+ alphanumerics and underscores. It is suggested that lower-case
+ characters not be used, and names have a length of no more than 22
+ characters, as an informal convention. Dashes are not allowed.
+
+ Note that test names which begin with '__' are reserved for
+ meta-match sub-rules, and are not scored or listed in the 'tests
+ hit' reports. Test names which begin with 'T_' are reserved for
+ tests which are undergoing QA, and these are given a very low score.
+
+ If you add or modify a test, please be sure to run a sanity check
+ afterwards by running "spamassassin --lint". This will avoid
+ confusing error messages, or other tests being skipped as a
+ side-effect.
+
+ header SYMBOLIC_TEST_NAME exists:header_field_name
+ Define a header field existence test. "header_field_name" is the
+ name of a header field to test for existence. Not to be confused
+ with a test for a nonempty header field body, which can be
+ implemented by a "header SYMBOLIC_TEST_NAME header =~ /\S/" rule as
+ described above.
+
+ header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])
+ Define a header eval test. "name_of_eval_method" is the name of a
+ method registered by a "Mail::SpamAssassin::Plugin" object.
+ "arguments" are optional arguments to the function call.
+
+ header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone' [, 'sub-test'])
+ Check a DNSBL (a DNS 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
+ <https://www.iana.org/assignments/ipv4-address-space>,
+ <http://duxcw.com/faq/network/privip.htm>,
+ <http://duxcw.com/faq/network/autoip.htm>, or
+ <https://tools.ietf.org/html/rfc5735> as private.
+
+ the 'set' argument
+ This is used as a 'zone ID'. If you want to look up a
+ multiple-meaning zone like SORBS, you can then query the results
+ from that zone using it; but all check_rbl_sub() calls must use
+ that zone ID.
+
+ Also, if more than one IP address gets a DNSBL hit for a
+ particular rule, it does not affect the score because rules only
+ trigger once per message.
+
+ the 'zone' argument
+ This is the root zone of the DNSBL.
+
+ The domain name is considered to be a fully qualified domain
+ name (i.e. not subject to DNS resolver's search or default
+ domain options). No trailing period is needed, and will be
+ removed if specified.
+
+ the 'sub-test' argument
+ This optional argument behaves the same as the sub-test argument
+ in "check_rbl_sub()" below.
+
+ selecting all IPs except for the originating one
+ This is accomplished by placing '-notfirsthop' at the end of the
+ set name. This is useful for querying against DNS lists which
+ list dialup IP addresses; the first hop may be a dialup, but as
+ long as there is at least one more hop, via their outgoing SMTP
+ server, that's legitimate, and so should not gain points. If
+ there is only one hop, that will be queried anyway, as it should
+ be relaying via its outgoing SMTP server instead of sending
+ directly to your MX (mail exchange).
+
+ selecting IPs by whether they are trusted
+ When checking a 'nice' DNSBL (a DNS 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,
+ or a regular expression.
+
+ Note: the set name must be exactly the same for as the main query
+ rule, including selections like '-notfirsthop' appearing at the end
+ of the set name.
+
+ body SYMBOLIC_TEST_NAME /pattern/modifiers
+ Define a body pattern test. "pattern" is a Perl regular expression.
+ Note: as per the header tests, "#" must be escaped ("\#") or else it
+ is considered the beginning of a comment.
+
+ The 'body' in this case is the textual parts of the message body;
+ any non-text MIME parts are stripped, and the message decoded from
+ Quoted-Printable or Base-64-encoded format if necessary. Parts
+ declared as text/html will be rendered from HTML to text.
+
+ All body paragraphs (double-newline-separated blocks text) are
+ turned into a line breaks removed, whitespace normalized single
+ line. Any lines longer than 2kB are split into shorter separate
+ lines (from a boundary when possible), this may unexpectedly prevent
+ pattern from matching. Patterns are matched independently against
+ each of these lines.
+
+ Note that by default the message Subject header is considered part
+ of the body and becomes the first line when running the rules. If
+ you don't want to match Subject along with body text, use "tflags
+ RULENAME nosubject".
+
+ body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
+ Define a body eval test. See above.
+
+ uri SYMBOLIC_TEST_NAME /pattern/modifiers
+ Define a uri pattern test. "pattern" is a Perl regular expression.
+ Note: as per the header tests, "#" must be escaped ("\#") or else it
+ is considered the beginning of a comment.
+
+ The 'uri' in this case is a list of all the URIs in the body of the
+ email, and the test will be run on each and every one of those URIs,
+ adjusting the score if a match is found. Use this test instead of
+ one of the body tests when you need to match a URI, as it is more
+ accurately bound to the start/end points of the URI, and will also
+ be faster.
+
+ rawbody SYMBOLIC_TEST_NAME /pattern/modifiers
+ Define a raw-body pattern test. "pattern" is a Perl regular
+ expression. Note: as per the header tests, "#" must be escaped
+ ("\#") or else it is considered the beginning of a comment.
+
+ The 'raw body' of a message is the raw data inside all textual
+ parts. The text will be decoded from base64 or quoted-printable
+ encoding, but HTML tags and line breaks will still be present.
+ Multiline expressions will need to be used to match strings that are
+ broken by line breaks.
+
+ Note that the text is split into 2-4kB chunks (from a word boundary
+ when possible), this may unexpectedly prevent pattern from matching.
+ Patterns are matched independently against each of these chunks.
+
+ rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
+ Define a raw-body eval test. See above.
+
+ full SYMBOLIC_TEST_NAME /pattern/modifiers
+ Define a full message pattern test. "pattern" is a Perl regular
+ expression. Note: as per the header tests, "#" must be escaped
+ ("\#") or else it is considered the beginning of a comment.
+
+ The full message is the pristine message headers plus the pristine
+ message body, including all MIME data such as images, other
+ attachments, MIME boundaries, etc.
+
+ full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
+ Define a full message eval test. See above.
+
+ meta SYMBOLIC_TEST_NAME boolean expression
+ Define a boolean expression test in terms of other tests that have
+ been hit or not hit. For example:
+
+ meta META1 TEST1 && !(TEST2 || TEST3)
+
+ Note that English language operators ("and", "or") will be treated
+ as rule names, and that there is no "XOR" operator.
+
+ meta SYMBOLIC_TEST_NAME boolean arithmetic expression
+ Can also define an arithmetic expression in terms of other tests,
+ with an unhit test having the value "0" and a hit test having a
+ nonzero value. The value of a hit meta test is that of its
+ arithmetic expression. The value of a hit eval test is that returned
+ by its method. The value of a hit header, body, rawbody, uri, or
+ full test which has the "multiple" tflag is the number of times the
+ test hit. The value of any other type of hit test is "1".
+
+ For example:
+
+ meta META2 (3 * TEST1 - 2 * TEST2) > 0
+
+ Note that Perl builtins and functions, like "abs()", can't be used,
+ and will be treated as rule names.
+
+ If you want to define a meta-rule, but do not want its individual
+ sub-rules to count towards the final score unless the entire
+ meta-rule matches, give the sub-rules names that start with '__'
+ (two underscores). SpamAssassin will ignore these for scoring.
+
+ meta SYMBOLIC_TEST_NAME ... rules_matching(RULEGLOB) ...
+ Special function that will expand to list of matching rulenames. Can
+ be used anywhere in expressions. Argument supports glob style
[... 654 lines stripped ...]