Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
Mail::SpamAssassin::CoUser)Contributed Perl DocumenMail::SpamAssassin::Conf(3)

NAME
       Mail::SpamAssassin::Conf	- SpamAssassin configuration file

SYNOPSIS
	 # a comment

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

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

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

	 score A_HREF_TO_REMOVE		 2.0

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

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

DESCRIPTION
       SpamAssassin is configured using	traditional UNIX-style configuration
       files, loaded from the "/usr/share/spamassassin"	and
       "/etc/mail/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:

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

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

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

       clear_trusted_networks
	   Empty the list of trusted networks.

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

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

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

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

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

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

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

       clear_internal_networks
	   Empty the list of internal networks.

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

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

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

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

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

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

       clear_msa_networks
	   Empty the list of msa networks.

       originating_ip_headers header ...   (default: 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 <example@foo>
	   "Foo	Blah" <example@foo>
	   "'Foo Blah'"	<example@foo>

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

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

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

	   "ALL" can be	used to	mean the text of all the message's headers.
	   Note	that all whitespace inside the headers,	at line	folds, is
	   currently compressed	into a single space (' ') character. To	obtain
	   a pristine (unmodified) header section, use "ALL:raw" - the :raw
	   modifier is documented above. Also similar that return headers
	   added by specific relays: ALL-TRUSTED, ALL-INTERNAL,	ALL-UNTRUSTED,
	   ALL-EXTERNAL.
	   "ToCc" can be used to mean the contents of both the 'To' and	'Cc'
	   headers.
	   "EnvelopeFrom" is the address used in the 'MAIL FROM:' phase	of the
	   SMTP	transaction that delivered this	message, if this data has been
	   made	available by the SMTP server.  See "envelope_sender_header"
	   for more information	on how to set this.
	   "MESSAGEID" is a symbol meaning all Message-Id's found in the
	   message; some mailing list software moves the real 'Message-Id' to
	   'Resent-Message-Id' or to 'X-Message-Id', then uses its own one in
	   the 'Message-Id' header. The	value returned for this	symbol is the
	   text	from all 3 headers, separated by newlines.
	   "X-Spam-Relays-Untrusted", "X-Spam-Relays-Trusted",
	   "X-Spam-Relays-Internal" and	"X-Spam-Relays-External" represent a
	   portable, pre-parsed	representation of the message's	network	path,
	   as recorded in the Received headers,	divided	into 'trusted' vs
	   'untrusted' and 'internal' vs 'external' sets.  See
	   "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
	   rulename matching (*	= anything, ? =	one character).	 Matching is
	   case-sensitive.

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

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

	   Which would be the same as:

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

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

	   "reuse SPF_PASS"

	   "reuse MY_NET_RULE_V2 MY_NET_RULE_V1"

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

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

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

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

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

	   learn
	       The test	requires training before it can	be used.

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

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

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

	   noawl
	       This flag is specific when using	AWL plugin.

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

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

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

	       For example:

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

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

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

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

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

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

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

       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 you modify your ruleset, especially if
	   you plan to distribute it.  A good choice for string	is your	last
	   name	or your	initials followed by a number which you	increase with
	   each	change.

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

	   e.g.

	     version_tag myrules1    # version=2.41-myrules1

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

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

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

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

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

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

       util_rb_tld tld1	tld2 ...
	   This	option maintains list of valid TLDs in the RegistryBoundaries
	   code.  TLDs include things like com,	net, org, etc.

       util_rb_2tld 2tld-1.tld 2tld-2.tld ...
	   This	option maintains list of valid 2nd-level TLDs in the
	   RegistryBoundaries code.  2TLDs include things like co.uk, fed.us,
	   etc.

       util_rb_3tld 3tld1.some.tld 3tld2.other.tld ...
	   This	option maintains list of valid 3rd-level TLDs in the
	   RegistryBoundaries code.  3TLDs include things like demon.co.uk,
	   plc.co.im, etc.

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

       bayes_path /path/filename     (default: ~/.spamassassin/bayes)
	   This	is the directory and filename for Bayes	databases.  Several
	   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 then	database will not be
	   initialized.

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

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

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

	   If you load user scores from	an LDAP	directory, this	will set the
	   DSN used to connect.	You have to write the DSN as an	LDAP URL, the
	   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 [Mail::SpamAssassin::Plugin::]ModuleName [/path/module.pm]
	   Load	a SpamAssassin plugin module.  The "ModuleName"	is the perl
	   module name,	used to	create the plugin object itself.

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

	   "/path/module.pm" is	the file to load, containing the module's perl
	   code; if it's specified as a	relative path, it's considered to be
	   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 ModuleName [/path/module.pm]
	   Same	as "loadplugin", but silently ignored if the .pm file cannot
	   be found in the filesystem.

       ignore_always_matching_regexps	      (Default:	0)
	   Ignore any rule which contains a regexp which always	matches.
	   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.

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

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

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

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

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

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

	   has(Name::Of::Package::function_name)
	       This is a function call that returns 1 if the perl package
	       named "Name::Of::Package" includes a function called
	       "function_name",	or "undef" otherwise.  Note that packages can
	       be SpamAssassin plugins or built-in classes, there's no
	       difference in this respect.  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')
	_SENDERDOMAIN_	  a domain name	of the envelope	sender address,	lowercased
	_AUTHORDOMAIN_	  a domain name	of the author address (the From	header
			  field), lowercased;  note that RFC 5322 allows a mail
			  message to have multiple authors - currently only the
			  domain name of the first email address is returned
	_RELAYSTRUSTED_	  relays used and deemed to be trusted (see the
			  'X-Spam-Relays-Trusted' pseudo-header)
	_RELAYSUNTRUSTED_ relays used that can not be trusted (see the
			  'X-Spam-Relays-Untrusted' pseudo-header)
	_RELAYSINTERNAL_  relays used and deemed to be internal	(see the
			  'X-Spam-Relays-Internal' pseudo-header)
	_RELAYSEXTERNAL_  relays used and deemed to be external	(see the
			  'X-Spam-Relays-External' pseudo-header)
	_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)
	_SUBTESTSCOLLAPSED(,)_ subtests	(start with "__") hit separated	by ","
			  (or other separator) with duplicated rules collapsed
	_DCCB_		  DCC's	"Brand"
	_DCCR_		  DCC's	results
	_PYZOR_		  Pyzor	results
	_RBL_		  full results for positive RBL	queries	in DNS URI format
	_LANGUAGES_	  possible languages of	mail
	_PREVIEW_	  content preview
	_REPORT_	  terse	report of tests	hit (for header	reports)
	_SUBJPREFIX_	  subject prefix based on rules, to be prepended to Subject
			  header by SpamAssassin caller
	_SUMMARY_	  summary of tests hit for standard report (for	body reports)
	_CONTACTADDRESS_  contents of the 'report_contact' setting
	_HEADER(NAME)_	  includes the value of	a message header.  value is the	same
			  as is	found for header rules (see elsewhere in this doc)
	_TIMING_	  timing breakdown report
	_ADDEDHEADERHAM_  resulting header fields as requested by add_header for spam
	_ADDEDHEADERSPAM_ resulting header fields as requested by add_header for ham
	_ADDEDHEADER_	  same as ADDEDHEADERHAM for ham or ADDEDHEADERSPAM for	spam

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

       Additional, plugin specific, template tags can be found in the
       documentation for the following plugins:

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

       The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second
       argument	which specifies	a format.  See the HAMMYTOKENS/SPAMMYTOKENS
       TAG FORMAT 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(3) spamassassin(1) spamd(1)

perl v5.32.0			  2020-01-25	   Mail::SpamAssassin::Conf(3)

NAME | SYNOPSIS | DESCRIPTION | FILE FORMAT | USER PREFERENCES | RULE DEFINITIONS AND PRIVILEGED SETTINGS | ADMINISTRATOR SETTINGS | PREPROCESSING OPTIONS | TEMPLATE TAGS | LOCALI[SZ]ATION | SEE ALSO

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

home | help