Mailing List Archive

svn commit: r1871201 [4/17] - in /spamassassin/site/full/3.4.x: ./ doc/
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.html?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Conf.html Wed Dec 11 22:18:49 2019
@@ -0,0 +1,2116 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title></title>
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root@localhost" />
+</head>
+
+<body style="background-color: white">
+
+
+
+<ul id="index">
+ <li><a href="#NAME">NAME</a></li>
+ <li><a href="#SYNOPSIS">SYNOPSIS</a></li>
+ <li><a href="#DESCRIPTION">DESCRIPTION</a></li>
+ <li><a href="#FILE-FORMAT">FILE FORMAT</a></li>
+ <li><a href="#USER-PREFERENCES">USER PREFERENCES</a>
+ <ul>
+ <li><a href="#SCORING-OPTIONS">SCORING OPTIONS</a></li>
+ <li><a href="#WHITELIST-AND-BLACKLIST-OPTIONS">WHITELIST AND BLACKLIST OPTIONS</a></li>
+ <li><a href="#BASIC-MESSAGE-TAGGING-OPTIONS">BASIC MESSAGE TAGGING OPTIONS</a></li>
+ <li><a href="#LANGUAGE-OPTIONS">LANGUAGE OPTIONS</a></li>
+ <li><a href="#NETWORK-TEST-OPTIONS">NETWORK TEST OPTIONS</a></li>
+ <li><a href="#LEARNING-OPTIONS">LEARNING OPTIONS</a></li>
+ <li><a href="#MISCELLANEOUS-OPTIONS">MISCELLANEOUS OPTIONS</a></li>
+ </ul>
+ </li>
+ <li><a href="#RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</a></li>
+ <li><a href="#ADMINISTRATOR-SETTINGS">ADMINISTRATOR SETTINGS</a></li>
+ <li><a href="#PREPROCESSING-OPTIONS">PREPROCESSING OPTIONS</a></li>
+ <li><a href="#TEMPLATE-TAGS">TEMPLATE TAGS</a>
+ <ul>
+ <li><a href="#HAMMYTOKENS-SPAMMYTOKENS-TAG-FORMAT">HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT</a></li>
+ </ul>
+ </li>
+ <li><a href="#LOCALI-SZ-ATION">LOCALI[SZ]ATION</a></li>
+ <li><a href="#SEE-ALSO">SEE ALSO</a></li>
+</ul>
+
+<h1 id="NAME">NAME</h1>
+
+<p>Mail::SpamAssassin::Conf - SpamAssassin configuration file</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<pre><code> # 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 [...]</code></pre>
+
+<h1 id="DESCRIPTION">DESCRIPTION</h1>
+
+<p>SpamAssassin is configured using traditional UNIX-style configuration files, loaded from the <code>/usr/share/spamassassin</code> and <code>/etc/mail/spamassassin</code> directories.</p>
+
+<p>The following web page lists the most important configuration settings used to configure SpamAssassin; novices are encouraged to read it first:</p>
+
+<pre><code> http://wiki.apache.org/spamassassin/ImportantInitialConfigItems</code></pre>
+
+<h1 id="FILE-FORMAT">FILE FORMAT</h1>
+
+<p>The <code>#</code> character starts a comment, which continues until end of line. <b>NOTE:</b> if the <code>#</code> character is to be used as part of a rule or configuration option, it must be escaped with a backslash. i.e.: <code>\#</code></p>
+
+<p>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.</p>
+
+<p>Currently, each rule or configuration setting must fit on one-line; multi-line settings are not supported yet.</p>
+
+<p>File and directory paths can use <code>~</code> to refer to the user&#39;s home directory, but no other shell-style path extensions such as globing or <code>~user/</code> are supported.</p>
+
+<p>Where appropriate below, default values are listed in parentheses.</p>
+
+<p>Test names (&quot;SYMBOLIC_TEST_NAME&quot;) can only contain alphanumerics/underscores, can not start with digit, and must be less than 128 characters.</p>
+
+<h1 id="USER-PREFERENCES">USER PREFERENCES</h1>
+
+<p>The following options can be used in both site-wide (<code>local.cf</code>) and user-specific (<code>user_prefs</code>) configuration files to customize how SpamAssassin handles incoming email messages.</p>
+
+<h2 id="SCORING-OPTIONS">SCORING OPTIONS</h2>
+
+<dl>
+
+<dt id="required_score-n.nn-default:-5">required_score n.nn (default: 5)</dt>
+<dd>
+
+<p>Set the score required before a mail is considered spam. <code>n.nn</code> 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&#39;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 <b>will</b> 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 <code>required_hits</code> and that name is still accepted, but is deprecated.</p>
+
+</dd>
+<dt id="score-SYMBOLIC_TEST_NAME-n.nn-n.nn-n.nn-n.nn">score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]</dt>
+<dd>
+
+<p>Assign scores (the number of points for a hit) to a given test. Scores can be positive or negative real numbers or integers. <code>SYMBOLIC_TEST_NAME</code> is the symbolic name used by SpamAssassin for that test; for example, &#39;FROM_ENDS_IN_NUMS&#39;.</p>
+
+<p>If only one valid score is listed, then that score is always used for a test.</p>
+
+<p>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).</p>
+
+<p>Setting a rule&#39;s score to 0 will disable that rule from running.</p>
+
+<p>If any of the score values are surrounded by parenthesis &#39;()&#39;, then all of the scores in the line are considered to be relative to the already set score. ie: &#39;(3)&#39; means increase the score for this rule by 3 points in all score sets. &#39;(3) (0) (3) (0)&#39; means increase the score for this rule by 3 in score sets 0 and 2 only.</p>
+
+<p>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 &#39;T_&#39; (this is used to indicate a rule in testing) which receive 0.01.</p>
+
+<p>Note that test names which begin with &#39;__&#39; 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 &#39;tests hit&#39; reports, but assigning a score of 0 to an indirect rule will disable it from running.</p>
+
+</dd>
+</dl>
+
+<h2 id="WHITELIST-AND-BLACKLIST-OPTIONS">WHITELIST AND BLACKLIST OPTIONS</h2>
+
+<dl>
+
+<dt id="whitelist_from-user-example.com">whitelist_from user@example.com</dt>
+<dd>
+
+<p>Used to whitelist sender addresses which send mail that is often tagged (incorrectly) as spam.</p>
+
+<p>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 <code>whitelist_auth</code> or other authenticated whitelisting methods, or <code>whitelist_from_rcvd</code>.</p>
+
+<p>Whitelist and blacklist addresses are now file-glob-style patterns, so <code>friend@somewhere.com</code>, <code>*@isp.com</code>, or <code>*.domain.net</code> will all work. Specifically, <code>*</code> and <code>?</code> are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons. Matching is case-insensitive.</p>
+
+<p>Multiple addresses per line, separated by spaces, is OK. Multiple <code>whitelist_from</code> lines are also OK.</p>
+
+<p>The headers checked for whitelist addresses are as follows: if <code>Resent-From</code> is set, use that; otherwise check all addresses taken from the following set of headers:</p>
+
+<pre><code> Envelope-Sender
+ Resent-Sender
+ X-Envelope-From
+ From</code></pre>
+
+<p>In addition, the &quot;envelope sender&quot; data, taken from the SMTP envelope data where this is available, is looked up. See <code>envelope_sender_header</code>.</p>
+
+<p>e.g.</p>
+
+<pre><code> whitelist_from joe@example.com fred@example.com
+ whitelist_from *@example.com</code></pre>
+
+</dd>
+<dt id="unwhitelist_from-user-example.com">unwhitelist_from user@example.com</dt>
+<dd>
+
+<p>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 <code>user_prefs</code> 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 &#39;any&#39; address).</p>
+
+<p>e.g.</p>
+
+<pre><code> unwhitelist_from joe@example.com fred@example.com
+ unwhitelist_from *@example.com</code></pre>
+
+</dd>
+<dt id="whitelist_from_rcvd-addr-lists.sourceforge.net-sourceforge.net">whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net</dt>
+<dd>
+
+<p>Works similarly to whitelist_from, except that in addition to matching a sender address, a relay&#39;s rDNS name or its IP address must match too for the whitelisting rule to fire. The first parameter is a sender&#39;s e-mail address to whitelist, and the second is a string to match the relay&#39;s rDNS, or its IP address. Matching is case-insensitive.</p>
+
+<p>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.</p>
+
+<p>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. <code>[10.1.2.3]</code>, <code>[10.1.2]</code>, <code>[10.1]</code>, <code>[10]</code>.</p>
+
+<p>In other words, if the host that connected to your MX had an IP address 192.0.2.123 that mapped to &#39;sendinghost.example.org&#39;, you should specify <code>sendinghost.example.org</code>, or <code>example.org</code>, or <code>[192.0.2.123]</code>, or <code>[192.0.2.0/24]</code>, or <code>[192.0.2]</code> here.</p>
+
+<p>Note that this requires that <code>internal_networks</code> be correct. For simple cases, it will be, but for a complex network you may get better results by setting that parameter.</p>
+
+<p>It also requires that your mail exchangers be configured to perform DNS reverse lookups on the connecting host&#39;s IP address, and to record the result in the generated Received header field according to RFC 5321.</p>
+
+<p>e.g.</p>
+
+<pre><code> 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</code></pre>
+
+</dd>
+<dt id="def_whitelist_from_rcvd-addr-lists.sourceforge.net-sourceforge.net">def_whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net</dt>
+<dd>
+
+<p>Same as <code>whitelist_from_rcvd</code>, but used for the default whitelist entries in the SpamAssassin distribution. The whitelist score is lower, because these are often targets for spammer spoofing.</p>
+
+</dd>
+<dt id="whitelist_allows_relays-user-example.com">whitelist_allows_relays user@example.com</dt>
+<dd>
+
+<p>Specify addresses which are in <code>whitelist_from_rcvd</code> that sometimes send through a mail relay other than the listed ones. By default mail with a From address that is in <code>whitelist_from_rcvd</code> that does not match the relay will trigger a forgery rule. Including the address in <code>whitelist_allows_relay</code> prevents that.</p>
+
+<p>Whitelist and blacklist addresses are now file-glob-style patterns, so <code>friend@somewhere.com</code>, <code>*@isp.com</code>, or <code>*.domain.net</code> will all work. Specifically, <code>*</code> and <code>?</code> are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons. Matching is case-insensitive.</p>
+
+<p>Multiple addresses per line, separated by spaces, is OK. Multiple <code>whitelist_allows_relays</code> lines are also OK.</p>
+
+<p>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.</p>
+
+<p>e.g.</p>
+
+<pre><code> whitelist_allows_relays joe@example.com fred@example.com
+ whitelist_allows_relays *@example.com</code></pre>
+
+</dd>
+<dt id="unwhitelist_from_rcvd-user-example.com">unwhitelist_from_rcvd user@example.com</dt>
+<dd>
+
+<p>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 <code>user_prefs</code> file.</p>
+
+<p>The specified email address has to match exactly the address previously used in a whitelist_from_rcvd line.</p>
+
+<p>e.g.</p>
+
+<pre><code> unwhitelist_from_rcvd joe@example.com fred@example.com
+ unwhitelist_from_rcvd *@axkit.org</code></pre>
+
+</dd>
+<dt id="blacklist_from-user-example.com">blacklist_from user@example.com</dt>
+<dd>
+
+<p>Used to specify addresses which send mail that is often tagged (incorrectly) as non-spam, but which the user doesn&#39;t want. Same format as <code>whitelist_from</code>.</p>
+
+</dd>
+<dt id="unblacklist_from-user-example.com">unblacklist_from user@example.com</dt>
+<dd>
+
+<p>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 <code>user_prefs</code> file. The specified email address has to match exactly the address previously used in a blacklist_from line.</p>
+
+<p>e.g.</p>
+
+<pre><code> unblacklist_from joe@example.com fred@example.com
+ unblacklist_from *@spammer.com</code></pre>
+
+</dd>
+<dt id="whitelist_to-user-example.com">whitelist_to user@example.com</dt>
+<dd>
+
+<p>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&#39;re deploying SpamAssassin system-wide, and don&#39;t want some users to have their mail filtered. Same format as <code>whitelist_from</code>.</p>
+
+<p>There are three levels of To-whitelisting, <code>whitelist_to</code>, <code>more_spam_to</code> and <code>all_spam_to</code>. Users in the first level may still get some spammish mails blocked, but users in <code>all_spam_to</code> should never get mail blocked.</p>
+
+<p>The headers checked for whitelist addresses are as follows: if <code>Resent-To</code> or <code>Resent-Cc</code> are set, use those; otherwise check all addresses taken from the following set of headers:</p>
+
+<pre><code> 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</code></pre>
+
+</dd>
+<dt id="more_spam_to-user-example.com">more_spam_to user@example.com</dt>
+<dd>
+
+<p>See above.</p>
+
+</dd>
+<dt id="all_spam_to-user-example.com">all_spam_to user@example.com</dt>
+<dd>
+
+<p>See above.</p>
+
+</dd>
+<dt id="blacklist_to-user-example.com">blacklist_to user@example.com</dt>
+<dd>
+
+<p>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 <code>blacklist_from</code>.</p>
+
+</dd>
+<dt id="whitelist_auth-user-example.com">whitelist_auth user@example.com</dt>
+<dd>
+
+<p>Used to specify addresses which send mail that is often tagged (incorrectly) as spam. This is different from <code>whitelist_from</code> and <code>whitelist_from_rcvd</code> in that it first verifies that the message was sent by an authorized sender for the address, before whitelisting.</p>
+
+<p>Authorization is performed using one of the installed sender-authorization schemes: SPF (using <code>Mail::SpamAssassin::Plugin::SPF</code>), or DKIM (using <code>Mail::SpamAssassin::Plugin::DKIM</code>). Note that those plugins must be active, and working, for this to operate.</p>
+
+<p>Using <code>whitelist_auth</code> is roughly equivalent to specifying duplicate <code>whitelist_from_spf</code>, <code>whitelist_from_dk</code>, and <code>whitelist_from_dkim</code> lines for each of the addresses specified.</p>
+
+<p>e.g.</p>
+
+<pre><code> whitelist_auth joe@example.com fred@example.com
+ whitelist_auth *@example.com</code></pre>
+
+</dd>
+<dt id="def_whitelist_auth-user-example.com">def_whitelist_auth user@example.com</dt>
+<dd>
+
+<p>Same as <code>whitelist_auth</code>, but used for the default whitelist entries in the SpamAssassin distribution. The whitelist score is lower, because these are often targets for spammer spoofing.</p>
+
+</dd>
+<dt id="unwhitelist_auth-user-example.com">unwhitelist_auth user@example.com</dt>
+<dd>
+
+<p>Used to override a <code>whitelist_auth</code> entry. The specified email address has to match exactly the address previously used in a <code>whitelist_auth</code> line.</p>
+
+<p>e.g.</p>
+
+<pre><code> unwhitelist_auth joe@example.com fred@example.com
+ unwhitelist_auth *@example.com</code></pre>
+
+</dd>
+<dt id="enlist_uri_host-listname-host">enlist_uri_host (listname) host ...</dt>
+<dd>
+
+<p>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.</p>
+
+<p>Host names may optionally be prefixed by an exclamation mark &#39;!&#39;, 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:</p>
+
+<pre><code> enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com</code></pre>
+
+<p>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 &#39;!&#39; prefix) or a false (with a &#39;!&#39; prefix) result.</p>
+
+<p>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.</p>
+
+<p>Use the delist_uri_host directive to neutralize previous enlist_uri_host settings.</p>
+
+<p>Enlisting to lists named &#39;BLACK&#39; and &#39;WHITE&#39; have their shorthand directives blacklist_uri_host and whitelist_uri_host and corresponding default rules, but the names &#39;BLACK&#39; and &#39;WHITE&#39; are otherwise not special or reserved.</p>
+
+</dd>
+<dt id="delist_uri_host-listname-host">delist_uri_host [ (listname) ] host ...</dt>
+<dd>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="enlist_addrlist-listname-user-example.com">enlist_addrlist (listname) user@example.com</dt>
+<dd>
+
+<p>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.</p>
+
+<p>Listed addresses are file-glob-style patterns, so <code>friend@somewhere.com</code>, <code>*@isp.com</code>, or <code>*.domain.net</code> will all work. Specifically, <code>*</code> and <code>?</code> are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons. Matching is case-insensitive.</p>
+
+<p>Multiple addresses per line, separated by spaces, is OK. Multiple <code>enlist_addrlist</code> lines are also OK.</p>
+
+<p>Enlisting an address to the list named blacklist_to is synonymous to using the directive blacklist_to</p>
+
+<p>Enlisting an address to the list named blacklist_from is synonymous to using the directive blacklist_from</p>
+
+<p>Enlisting an address to the list named whitelist_to is synonymous to using the directive whitelist_to</p>
+
+<p>Enlisting an address to the list named whitelist_from is synonymous to using the directive whitelist_from</p>
+
+<p>e.g.</p>
+
+<pre><code> enlist_addrlist (PAYPAL_ADDRESS) service@paypal.com
+ enlist_addrlist (PAYPAL_ADDRESS) *@paypal.co.uk</code></pre>
+
+</dd>
+<dt id="blacklist_uri_host-host-or-domain">blacklist_uri_host host-or-domain ...</dt>
+<dd>
+
+<p>Is a shorthand for a directive: enlist_uri_host (BLACK) host ...</p>
+
+<p>Please see directives enlist_uri_host and delist_uri_host for details.</p>
+
+</dd>
+<dt id="whitelist_uri_host-host-or-domain">whitelist_uri_host host-or-domain ...</dt>
+<dd>
+
+<p>Is a shorthand for a directive: enlist_uri_host (BLACK) host ...</p>
+
+<p>Please see directives enlist_uri_host and delist_uri_host for details.</p>
+
+</dd>
+</dl>
+
+<h2 id="BASIC-MESSAGE-TAGGING-OPTIONS">BASIC MESSAGE TAGGING OPTIONS</h2>
+
+<dl>
+
+<dt id="rewrite_header-subject-from-to-STRING">rewrite_header { subject | from | to } STRING</dt>
+<dd>
+
+<p>By default, suspected spam messages will not have the <code>Subject</code>, <code>From</code> or <code>To</code> lines tagged to indicate spam. By setting this option, the header will be tagged with <code>STRING</code> 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 <code>report_safe</code> 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 <b>TEMPLATE TAGS</b> section.</p>
+
+<p>Parentheses are not permitted in STRING if rewriting the From or To headers. (They will be converted to square brackets.)</p>
+
+<p>If <code>rewrite_header subject</code> is used, but the message being rewritten does not already contain a <code>Subject</code> header, one will be created.</p>
+
+<p>A null value for <code>STRING</code> will remove any existing rewrite for the specified header.</p>
+
+</dd>
+<dt id="subjprefix">subjprefix</dt>
+<dd>
+
+<p>Add a prefix in emails Subject if a rule is matched. To enable this option &quot;rewrite_header Subject&quot; config option must be enabled as well.</p>
+
+<p>The check <code>if can(Mail::SpamAssassin::Conf::feature_subjprefix)</code> should be used to silence warnings in previous SpamAssassin versions.</p>
+
+<p>To be able to use this feature a <code>add_header all Subjprefix _SUBJPREFIX_</code> configuration line could be needed on some setups.</p>
+
+</dd>
+<dt id="add_header-spam-ham-all-header_name-string">add_header { spam | ham | all } header_name string</dt>
+<dd>
+
+<p>Customized headers can be added to the specified type of messages (spam, ham, or &quot;all&quot; to add to either). All headers begin with <code>X-Spam-</code> (so a <code>header_name</code> Foo will generate a header called X-Spam-Foo). header_name is restricted to the character set [A-Za-z0-9_-].</p>
+
+<p>The order of <code>add_header</code> configuration options is preserved, inserted headers will follow this order of declarations. When combining <code>add_header</code> with <code>clear_headers</code> and <code>remove_header</code>, keep in mind that <code>add_header</code> appends a new header to the current list, after first removing any existing header fields of the same name. Note also that <code>add_header</code>, <code>clear_headers</code> and <code>remove_header</code> may appear in multiple .cf files, which are interpreted in alphabetic order.</p>
+
+<p><code>string</code> can contain tags as explained below in the <b>TEMPLATE TAGS</b> section. You can also use <code>\n</code> and <code>\t</code> 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.</p>
+
+<p>All headers will be folded if fold_headers is set to <code>1</code>. Note: Manually adding newlines via <code>\n</code> disables any further automatic wrapping (ie: long header lines are possible). The lines will still be properly folded (marked as continuing) though.</p>
+
+<p>You can customize existing headers with <b>add_header</b> (only the specified subset of messages will be changed).</p>
+
+<p>See also <code>clear_headers</code> and <code>remove_header</code> for removing headers.</p>
+
+<p>Here are some examples (these are the defaults, note that Checker-Version can not be changed or removed):</p>
+
+<pre><code> 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_</code></pre>
+
+</dd>
+<dt id="remove_header-spam-ham-all-header_name">remove_header { spam | ham | all } header_name</dt>
+<dd>
+
+<p>Headers can be removed from the specified type of messages (spam, ham, or &quot;all&quot; to remove from either). All headers begin with <code>X-Spam-</code> (so <code>header_name</code> will be appended to <code>X-Spam-</code>).</p>
+
+<p>See also <code>clear_headers</code> for removing all the headers at once.</p>
+
+<p>Note that <b>X-Spam-Checker-Version</b> 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.</p>
+
+</dd>
+<dt id="clear_headers">clear_headers</dt>
+<dd>
+
+<p>Clear the list of headers to be added to messages. You may use this before any <b>add_header</b> options to prevent the default headers from being added to the message.</p>
+
+<p><code>add_header</code>, <code>clear_headers</code> and <code>remove_header</code> may appear in multiple .cf files, which are interpreted in alphabetic order, so <code>clear_headers</code> in a later file will remove all added headers from previously interpreted configuration files, which may or may not be desired.</p>
+
+<p>Note that <b>X-Spam-Checker-Version</b> 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.</p>
+
+</dd>
+<dt id="report_safe-0-1-2-default:-1">report_safe ( 0 | 1 | 2 ) (default: 1)</dt>
+<dd>
+
+<p>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).</p>
+
+<p>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.</p>
+
+<p>If this option is set to 0, incoming spam is only modified by adding some <code>X-Spam-</code> headers and no changes will be made to the body. In addition, a header named <b>X-Spam-Report</b> will be added to spam. You can use the <b>remove_header</b> option to remove that header after setting <b>report_safe</b> to 0.</p>
+
+<p>See <b>report_safe_copy_headers</b> if you want to copy headers from the original mail into tagged messages.</p>
+
+</dd>
+<dt id="report_wrap_width-default:-70">report_wrap_width (default: 70)</dt>
+<dd>
+
+<p>This option sets the wrap width for description lines in the X-Spam-Report header, not accounting for tab width.</p>
+
+</dd>
+</dl>
+
+<h2 id="LANGUAGE-OPTIONS">LANGUAGE OPTIONS</h2>
+
+<dl>
+
+<dt id="ok_locales-xx-yy-zz-...-default:-all">ok_locales xx [ yy zz ... ] (default: all)</dt>
+<dd>
+
+<p>This option is used to specify which locales are considered OK for incoming mail. Mail using the <b>character sets</b> that are allowed by this option will not be marked as possibly being spam in a foreign language.</p>
+
+<p>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.</p>
+
+<p>Set this to <code>all</code> to allow all character sets. This is the default.</p>
+
+<p>The rules <code>CHARSET_FARAWAY</code>, <code>CHARSET_FARAWAY_BODY</code>, and <code>CHARSET_FARAWAY_HEADERS</code> are triggered based on how this is set.</p>
+
+<p>Examples:</p>
+
+<pre><code> ok_locales all (allow all locales)
+ ok_locales en (only allow English)
+ ok_locales en ja zh (allow English, Japanese, and Chinese)</code></pre>
+
+<p>Note: if there are multiple ok_locales lines, only the last one is used.</p>
+
+<p>Select the locales to allow from the list below:</p>
+
+<dl>
+
+<dt id="en---Western-character-sets-in-general">en - Western character sets in general</dt>
+<dd>
+
+</dd>
+<dt id="ja---Japanese-character-sets">ja - Japanese character sets</dt>
+<dd>
+
+</dd>
+<dt id="ko---Korean-character-sets">ko - Korean character sets</dt>
+<dd>
+
+</dd>
+<dt id="ru---Cyrillic-character-sets">ru - Cyrillic character sets</dt>
+<dd>
+
+</dd>
+<dt id="th---Thai-character-sets">th - Thai character sets</dt>
+<dd>
+
+</dd>
+<dt id="zh---Chinese-both-simplified-and-traditional-character-sets">zh - Chinese (both simplified and traditional) character sets</dt>
+<dd>
+
+</dd>
+</dl>
+
+</dd>
+<dt id="normalize_charset-0-1-default:-0">normalize_charset ( 0 | 1) (default: 0)</dt>
+<dd>
+
+<p>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).</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="body_part_scan_size-default:-50000">body_part_scan_size (default: 50000)</dt>
+<dd>
+
+<p>Per mime-part scan size limit in bytes for &quot;body&quot; type rules. The decoded/stripped mime-part is truncated approx to this size. Helps scanning large messages safely, so it&#39;s not necessary to skip them completely. Disabled with 0.</p>
+
+</dd>
+<dt id="rawbody_part_scan_size-default:-500000">rawbody_part_scan_size (default: 500000)</dt>
+<dd>
+
+<p>Like body_part_scan_size, for &quot;rawbody&quot; type rules.</p>
+
+</dd>
+</dl>
+
+<h2 id="NETWORK-TEST-OPTIONS">NETWORK TEST OPTIONS</h2>
+
+<dl>
+
+<dt id="trusted_networks-IPaddress-masklen-...-default:-none">trusted_networks IPaddress[/masklen] ... (default: none)</dt>
+<dd>
+
+<p>What networks or hosts are &#39;trusted&#39; in your setup. <b>Trusted</b> 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.</p>
+
+<p>See <code>http://wiki.apache.org/spamassassin/TrustPath</code> for more information.</p>
+
+<p>MXes for your domain(s) and internal relays should <b>also</b> be specified using the <code>internal_networks</code> setting. When there are &#39;trusted&#39; hosts that are not MXes or internal relays for your domain(s) they should <b>only</b> be specified in <code>trusted_networks</code>.</p>
+
+<p>The <code>IPaddress</code> 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.</p>
+
+<p>If a <code>/masklen</code> is specified, it is considered a CIDR-style &#39;netmask&#39; 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 <code>/32</code> with an IPv4 address, or <code>/128</code> in case of an IPv6 address.</p>
+
+<p>If a network or host address is prefaced by a <code>!</code> 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.</p>
+
+<p>Note: 127.0.0.0/8 and ::1 are always included in trusted_networks, regardless of your config.</p>
+
+<p>Examples:</p>
+
+<pre><code> 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</code></pre>
+
+<p>This operates additively, so a <code>trusted_networks</code> line after another one will append new entries to the list of trusted networks. To clear out the existing entries, use <code>clear_trusted_networks</code>.</p>
+
+<p>If <code>trusted_networks</code> is not set and <code>internal_networks</code> is, the value of <code>internal_networks</code> will be used for this parameter.</p>
+
+<p>If neither <code>trusted_networks</code> or <code>internal_networks</code> is set, a basic inference algorithm is applied. This works as follows:</p>
+
+<ul>
+
+<li><p>If the &#39;from&#39; host has an IP address in a private (RFC 1918) network range, then it&#39;s trusted</p>
+
+</li>
+<li><p>If there are authentication tokens in the received header, and the previous host was trusted, then this host is also trusted</p>
+
+</li>
+<li><p>Otherwise this host, and all further hosts, are consider untrusted.</p>
+
+</li>
+</ul>
+
+</dd>
+<dt id="clear_trusted_networks">clear_trusted_networks</dt>
+<dd>
+
+<p>Empty the list of trusted networks.</p>
+
+</dd>
+<dt id="internal_networks-IPaddress-masklen-...-default:-none">internal_networks IPaddress[/masklen] ... (default: none)</dt>
+<dd>
+
+<p>What networks or hosts are &#39;internal&#39; in your setup. <b>Internal</b> 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 <code>trusted_networks</code>, above - see there for details.</p>
+
+<p>This value is used when checking &#39;dial-up&#39; or dynamic IP address blocklists, in order to detect direct-to-MX spamming.</p>
+
+<p>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 <code>internal_networks</code>. List them only in <code>trusted_networks</code>.</p>
+
+<p>If <code>trusted_networks</code> is set and <code>internal_networks</code> is not, the value of <code>trusted_networks</code> will be used for this parameter.</p>
+
+<p>If neither <code>trusted_networks</code> nor <code>internal_networks</code> is set, no addresses will be considered local; in other words, any relays past the machine where SpamAssassin is running will be considered external.</p>
+
+<p>Every entry in <code>internal_networks</code> must appear in <code>trusted_networks</code>; in other words, <code>internal_networks</code> is always a subset of the trusted set.</p>
+
+<p>Note: 127/8 and ::1 are always included in internal_networks, regardless of your config.</p>
+
+</dd>
+<dt id="clear_internal_networks">clear_internal_networks</dt>
+<dd>
+
+<p>Empty the list of internal networks.</p>
+
+</dd>
+<dt id="msa_networks-IPaddress-masklen-...-default:-none">msa_networks IPaddress[/masklen] ... (default: none)</dt>
+<dd>
+
+<p>The networks or hosts which are acting as MSAs in your setup (but not also as MX relays). This uses the same syntax as <code>trusted_networks</code>, above - see there for details.</p>
+
+<p><b>MSA</b> 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&#39;t authenticated in some way. Examples of authentication include, IP lists, SMTP AUTH, POP-before-SMTP, etc.</p>
+
+<p>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 <i>trusted_networks</i> and <i>internal_networks</i> configuration.</p>
+
+<p>For example, if the MSA relay is trusted and internal so will all of the relays that precede it.</p>
+
+<p>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.</p>
+
+<p><b>Warning:</b> 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.</p>
+
+</dd>
+<dt id="clear_msa_networks">clear_msa_networks</dt>
+<dd>
+
+<p>Empty the list of msa networks.</p>
+
+</dd>
+<dt id="originating_ip_headers-header-...-default:-X-Yahoo-Post-IP-X-Originating-IP-X-Apparently-From-X-SenderIP">originating_ip_headers header ... (default: X-Yahoo-Post-IP X-Originating-IP X-Apparently-From X-SenderIP)</dt>
+<dd>
+
+<p>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.</p>
+
+<p>These IP addresses are virtually appended into the Received: chain, so they are used in RBL checks where appropriate.</p>
+
+<p>Currently the IP addresses are not added into X-Spam-Relays-* header fields, but they may be in the future.</p>
+
+</dd>
+<dt id="clear_originating_ip_headers">clear_originating_ip_headers</dt>
+<dd>
+
+<p>Empty the list of &#39;originating IP address&#39; header field names.</p>
+
+</dd>
+<dt id="always_trust_envelope_sender-0-1-default:-0">always_trust_envelope_sender ( 0 | 1 ) (default: 0)</dt>
+<dd>
+
+<p>Trust the envelope sender even if the message has been passed through one or more trusted relays. See also <code>envelope_sender_header</code>.</p>
+
+</dd>
+<dt id="skip_rbl_checks-0-1-default:-0">skip_rbl_checks ( 0 | 1 ) (default: 0)</dt>
+<dd>
+
+<p>Turning on the skip_rbl_checks setting will disable the DNSEval plugin, which implements Real-time Block List (or: Blackhole List) (RBL) lookups.</p>
+
+<p>By default, SpamAssassin will run RBL checks. Individual blocklists may be disabled selectively by setting a score of a corresponding rule to 0.</p>
+
+<p>See also a related configuration parameter skip_uribl_checks, which controls the URIDNSBL plugin (documented in the URIDNSBL man page).</p>
+
+</dd>
+<dt id="dns_available-yes-no-test-:-domain1-domain2...-default:-yes">dns_available { yes | no | test[: domain1 domain2...] } (default: yes)</dt>
+<dd>
+
+<p>Tells SpamAssassin whether DNS resolving is available or not. A value <i>yes</i> indicates DNS resolving is available, a value <i>no</i> indicates DNS resolving is not available - both of these values apply unconditionally and skip initial DNS tests, which can be slow or unreliable.</p>
+
+<p>When the option value is a <i>test</i> (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.</p>
+
+<p>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.</p>
+
+<p>Please note, the DNS test queries for NS records, so specify domain names, not host names.</p>
+
+<p>Since version 3.4.0 of SpamAssassin a default setting for option <i>dns_available</i> is <i>yes</i>. A default in older versions was <i>test</i>.</p>
+
+</dd>
+<dt id="dns_server-ip-addr-port-default:-entries-provided-by-Net::DNS">dns_server ip-addr-port (default: entries provided by Net::DNS)</dt>
+<dd>
+
+<p>Specifies an IP address of a DNS server, and optionally its port number. The <i>dns_server</i> directive may be specified multiple times, each entry adding to a list of available resolving name servers. The <i>ip-addr-port</i> 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 <b>must</b> 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).</p>
+
+<p>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</p>
+
+<p>In absence of <i>dns_server</i> 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.</p>
+
+</dd>
+<dt id="clear_dns_servers">clear_dns_servers</dt>
+<dd>
+
+<p>Empty the list of explicitly configured DNS servers through a <i>dns_server</i> directive, falling back to Net::DNS -supplied defaults.</p>
+
+</dd>
+<dt id="dns_local_ports_permit-ranges">dns_local_ports_permit ranges...</dt>
+<dd>
+
+<p>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.</p>
+
+<p>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 &#39;-&#39;, representing a range. Allowed port numbers are between 1 and 65535.</p>
+
+<p>Directives <i>dns_local_ports_permit</i> and <i>dns_local_ports_avoid</i> 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.</p>
+
+<p>If the resulting set of port numbers is empty (see also the directive <i>dns_local_ports_none</i>), then SpamAssassin does not apply its ports randomization logic, but instead leaves the operating system to choose a suitable free local port number.</p>
+
+<p>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.</p>
+
+<p>See also directives <i>dns_local_ports_permit</i> and <i>dns_local_ports_none</i>.</p>
+
+</dd>
+<dt id="dns_local_ports_avoid-ranges">dns_local_ports_avoid ranges...</dt>
+<dd>
+
+<p>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.</p>
+
+<p>Please see directive <i>dns_local_ports_permit</i> for details.</p>
+
+</dd>
+<dt id="dns_local_ports_none">dns_local_ports_none</dt>
+<dd>
+
+<p>Is a fast shorthand for:</p>
+
+<pre><code> dns_local_ports_avoid 1-65535</code></pre>
+
+<p>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 <i>dns_local_ports_permit</i> and <i>dns_local_ports_avoid</i>.</p>
+
+<p>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.</p>
+
+<p>See also directives <i>dns_local_ports_permit</i> and <i>dns_local_ports_avoid</i>.</p>
+
+</dd>
+<dt id="dns_test_interval-n-default:-600-seconds">dns_test_interval n (default: 600 seconds)</dt>
+<dd>
+
+<p>If dns_available is set to <i>test</i>, 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).</p>
+
+</dd>
+<dt id="dns_options-opts-default:-norotate-nodns0x20-edns-4096">dns_options opts (default: norotate, nodns0x20, edns=4096)</dt>
+<dd>
+
+<p>Provides a (whitespace or comma -separated) list of options applying to DNS resolving. Available options are: <i>rotate</i>, <i>dns0x20</i> and <i>edns</i> (or <i>edns0</i>). Option name may be negated by prepending a <i>no</i> (e.g. <i>norotate</i>, <i>NoEDNS</i>) to counteract a previously enabled option. Option names are not case-sensitive. The <i>dns_options</i> directive may appear in configuration files multiple times, the last setting prevails.</p>
+
+<p>Option <i>edns</i> (or <i>edsn0</i>) may take a value which specifies a requestor&#39;s acceptable UDP payload size according to EDNS0 specifications (RFC 6891, ex RFC 2671) e.g. <i>edns=4096</i>. When EDNS0 is off (<i>noedns</i> or <i>edns=512</i>) 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 <i>edns</i> enabled when using a local recursive DNS server which supports EDNS0 (like most modern DNS servers do), a suitable setting in this case is <i>edns=4096</i>, 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 reac
hable 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 <b>does</b> 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).</p>
+
+<p>Option <i>rotate</i> causes SpamAssassin to choose a DNS server at random from all servers listed in <code>/etc/resolv.conf</code> every <i>dns_test_interval</i> seconds, effectively spreading the load over all currently available DNS servers when there are many spamd workers.</p>
+
+<p>Option <i>dns0x20</i> 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 &quot;dns: no callback for id:&quot; in the log, or if RBL or URIDNS lookups do not work for no apparent reason.</p>
+
+</dd>
+<dt id="dns_query_restriction-allow-deny-domain1-domain2">dns_query_restriction (allow|deny) domain1 domain2 ...</dt>
+<dd>
+
+<p>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 <code>allow</code> or <code>deny</code>, remaining arguments are domains names.</p>
+
+<p>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 <code>allow</code> or <code>deny</code> value then controls whether a DNS query is allowed to be launched.</p>
+
+<p>If no match is found an implicit default is to allow a query. The purpose of an explicit <code>allow</code> entry is to be able to override a previously configured <code>deny</code> 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 &#39;allow zen.spamhaus.org&#39; with a &#39;deny spamhaus.org&#39; would permit DNS queries on a specific DNS BL zone but deny queries to other zones under the same parent domain.</p>
+
+<p>Domains are matched case-insensitively, no wildcards are recognized, there should be no leading or trailing dot.</p>
+
+<p>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.</p>
+
+<p>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</p>
+
+</dd>
+<dt id="clear_dns_query_restriction">clear_dns_query_restriction</dt>
+<dd>
+
+<p>The option removes any entries entered by previous &#39;dns_query_restriction&#39; options, leaving the list empty, i.e. allowing DNS queries for any domain (including any DNS BL zone).</p>
+
+</dd>
+</dl>
+
+<h2 id="LEARNING-OPTIONS">LEARNING OPTIONS</h2>
+
+<dl>
+
+<dt id="use_learner-0-1-default:-1">use_learner ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>Whether to use any machine-learning classifiers with SpamAssassin, such as the default &#39;BAYES_*&#39; rules. Setting this to 0 will disable use of any and all human-trained classifiers.</p>
+
+</dd>
+<dt id="use_bayes-0-1-default:-1">use_bayes ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>Whether to use the naive-Bayesian-style classifier built into SpamAssassin. This is a master on/off switch for all Bayes-related operations.</p>
+
+</dd>
+<dt id="use_bayes_rules-0-1-default:-1">use_bayes_rules ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_auto_learn-0-1-default:-1">bayes_auto_learn ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>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.</p>
+
+<p>See the documentation for the <code>Mail::SpamAssassin::Plugin::AutoLearnThreshold</code> plugin module for details on how Bayes auto-learning is implemented by default.</p>
+
+</dd>
+<dt id="bayes_token_sources-default:-header-visible-invisible-uri">bayes_token_sources (default: header visible invisible uri)</dt>
+<dd>
+
+<p>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: <i>header</i>, <i>visible</i>, <i>invisible</i>, <i>uri</i>, <i>mimepart</i>), each of which may be prefixed by a <i>no</i> to indicate its exclusion. Additionally two reserved keywords are allowed: <i>all</i> and <i>none</i> (or: <i>noall</i>). The list of keywords is processed sequentially: a keyword <i>all</i> adds all available keywords to a set being built, a <i>none</i> or <i>noall</i> clears the set, other non-negated keywords are added to the set, and negated keywords are removed from the set. Keywords are case-insensitive.</p>
+
+<p>The default set is: <i>header</i> <i>visible</i> <i>invisible</i> <i>uri</i>, which is equivalent for example to: <i>All</i> <i>NoMIMEpart</i>. The reason why <i>mimepart</i> 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.</p>
+
+<p>See also option <code>bayes_ignore_header</code> for a fine-grained control on individual header fields under the umbrella of a more general keyword <i>header</i> here.</p>
+
+<p>Keywords imply the following data sources:</p>
+
+<dl>
+
+<dt id="header---tokens-collected-from-a-message-header-section"><i>header</i> - tokens collected from a message header section</dt>
+<dd>
+
+</dd>
+<dt id="visible---words-from-visible-text-plain-or-HTML-in-a-message-body"><i>visible</i> - words from visible text (plain or HTML) in a message body</dt>
+<dd>
+
+</dd>
+<dt id="invisible---hidden-invisible-text-in-HTML-parts-of-a-message-body"><i>invisible</i> - hidden/invisible text in HTML parts of a message body</dt>
+<dd>
+
+</dd>
+<dt id="uri---URIs-collected-from-a-message-body"><i>uri</i> - URIs collected from a message body</dt>
+<dd>
+
+</dd>
+<dt id="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"><i>mimepart</i> - 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</dt>
+<dd>
+
+</dd>
+<dt id="all---adds-all-the-above-keywords-to-the-set-being-assembled"><i>all</i> - adds all the above keywords to the set being assembled</dt>
+<dd>
+
+</dd>
+<dt id="none-or-noall---removes-all-keywords-from-the-set"><i>none</i> or <i>noall</i> - removes all keywords from the set</dt>
+<dd>
+
+</dd>
+</dl>
+
+<p>The <code>bayes_token_sources</code> 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 <code>bayes_token_sources</code> directive(s).</p>
+
+</dd>
+<dt id="bayes_ignore_header-header_name">bayes_ignore_header header_name</dt>
+<dd>
+
+<p>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 &quot;short cut&quot;. To avoid this, list the headers using this setting. Example:</p>
+
+<pre><code> bayes_ignore_header X-Upstream-Spamfilter
+ bayes_ignore_header X-Upstream-SomethingElse</code></pre>
+
+</dd>
+<dt id="bayes_ignore_from-user-example.com">bayes_ignore_from user@example.com</dt>
+<dd>
+
+<p>Bayesian classification and autolearning will not be performed on mail from the listed addresses. Program <code>sa-learn</code> will also ignore the listed addresses if it is invoked using the <code>--use-ignores</code> option. One or more addresses can be listed, see <code>whitelist_from</code>.</p>
+
+<p>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&#39;t send you mail through myriad affiliates.)</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_ignore_to-user-example.com">bayes_ignore_to user@example.com</dt>
+<dd>
+
+<p>Bayesian classification and autolearning will not be performed on mail to the listed addresses. See <code>bayes_ignore_from</code> for details.</p>
+
+</dd>
+<dt id="bayes_min_ham_num-Default:-200">bayes_min_ham_num (Default: 200)</dt>
+<dd>
+
+</dd>
+<dt id="bayes_min_spam_num-Default:-200">bayes_min_spam_num (Default: 200)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_learn_during_report-Default:-1">bayes_learn_during_report (Default: 1)</dt>
+<dd>
+
+<p>The Bayes system will, by default, learn any reported messages (<code>spamassassin -r</code>) as spam. If you do not want this to happen, set this option to 0.</p>
+
+</dd>
+<dt id="bayes_sql_override_username">bayes_sql_override_username</dt>
+<dd>
+
+<p>Used by BayesStore::SQL storage implementation.</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_use_hapaxes-default:-1">bayes_use_hapaxes (default: 1)</dt>
+<dd>
+
+<p>Should the Bayesian classifier use hapaxes (words/tokens that occur only once) when classifying? This produces significantly better hit-rates.</p>
+
+</dd>
+<dt id="bayes_journal_max_size-default:-102400">bayes_journal_max_size (default: 102400)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_expiry_max_db_size-default:-150000">bayes_expiry_max_db_size (default: 150000)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_auto_expire-default:-1">bayes_auto_expire (default: 1)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_token_ttl-default:-3w-i.e.-3-weeks">bayes_token_ttl (default: 3w, i.e. 3 weeks)</dt>
+<dd>
+
+<p>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).</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="bayes_seen_ttl-default:-8d-i.e.-8-days">bayes_seen_ttl (default: 8d, i.e. 8 days)</dt>
+<dd>
+
+<p>Time-to-live / expiration time in seconds for &#39;seen&#39; 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).</p>
+
+<p>If bayes_auto_expire is true and a Bayes datastore backend supports it (currently only Redis), this setting controls deletion of expired &#39;seen&#39; 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.</p>
+
+</dd>
+<dt id="bayes_learn_to_journal-default:-0">bayes_learn_to_journal (default: 0)</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+</dl>
+
+<h2 id="MISCELLANEOUS-OPTIONS">MISCELLANEOUS OPTIONS</h2>
+
+<dl>
+
+<dt id="time_limit-n-default:-300">time_limit n (default: 300)</dt>
+<dd>
+
+<p>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 .</p>
+
+<p>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.</p>
+
+<p>When a message is passed to Mail::SpamAssassin::parse, a deadline time is established as a sum of current time and the <code>time_limit</code> setting.</p>
+
+<p>This deadline may also be specified by a caller through an option &#39;master_deadline&#39; 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 &#39;master_deadline&#39; 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 &#39;master_deadline&#39; option in a call based on its --timeout-child option (or equivalent), unlike the command line <code>spamassassin</code>, which has no such command line option.</p>
+
+<p>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 &#39;on&#39;, 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.</p>
+
+<p>The <code>time_limit</code> 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 &#39;DATA Termination&#39; time limit of 10 minutes, although it is not unusual to see some SMTP clients abort sooner on waiting for a response. A sensible <code>time_limit</code> for a pre-queue filtering setup is maybe 50 seconds, assuming that clients are willing to wait at least a minute.</p>
+
+</dd>
+<dt id="lock_method-type">lock_method type</dt>
+<dd>
+
+<p>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&#39;ll be using for Bayes and AWL storage will never be accessed over NFS, a non-NFS-safe locking system can be selected.</p>
+
+<p>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.</p>
+
+<p>Note that different platforms require different locking systems.</p>
+
+<p>The supported locking systems for <code>type</code> are as follows:</p>
+
+<dl>
+
+<dt id="nfssafe---an-NFS-safe-locking-system"><i>nfssafe</i> - an NFS-safe locking system</dt>
+<dd>
+
+</dd>
+<dt id="flock---simple-UNIX-flock-locking"><i>flock</i> - simple UNIX <code>flock()</code> locking</dt>
+<dd>
+
+</dd>
+<dt id="win32---Win32-locking-using-sysopen-...-O_CREAT-O_EXCL"><i>win32</i> - Win32 locking using <code>sysopen (..., O_CREAT|O_EXCL)</code>.</dt>
+<dd>
+
+</dd>
+</dl>
+
+<p>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.</p>
+
+</dd>
+<dt id="fold_headers-0-1-default:-1">fold_headers ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>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.</p>
+
+<p>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).</p>
+
+</dd>
+<dt id="report_safe_copy_headers-header_name">report_safe_copy_headers header_name ...</dt>
+<dd>
+
+<p>If using <code>report_safe</code>, 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.</p>
+
+</dd>
+<dt id="envelope_sender_header-Name-Of-Header">envelope_sender_header Name-Of-Header</dt>
+<dd>
+
+<p>SpamAssassin will attempt to discover the address used in the &#39;MAIL FROM:&#39; 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 <code>EnvelopeFrom</code> pseudo-header, and for various rules such as SPF checking.</p>
+
+<p>By default, various MTAs will use different headers, such as the following:</p>
+
+<pre><code> X-Envelope-From
+ Envelope-Sender
+ X-Sender
+ Return-Path</code></pre>
+
+<p>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.)</p>
+
+<p>To avoid this heuristic failure, the <code>envelope_sender_header</code> 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.</p>
+
+<p>If the header in question contains <code>&lt;</code> or <code>&gt;</code> characters at the start and end of the email address in the right-hand side, as in the SMTP transaction, these will be stripped.</p>
+
+<p>If the header is not found in a message, or if it&#39;s value does not contain an <code>@</code> sign, SpamAssassin will issue a warning in the logs and fall back to its default heuristics.</p>
+
+<p>(Note for MTA developers: we would prefer if the use of a single header be avoided in future, since that precludes &#39;downstream&#39; spam scanning. <code>http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived</code> details a better proposal, storing the envelope sender at each hop in the <code>Received</code> header.)</p>
+
+<p>example:</p>
+
+<pre><code> envelope_sender_header X-SA-Exim-Mail-From</code></pre>
+
+</dd>
+<dt id="describe-SYMBOLIC_TEST_NAME-description">describe SYMBOLIC_TEST_NAME description ...</dt>
+<dd>
+
+<p>Used to describe a test. This text is shown to users in the detailed report.</p>
+
+<p>Note that test names which begin with &#39;__&#39; are reserved for meta-match sub-rules, and are not scored or listed in the &#39;tests hit&#39; reports.</p>
+
+<p>Also note that by convention, rule descriptions should be limited in length to no more than 50 characters.</p>
+
+</dd>
+<dt id="report_charset-CHARSET-default:-unset">report_charset CHARSET (default: unset)</dt>
+<dd>
+
+<p>Set the MIME Content-Type charset used for the text/plain report which is attached to spam mail messages.</p>
+
+</dd>
+<dt id="report-...some-text-for-a-report">report ...some text for a report...</dt>
+<dd>
+
+<p>Set the report template which is attached to spam mail messages. See the <code>10_default_prefs.cf</code> configuration file in <code>/usr/share/spamassassin</code> for an example.</p>
+
+<p>If you change this, try to keep it under 78 columns. Each <code>report</code> line appends to the existing template, so use <code>clear_report_template</code> to restart.</p>
+
+<p>Tags can be included as explained above.</p>
+
+</dd>
+<dt id="clear_report_template">clear_report_template</dt>
+<dd>
+
+<p>Clear the report template.</p>
+
+</dd>
+<dt id="report_contact-...text-of-contact-address">report_contact ...text of contact address...</dt>
+<dd>
+
+<p>Set what _CONTACTADDRESS_ is replaced with in the above report text. By default, this is &#39;the administrator of that system&#39;, since the hostname of the system the scanner is running on is also included.</p>
+
+</dd>
+<dt id="report_hostname-...hostname-to-use">report_hostname ...hostname to use...</dt>
+<dd>
+
+<p>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.</p>
+
+</dd>
+<dt id="unsafe_report-...some-text-for-a-report">unsafe_report ...some text for a report...</dt>
+<dd>
+
+<p>Set the report template which is attached to spam mail messages which contain a non-text/plain part. See the <code>10_default_prefs.cf</code> configuration file in <code>/usr/share/spamassassin</code> for an example.</p>
+
+<p>Each <code>unsafe-report</code> line appends to the existing template, so use <code>clear_unsafe_report_template</code> to restart.</p>
+
+<p>Tags can be used in this template (see above for details).</p>
+
+</dd>
+<dt id="clear_unsafe_report_template">clear_unsafe_report_template</dt>
+<dd>
+
+<p>Clear the unsafe_report template.</p>
+
+</dd>
+<dt id="mbox_format_from_regex">mbox_format_from_regex</dt>
+<dd>
+
+<p>Set a specific regular expression to be used for mbox file From separators.</p>
+
+<p>For example, this setting will allow sa-learn to process emails stored in a kmail 2 mbox:</p>
+
+<p>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})/</p>
+
+</dd>
+<dt id="parse_dkim_uris-0-1-default:-1">parse_dkim_uris ( 0 | 1 ) (default: 1)</dt>
+<dd>
+
+<p>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)</p>
+
+</dd>
+</dl>
+
+<h1 id="RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</h1>
+
+<p>These settings differ from the ones above, in that they are considered &#39;privileged&#39;. Only users running <code>spamassassin</code> from their procmailrc&#39;s or forward files, or sysadmins editing a file in <code>/etc/mail/spamassassin</code>, can use them. <code>spamd</code> users cannot use them in their <code>user_prefs</code> files, for security and efficiency reasons, unless <code>allow_user_rules</code> is enabled (and then, they may only add rules from below).</p>
+
+<dl>
+
+<dt id="allow_user_rules-0-1-default:-0">allow_user_rules ( 0 | 1 ) (default: 0)</dt>
+<dd>
+
+<p>This setting allows users to create rules (and only rules) in their <code>user_prefs</code> files for use with <code>spamd</code>. It defaults to off, because this could be a severe security hole. It may be possible for users to gain root level access if <code>spamd</code> is run as root. It is NOT a good idea, unless you have some other way of ensuring that users&#39; tests are safe. Don&#39;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 <code>user_prefs</code> file, which could have a significant effect on server load. It is not recommended.</p>
+
+<p>Note that it is not currently possible to use <code>allow_user_rules</code> to modify an existing system rule from a <code>user_prefs</code> file with <code>spamd</code>.</p>
+
+</dd>
+<dt id="redirector_pattern-pattern-modifiers">redirector_pattern /pattern/modifiers</dt>
+<dd>
+
+<p>A regex pattern that matches both the redirector site portion, and the target site portion of a URI.</p>
+
+<p>Note: The target URI portion must be surrounded in parentheses and no other part of the pattern may create a backreference.</p>
+
+<p>Example: http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude</p>
+
+<pre><code> redirector_pattern /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i</code></pre>
+
+</dd>
+<dt id="header-SYMBOLIC_TEST_NAME-header-op-pattern-modifiers-if-unset:-STRING">header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING]</dt>
+<dd>
+
+<p>Define a test. <code>SYMBOLIC_TEST_NAME</code> is a symbolic test name, such as &#39;FROM_ENDS_IN_NUMS&#39;. <code>header</code> is the name of a mail header field, such as &#39;Subject&#39;, &#39;To&#39;, &#39;From&#39;, 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.</p>
+
+<p>Appending a modifier <code>:raw</code> 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 <code>:raw</code> may also be applied to pseudo-headers e.g. <code>ALL:raw</code> will return a pristine (unmodified) header section.</p>
+
+<p>Appending a modifier <code>:addr</code> 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 &#39;From&#39;, &#39;Sender&#39;, &#39;To&#39;, &#39;Cc&#39; along with their &#39;Resent-*&#39; counterparts, and the &#39;Return-Path&#39;.</p>
+
+<p>Appending a modifier <code>:name</code> 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: &#39;From&#39;, &#39;Sender&#39;, along with their &#39;Resent-From&#39; and &#39;Resent-Sender&#39; counterparts.</p>
+
+<p>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 <code>From:addr:raw</code> or <code>From:raw:addr</code> is currently the same as <code>From:addr</code> .</p>
+
+<p>For example, appending <code>:addr</code> to a header name will result in example@foo in all of the following cases:</p>
+
+<dl>
+
+<dt id="example-foo">example@foo</dt>
+<dd>
+
+</dd>
+<dt id="example-foo-Foo-Blah">example@foo (Foo Blah)</dt>
+<dd>
+
+</dd>
+<dt id="example-foo-example-bar">example@foo, example@bar</dt>
+<dd>
+
+</dd>
+<dt id="display:-example-foo-Foo-Blah-example-bar">display: example@foo (Foo Blah), example@bar ;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo">Foo Blah &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo1">&quot;Foo Blah&quot; &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo2">&quot;&#39;Foo Blah&#39;&quot; &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+</dl>
+
+<p>For example, appending <code>:name</code> to a header name will result in &quot;Foo Blah&quot; (without quotes) in all of the following cases:</p>
+
+<dl>
+
+<dt id="example-foo-Foo-Blah1">example@foo (Foo Blah)</dt>
+<dd>
+
+</dd>
+<dt id="example-foo-Foo-Blah-example-bar">example@foo (Foo Blah), example@bar</dt>
+<dd>
+
+</dd>
+<dt id="display:-example-foo-Foo-Blah-example-bar1">display: example@foo (Foo Blah), example@bar ;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo3">Foo Blah &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo4">&quot;Foo Blah&quot; &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+<dt id="Foo-Blah-example-foo5">&quot;&#39;Foo Blah&#39;&quot; &lt;example@foo&gt;</dt>
+<dd>
+
+</dd>
+</dl>
+
+<p>There are several special pseudo-headers that can be specified:</p>
+
+<dl>
+
+<dt id="ALL-can-be-used-to-mean-the-text-of-all-the-messages-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"><code>ALL</code> can be used to mean the text of all the message&#39;s headers. Note that all whitespace inside the headers, at line folds, is currently compressed into a single space (&#39; &#39;) character. To obtain a pristine (unmodified) header section, use <code>ALL:raw</code> - the :raw modifier is documented above. Also similar that return headers added by specific relays: ALL-TRUSTED, ALL-INTERNAL, ALL-UNTRUSTED, ALL-EXTERNAL.</dt>
+<dd>
+
+</dd>
+<dt id="ToCc-can-be-used-to-mean-the-contents-of-both-the-To-and-Cc-headers"><code>ToCc</code> can be used to mean the contents of both the &#39;To&#39; and &#39;Cc&#39; headers.</dt>
+<dd>
+
+</dd>
+<dt id="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"><code>EnvelopeFrom</code> is the address used in the &#39;MAIL FROM:&#39; phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. See <code>envelope_sender_header</code> for more information on how to set this.</dt>
+<dd>
+
+</dd>
+<dt id="MESSAGEID-is-a-symbol-meaning-all-Message-Ids-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"><code>MESSAGEID</code> is a symbol meaning all Message-Id&#39;s found in the message; some mailing list software moves the real &#39;Message-Id&#39; to &#39;Resent-Message-Id&#39; or to &#39;X-Message-Id&#39;, then uses its own one in the &#39;Message-Id&#39; header. The value returned for this symbol is the text from all 3 headers, separated by newlines.</dt>
+<dd>
+
+</dd>
+<dt id="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-messages-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"><code>X-Spam-Relays-Untrusted</code>, <code>X-Spam-Relays-Trusted</code>, <code>X-Spam-Relays-Internal</code> and <code>X-Spam-Relays-External</code> represent a portable, pre-parsed representation of the message&#39;s network path, as recorded in the Received headers, divided into &#39;trusted&#39; vs &#39;untrusted&#39; and &#39;internal&#39; vs &#39;external&#39; sets. See <code>http://wiki.apache.org/spamassassin/TrustedRelays</code> for more details.</dt>
+<dd>
+
+</dd>
+</dl>
+
+<p><code>op</code> is either <code>=~</code> (contains regular expression) or <code>!~</code> (does not contain regular expression), and <code>pattern</code> is a valid Perl regular expression, with <code>modifiers</code> as regexp modifiers in the usual style. Note that multi-line rules are not supported, even if you use <code>x</code> as a modifier. Also note that the <code>#</code> character must be escaped (<code>\#</code>) or else it will be considered to be the start of a comment and not part of the regexp.</p>
+
+<p>If the header specified matches multiple headers, their text will be concatenated with embedded \n&#39;s. Therefore you may wish to use <code>/m</code> if you use <code>^</code> or <code>$</code> in your regular expression.</p>
+
+<p>If the <code>[if-unset: STRING]</code> tag is present, then <code>STRING</code> will be used if the header is not found in the mail message.</p>
+
+<p>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.</p>
+
+<p>Note that test names which begin with &#39;__&#39; are reserved for meta-match sub-rules, and are not scored or listed in the &#39;tests hit&#39; reports. Test names which begin with &#39;T_&#39; are reserved for tests which are undergoing QA, and these are given a very low score.</p>
+
+<p>If you add or modify a test, please be sure to run a sanity check afterwards by running <code>spamassassin --lint</code>. This will avoid confusing error messages, or other tests being skipped as a side-effect.</p>
+
+</dd>
+<dt id="header-SYMBOLIC_TEST_NAME-exists:header_field_name">header SYMBOLIC_TEST_NAME exists:header_field_name</dt>
+<dd>
+
+<p>Define a header field existence test. <code>header_field_name</code> 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 <code>header SYMBOLIC_TEST_NAME header =~ /\S/</code> rule as described above.</p>
+
+</dd>
+<dt id="header-SYMBOLIC_TEST_NAME-eval:name_of_eval_method-arguments">header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])</dt>
+<dd>
+
+<p>Define a header eval test. <code>name_of_eval_method</code> is the name of a method registered by a <code>Mail::SpamAssassin::Plugin</code> object. <code>arguments</code> are optional arguments to the function call.</p>
+
+</dd>
+<dt id="header-SYMBOLIC_TEST_NAME-eval:check_rbl-set-zone-sub-test">header SYMBOLIC_TEST_NAME eval:check_rbl(&#39;set&#39;, &#39;zone&#39; [, &#39;sub-test&#39;])</dt>
+<dd>
+
+<p>Check a DNSBL (a DNS blacklist or whitelist). This will retrieve Received: headers from the message, extract the IP addresses, select which ones are &#39;untrusted&#39; based on the <code>trusted_networks</code> logic, and query that DNSBL zone. There&#39;s a few things to note:</p>
+
+<dl>
+
+<dt id="duplicated-or-private-IPs">duplicated or private IPs</dt>
+<dd>
+
+<p>Duplicated IPs are only queried once and reserved IPs are not queried. Private IPs are those listed in &lt;https://www.iana.org/assignments/ipv4-address-space&gt;, &lt;http://duxcw.com/faq/network/privip.htm&gt;, &lt;http://duxcw.com/faq/network/autoip.htm&gt;, or &lt;https://tools.ietf.org/html/rfc5735&gt; as private.</p>
+
+</dd>
+<dt id="the-set-argument">the &#39;set&#39; argument</dt>
+<dd>
+
+<p>This is used as a &#39;zone ID&#39;. 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.</p>
+
+<p>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.</p>
+
+</dd>
+<dt id="the-zone-argument">the &#39;zone&#39; argument</dt>
+<dd>
+
+<p>This is the root zone of the DNSBL.</p>
+
+<p>The domain name is considered to be a fully qualified domain name (i.e. not subject to DNS resolver&#39;s search or default domain options). No trailing period is needed, and will be removed if specified.</p>
+
+</dd>
+<dt id="the-sub-test-argument">the &#39;sub-test&#39; argument</dt>
+<dd>
+
+<p>This optional argument behaves the same as the sub-test argument in <code>check_rbl_sub()</code> below.</p>
+
+</dd>
+<dt id="selecting-all-IPs-except-for-the-originating-one">selecting all IPs except for the originating one</dt>
+<dd>
+

[... 793 lines stripped ...]