You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by km...@apache.org on 2015/04/29 19:04:11 UTC
svn commit: r1676792 [12/17] - in /spamassassin/site/full/3.4.x: ./ doc/
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TextCat.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TextCat.txt?rev=1676792&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TextCat.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TextCat.txt Wed Apr 29 17:04:09 2015
@@ -0,0 +1,155 @@
+NAME
+ Mail::SpamAssassin::Plugin::TextCat - TextCat language guesser
+
+SYNOPSIS
+ loadplugin Mail::SpamAssassin::Plugin::TextCat
+
+DESCRIPTION
+ This plugin will try to guess the language used in the message body
+ text.
+
+ You can use the "ok_languages" directive to set which languages are
+ considered okay for incoming mail and if the guessed language is not
+ okay, "UNWANTED_LANGUAGE_BODY" is triggered.
+
+ It will always add the results to a "X-Language" name-value pair in the
+ message metadata data structure. This may be useful as Bayes tokens and
+ can also be used in rules for scoring. The results can also be added to
+ marked-up messages using "add_header", with the _LANGUAGES_ tag. See
+ Mail::SpamAssassin::Conf for details.
+
+ Note: the language cannot always be recognized with sufficient
+ confidence. In that case, no action is taken.
+
+USER OPTIONS
+ ok_languages xx [ yy zz ... ] (default: all)
+ This option is used to specify which languages are considered okay
+ for incoming mail. SpamAssassin will try to detect the language used
+ in the message body text.
+
+ Note that the language cannot always be recognized with sufficient
+ confidence. In that case, no action is taken.
+
+ The rule "UNWANTED_LANGUAGE_BODY" is triggered if none of the
+ languages detected are in the "ok" list. Note that this is the only
+ effect of the "ok" list. It does not act as a whitelist against any
+ other form of spam scanning.
+
+ In your configuration, you must use the two or three letter language
+ specifier in lowercase, not the English name for the language. You
+ may also specify "all" if a desired language is not listed, or if
+ you want to allow any language. The default setting is "all".
+
+ Examples:
+
+ ok_languages all (allow all languages)
+ ok_languages en (only allow English)
+ ok_languages en ja zh (allow English, Japanese, and Chinese)
+
+ Note: if there are multiple ok_languages lines, only the last one is
+ used.
+
+ Select the languages to allow from the list below:
+
+ af - Afrikaans
+ am - Amharic
+ ar - Arabic
+ be - Byelorussian
+ bg - Bulgarian
+ bs - Bosnian
+ ca - Catalan
+ cs - Czech
+ cy - Welsh
+ da - Danish
+ de - German
+ el - Greek
+ en - English
+ eo - Esperanto
+ es - Spanish
+ et - Estonian
+ eu - Basque
+ fa - Persian
+ fi - Finnish
+ fr - French
+ fy - Frisian
+ ga - Irish Gaelic
+ gd - Scottish Gaelic
+ he - Hebrew
+ hi - Hindi
+ hr - Croatian
+ hu - Hungarian
+ hy - Armenian
+ id - Indonesian
+ is - Icelandic
+ it - Italian
+ ja - Japanese
+ ka - Georgian
+ ko - Korean
+ la - Latin
+ lt - Lithuanian
+ lv - Latvian
+ mr - Marathi
+ ms - Malay
+ ne - Nepali
+ nl - Dutch
+ no - Norwegian
+ pl - Polish
+ pt - Portuguese
+ qu - Quechua
+ rm - Rhaeto-Romance
+ ro - Romanian
+ ru - Russian
+ sa - Sanskrit
+ sco - Scots
+ sk - Slovak
+ sl - Slovenian
+ sq - Albanian
+ sr - Serbian
+ sv - Swedish
+ sw - Swahili
+ ta - Tamil
+ th - Thai
+ tl - Tagalog
+ tr - Turkish
+ uk - Ukrainian
+ vi - Vietnamese
+ yi - Yiddish
+ zh - Chinese (both Traditional and Simplified)
+ zh.big5 - Chinese (Traditional only)
+ zh.gb2312 - Chinese (Simplified only)
+
+
+
+ inactive_languages xx [ yy zz ... ] (default: see below)
+ This option is used to specify which languages will not be
+ considered when trying to guess the language. For performance
+ reasons, supported languages that have fewer than about 5 million
+ speakers are disabled by default. Note that listing a language in
+ "ok_languages" automatically enables it for that user.
+
+ The default setting is:
+
+ bs cy eo et eu fy ga gd is la lt lv rm sa sco sl yi
+
+ That list is Bosnian, Welsh, Esperanto, Estonian, Basque, Frisian,
+ Irish Gaelic, Scottish Gaelic, Icelandic, Latin, Lithuanian,
+ Latvian, Rhaeto-Romance, Sanskrit, Scots, Slovenian, and Yiddish.
+
+ textcat_max_languages N (default: 3)
+ The maximum number of languages any one message can simultaneously
+ match before its classification is considered unknown.
+
+ textcat_optimal_ngrams N (default: 0)
+ If the number of ngrams is lower than this number then they will be
+ removed. This can be used to speed up the program for longer inputs.
+ For shorter inputs, this should be set to 0.
+
+ textcat_max_ngrams N (default: 400)
+ The maximum number of ngrams that should be compared with each of
+ the languages models (note that each of those models is used
+ completely).
+
+ textcat_acceptable_score N (default: 1.02)
+ Include any language that scores at least "textcat_acceptable_score"
+ in the returned list of languages.
+
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.html?rev=1676792&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.html Wed Apr 29 17:04:09 2015
@@ -0,0 +1,288 @@
+<?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>Mail::SpamAssassin::Plugin::TxRep - Normalize scores with sender reputation records</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">
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#template_tags">TEMPLATE TAGS</a></li>
+ <li><a href="#administrator_settings">ADMINISTRATOR SETTINGS</a></li>
+</ul>
+
+<hr name="index" />
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<h1><a name="name">NAME</a></h1>
+<p>Mail::SpamAssassin::Plugin::TxRep - Normalize scores with sender reputation records</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p>The TxRep (Reputation) plugin is designed as an improved replacement of the AWL
+(Auto-Whitelist) plugin. It adjusts the final message spam score by looking up and
+taking in consideration the reputation of the sender.</p>
+<p>To try TxRep out, you <strong>have to</strong> disable the AWL plugin (if present), back up its
+database and add a line loading this module in init.pre (AWL may be enabled in v310.pre):</p>
+<pre>
+ # loadplugin Mail::SpamAssassin::Plugin::AWL
+ loadplugin Mail::SpamAssassin::Plugin::TxRep</pre>
+<p>When AWL is not disabled, TxRep will refuse to run.</p>
+<p>Use the supplied 60_txreputation.cf file or add these lines to a .cf file:</p>
+<pre>
+ header TXREP eval:check_senders_reputation()
+ describe TXREP Score normalizing based on sender's reputation
+ tflags TXREP userconf noautolearn
+ priority TXREP 1000</pre>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>This plugin is intended to replace the former AWL - AutoWhiteList. Although the
+concept and the scope differ, the purpose remains the same - the normalizing of spam
+score results based on previous sender's history. The name was intentionally changed
+from "whitelist" to "reputation" to avoid any confusion, since the result score can
+be adjusted in both directions.</p>
+<p>The TxRep plugin keeps track of the average SpamAssassin score for senders.
+Senders are tracked using multiple identificators, or their combinations: the From:
+email address, the originating IP and/or an originating block of IPs, sender's domain
+name, the DKIM signature, and the HELO name. TxRep then uses the average score to reduce
+the variability in scoring from message to message, and modifies the final score by
+pushing the result towards the historical average. This improves the accuracy of
+filtering for most email.</p>
+<p>In comparison with the original AWL plugin, several conceptual changes were implemented
+in TxRep:</p>
+<p>1. <strong>Scoring</strong> - at AWL, although it tracks the number of messages received from each
+respective sender, when calculating the corrective score at a new message, it does
+not take it in count in any way. So for example a sender who previously sent a single
+ham message with the score of -5, and then sends a second one with the score of +10,
+AWL will issue a corrective score bringing the score towards the -5. With the default
+<code>auto_whitelist_factor</code> of 0.5, the resulting score would be only 2.5. And it would be
+exactly the same even if the sender previously sent 1,000 messages with the average of
+-5. TxRep tries to take the maximal advantage of the collected data, and adjusts the
+final score not only with the mean reputation score stored in the database, but also
+respecting the number of messages already seen from the sender. You can see the exact
+formula in the section <a href="#c_txrep_factor_"><code>txrep_factor</code></a>.</p>
+<p>2. <strong>Learning</strong> - AWL ignores any spam/ham learning. In fact it acts against it, which
+often leads to a frustrating situation, where a user repeatedly tags all messages of a
+given sender as spam (resp. ham), but at any new message from the sender, AWL will
+adjust the score of the message back to the historical average which does <strong>not</strong> include
+the learned scores. This is now changed at TxRep, and every spam/ham learning will be
+recorded in the reputation database, and hence taken in consideration at future email
+from the respective sender. See the section <a href="#learning_spam___ham">LEARNING SPAM / HAM</a> for more details.</p>
+<p>3. <strong>Auto-Learning</strong> - in certain situations SpamAssassin may declare a message an
+obvious spam resp. ham, and launch the auto-learning process, so that the message can be
+re-evaluated. AWL, by design, did not perform any auto-learning adjustments. This plugin
+will readjust the stored reputation by the value defined by <a href="#c_txrep_learn_penalty_"><code>txrep_learn_penalty</code></a>
+resp. <a href="#c_txrep_learn_bonus_"><code>txrep_learn_bonus</code></a>. Auto-learning score thresholds may be tuned, or the
+auto-learning completely disabled, through the setting <a href="#c_txrep_autolearn_"><code>txrep_autolearn</code></a>.</p>
+<p>4. <strong>Relearning</strong> - messages that were wrongly learned or auto-learned, can be relearned.
+Old reputations are removed from the database, and new ones added instead of them. The
+relearning works better when message tracking is enabled through the
+<a href="#c_txrep_track_messages_"><code>txrep_track_messages</code></a> option. Without it, the relearned score is simply added to
+the reputation, without removing the old ones.</p>
+<p>5. <strong>Aging</strong> - with AWL, any historical record of given sender has the same weight. It
+means that changes in senders behavior, or modified SA rules may take long time, or
+be virtually negated by the AWL normalization, especially at senders with high count
+of past messages, and low recent frequency. It also turns to be particularly
+counterproductive when the administrator detects new patterns in certain messages, and
+applies new rules to better tag such messages as spam or ham. AWL will practically
+eliminate the effect of the new rules, by adjusting the score back towards the (wrong)
+historical average. Only setting the <code>auto_whitelist_factor</code> lower would help, but in
+the same time it would also reduce the overall impact of AWL, and put doubts on its
+purpose. TxRep, besides the <a href="#c_txrep_factor_"><code>txrep_factor</code></a> (replacement of the <code>auto_whitelist_factor</code>),
+introduces also the <a href="#c_txrep_dilution_factor_"><code>txrep_dilution_factor</code></a> to help coping with this issue by
+progressively reducing the impact of past records. More details can be found in the
+description of the factor below.</p>
+<p>6. <strong>Blacklisting and Whitelisting</strong> - when a whitelisting or blacklisting was requested
+through SpamAssassin's API, AWL adjusts the historical total score of the plain email
+address without IP (and deleted records bound to an IP), but since during the reception
+new records with IP will be added, the blacklisted entry would cease acting during
+scanning. TxRep always uses the record of th plain email address without IP together
+with the one bound to an IP address, DKIM signature, or SPF pass (unless the weight
+factor for the EMAIL reputation is set to zero). AWL uses the score of 100 (resp. -100)
+for the blacklisting (resp. whitelisting) purposes. TxRep increases the value
+proportionally to the weight factor of the EMAIL reputation. It is explained in details
+in the section <a href="#blacklisting___whitelisting">BLACKLISTING / WHITELISTING</a>. TxRep can blacklist or whitelist also
+IP addresses, domain names, and dotless HELO names.</p>
+<p>7. <strong>Sender Identification</strong> - AWL identifies a sender on the basis of the email address
+used, and the originating IP address (better told its part defined by the mask setting).
+The main purpose of this measure is to avoid assigning false good scores to spammers who
+spoof known email addresses. The disadvantage appears at senders who send from frequently
+changing locations or even when connecting through dynamical IP addresses that are not
+within the block defined by the mask setting. Their score is difficult or sometimes
+impossible to track. Another disadvantage is, for example, at a spammer persistently
+sending spam from the same IP address, just under different email addresses. AWL will not
+find his previous scores, unless he reuses the same email address again. TxRep uses several
+identificators, and creates separate database entries for each of them. It tracks not only
+the email/IP address combination like AWL, but also the standalone email address (regardless
+of the originating IP), the standalone IP (regardless of email address used), the domain
+name of the email address, the DKIM signature, and the HELO name of the connecting PC. The
+influence of each individual identificator may be tuned up with the help of weight factors
+described in the section <a href="#reputation_weights">REPUTATION WEIGHTS</a>.</p>
+<p>8. <strong>Message Tracking</strong> - TxRep (optionally) keeps track of already scanned and/or learned
+message ID's. This is useful for avoiding to strengthen the reputation score by simply
+rescanning or relearning the same message multiple times. In the same time it also allows
+the proper relearning of once wrongly learned messages, or relearning them after the
+learn penalty or bonus were changed. See the option <a href="#c_txrep_track_messages_"><code>txrep_track_messages</code></a>.</p>
+<p>9. <strong>User and Global Storages</strong> - usually it is recommended to use the per-user setup
+of SpamAssassin, because each user may have quite different requirements, and may receive
+quite different sort of email. Especially when using the Bayesian and AWL plugins,
+the efficiency is much better when SpamAssassin is learned spam and ham separately
+for each user. However, the disadvantage is that senders and emails already learned
+many times by different users, will need to be relearned without any recognized history,
+anytime they arrive to another user. TxRep uses the advantages of both systems. It can
+use dual storages: the global common storage, where all email processed by SpamAssassin
+is recorded, and a local storage separate for each user, with reputation data from his
+email only. See more details at the setting <a href="#c_txrep_user2global_ratio_"><code>txrep_user2global_ratio</code></a>.</p>
+<p>10. <strong>Outbound Whitelisting</strong> - when a local user sends messages to an email address, we
+assume that he needs to see the eventual answer too, hence the recipient's address should
+be whitelisted. When SpamAssassin is used for scanning outgoing email too, when local
+users use the SMTP server where SA is installed, for sending email, and when internal
+networks are defined, TxREP will improve the reputation of all 'To:' and 'CC' addresses
+from messages originating in the internal networks. Details can be found at the setting
+<a href="#c_txrep_whitelist_out_"><code>txrep_whitelist_out</code></a>.</p>
+<p>Both plugins (AWL and TxREP) cannot coexist. It is necessary to disable the AWL to allow
+TxRep running. TxRep reuses the database handling of the original AWL module, and some
+its parameters bound to the database handler modules. By default, TxRep creates its own
+database, but the original auto-whitelist can be reused as a starting point. The AWL
+database can be renamed to the name defined in TxRep settings, and TxRep will start
+using it. The original auto-whitelist database has to be backed up, to allow switching
+back to the original state.</p>
+<p>The spamassassin/Plugin/TxRep.pm file replaces both spamassassin/Plugin/AWL.pm and
+spamassassin/AutoWhitelist.pm. Another two AWL files, spamassassin/DBBasedAddrList.pm
+and spamassassin/SQLBasedAddrList.pm are still needed.</p>
+<p>
+</p>
+<hr />
+<h1><a name="template_tags">TEMPLATE TAGS</a></h1>
+<p>This plugin module adds the following <code>tags</code> that can be used as
+placeholders in certain options. See <a href="/Mail/SpamAssassin/Conf.html">the Mail::SpamAssassin::Conf manpage</a>
+for more information on TEMPLATE TAGS.</p>
+<pre>
+ _TXREP_XXX_Y_ TXREP modifier
+ _TXREP_XXX_Y_MEAN_ Mean score on which TXREP modification is based
+ _TXREP_XXX_Y_COUNT_ Number of messages on which TXREP modification is based
+ _TXREP_XXX_Y_PRESCORE_ Score before TXREP
+ _TXREP_XXX_Y_UNKNOW_ New sender (not found in the TXREP list)</pre>
+<p>The XXX part of the tag takes the form of one of the following IDs, depending
+on the reputation checked: EMAIL, EMAIL_IP, IP, DOMAIN, or HELO. The _Y appendix
+ID is used only in the case of dual storage, and takes the form of either _U (for
+user storage reputations), or _G (for global storage reputations).</p>
+<dl>
+<dt><strong><a name="use_txrep" class="item"><strong>use_txrep</strong></a></strong></dt>
+
+<dd>
+<pre>
+ 0 | 1 (default: 0)</pre>
+<p>Whether to use TxRep reputation system. TxRep tracks the long-term average
+score for each sender and then shifts the score of new messages toward that
+long-term average. This can increase or decrease the score for messages,
+depending on the long-term behavior of the particular correspondent.</p>
+<p>Note that certain tests are ignored when determining the final message score:</p>
+<pre>
+ - rules with tflags set to 'noautolearn'</pre>
+</dd>
+<dt><strong><a name="txrep_spf" class="item"><strong>txrep_spf</strong></a></strong></dt>
+
+<dd>
+<pre>
+ 0 | 1 (default: 1)</pre>
+<p>When enabled, TxRep will treat any IP address using a given email address as
+the same authorized identity, and will not associate any IP address with it.
+(The same happens with valid DKIM signatures. No option available for DKIM).</p>
+<p>Note: at domains that define the useless SPF +all (pass all), no IP would be
+ever associated with the email address, and all addresses (incl. the froged
+ones) would be treated as coming from the authorized source. However, such
+domains are hopefuly rare, and ask for this kind of treatment anyway.</p>
+</dd>
+</dl>
+<ol>
+<li><strong><a name="fraction" class="item">) The reputation of the 'From' email address bound to the originating IP
+ address fraction (see the mask parameters for details)</a></strong>
+
+</li>
+<li><strong><a name="alone" class="item">) The reputation of the 'From' email address alone (regardless the IP
+ address being currently used)</a></strong>
+
+</li>
+<li><strong><a name="the_reputation_of_the_domain_name_of_the_from_email_address" class="item">) The reputation of the domain name of the 'From' email address</a></strong>
+
+</li>
+<li><strong><a name="the_reputation_of_the_originating_ip_address_regardless_of_sender_s_email_address" class="item">) The reputation of the originating IP address, regardless of sender's email address</a></strong>
+
+</li>
+<li><strong><a name="computer" class="item">) The reputation of the HELO name of the originating computer (if available)</a></strong>
+
+</li>
+</ol>
+<p>Each of these partial reputations is weighted with the help of these parameters,
+and the overall reputation is calculation as the sum of the individual
+reputations divided by the sum of all their weights:</p>
+<pre>
+ sender_reputation = weight_email * rep_email +
+ weight_email_ip * rep_email_ip +
+ weight_domain * rep_domain +
+ weight_ip * rep_ip +
+ weight_helo * rep_helo</pre>
+<p>You can disable the individual partial reputations by setting their respective
+weight to zero. This will also reduce the size of the database, since each
+partial reputation requires a separate entry in the database table. Disabling
+some of the partial reputations in this way may also help with the performance
+on busy servers, because the respective database lookups and processing will
+be skipped too.</p>
+<dl>
+<dt><strong><a name="txrep_weight_email" class="item"><strong>txrep_weight_email</strong></a></strong></dt>
+
+<dd>
+<pre>
+ range [0..10] (default: 3)</pre>
+<p>This weight factor controls the influence of the reputation of the standalone
+email address, regardless of the originating IP address. When adjusting the
+weight, you need to keep on mind that an email address can be easily spoofed,
+and hence spammers can use 'from' email addresses belonging to senders with
+good reputation. From this point of view, the email address bound to the
+originating IP address is a more reliable indicator for the overall reputation.</p>
+<p>On the other hand, some reputable senders may be sending from a bigger number
+of IP addresses, so looking for the reputation of the standalone email address
+without regarding the originating IP has some sense too.</p>
+<p>We recommend using a relatively low value for this partial reputation.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="administrator_settings">ADMINISTRATOR SETTINGS</a></h1>
+<p>These settings differ from the ones above, in that they are considered 'more
+privileged' -- even more than the ones in the <strong>PRIVILEGED SETTINGS</strong> section.
+No matter what <code>allow_user_rules</code> is set to, these can never be set from a
+user's <code>user_prefs</code> file.</p>
+<dl>
+<dt><strong><a name="txrep_factory_module" class="item"><strong>txrep_factory module</strong></a></strong></dt>
+
+<dd>
+<pre>
+ (default: Mail::SpamAssassin::DBBasedAddrList)</pre>
+<p>Select alternative database factory module for the TxRep database.</p>
+</dd>
+</dl>
+
+</body>
+
+</html>
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.txt?rev=1676792&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_TxRep.txt Wed Apr 29 17:04:09 2015
@@ -0,0 +1,803 @@
+NAME
+ Mail::SpamAssassin::Plugin::TxRep - Normalize scores with sender
+ reputation records
+
+SYNOPSIS
+ The TxRep (Reputation) plugin is designed as an improved replacement of
+ the AWL (Auto-Whitelist) plugin. It adjusts the final message spam score
+ by looking up and taking in consideration the reputation of the sender.
+
+ To try TxRep out, you have to disable the AWL plugin (if present), back
+ up its database and add a line loading this module in init.pre (AWL may
+ be enabled in v310.pre):
+
+ # loadplugin Mail::SpamAssassin::Plugin::AWL
+ loadplugin Mail::SpamAssassin::Plugin::TxRep
+
+ When AWL is not disabled, TxRep will refuse to run.
+
+ Use the supplied 60_txreputation.cf file or add these lines to a .cf
+ file:
+
+ header TXREP eval:check_senders_reputation()
+ describe TXREP Score normalizing based on sender's reputation
+ tflags TXREP userconf noautolearn
+ priority TXREP 1000
+
+DESCRIPTION
+ This plugin is intended to replace the former AWL - AutoWhiteList.
+ Although the concept and the scope differ, the purpose remains the same
+ - the normalizing of spam score results based on previous sender's
+ history. The name was intentionally changed from "whitelist" to
+ "reputation" to avoid any confusion, since the result score can be
+ adjusted in both directions.
+
+ The TxRep plugin keeps track of the average SpamAssassin score for
+ senders. Senders are tracked using multiple identificators, or their
+ combinations: the From: email address, the originating IP and/or an
+ originating block of IPs, sender's domain name, the DKIM signature, and
+ the HELO name. TxRep then uses the average score to reduce the
+ variability in scoring from message to message, and modifies the final
+ score by pushing the result towards the historical average. This
+ improves the accuracy of filtering for most email.
+
+ In comparison with the original AWL plugin, several conceptual changes
+ were implemented in TxRep:
+
+ 1. Scoring - at AWL, although it tracks the number of messages received
+ from each respective sender, when calculating the corrective score at a
+ new message, it does not take it in count in any way. So for example a
+ sender who previously sent a single ham message with the score of -5,
+ and then sends a second one with the score of +10, AWL will issue a
+ corrective score bringing the score towards the -5. With the default
+ "auto_whitelist_factor" of 0.5, the resulting score would be only 2.5.
+ And it would be exactly the same even if the sender previously sent
+ 1,000 messages with the average of -5. TxRep tries to take the maximal
+ advantage of the collected data, and adjusts the final score not only
+ with the mean reputation score stored in the database, but also
+ respecting the number of messages already seen from the sender. You can
+ see the exact formula in the section ""txrep_factor"".
+
+ 2. Learning - AWL ignores any spam/ham learning. In fact it acts against
+ it, which often leads to a frustrating situation, where a user
+ repeatedly tags all messages of a given sender as spam (resp. ham), but
+ at any new message from the sender, AWL will adjust the score of the
+ message back to the historical average which does not include the
+ learned scores. This is now changed at TxRep, and every spam/ham
+ learning will be recorded in the reputation database, and hence taken in
+ consideration at future email from the respective sender. See the
+ section "LEARNING SPAM / HAM" for more details.
+
+ 3. Auto-Learning - in certain situations SpamAssassin may declare a
+ message an obvious spam resp. ham, and launch the auto-learning process,
+ so that the message can be re-evaluated. AWL, by design, did not perform
+ any auto-learning adjustments. This plugin will readjust the stored
+ reputation by the value defined by ""txrep_learn_penalty"" resp.
+ ""txrep_learn_bonus"". Auto-learning score thresholds may be tuned, or
+ the auto-learning completely disabled, through the setting
+ ""txrep_autolearn"".
+
+ 4. Relearning - messages that were wrongly learned or auto-learned, can
+ be relearned. Old reputations are removed from the database, and new
+ ones added instead of them. The relearning works better when message
+ tracking is enabled through the ""txrep_track_messages"" option. Without
+ it, the relearned score is simply added to the reputation, without
+ removing the old ones.
+
+ 5. Aging - with AWL, any historical record of given sender has the same
+ weight. It means that changes in senders behavior, or modified SA rules
+ may take long time, or be virtually negated by the AWL normalization,
+ especially at senders with high count of past messages, and low recent
+ frequency. It also turns to be particularly counterproductive when the
+ administrator detects new patterns in certain messages, and applies new
+ rules to better tag such messages as spam or ham. AWL will practically
+ eliminate the effect of the new rules, by adjusting the score back
+ towards the (wrong) historical average. Only setting the
+ "auto_whitelist_factor" lower would help, but in the same time it would
+ also reduce the overall impact of AWL, and put doubts on its purpose.
+ TxRep, besides the ""txrep_factor"" (replacement of the
+ "auto_whitelist_factor"), introduces also the ""txrep_dilution_factor""
+ to help coping with this issue by progressively reducing the impact of
+ past records. More details can be found in the description of the factor
+ below.
+
+ 6. Blacklisting and Whitelisting - when a whitelisting or blacklisting
+ was requested through SpamAssassin's API, AWL adjusts the historical
+ total score of the plain email address without IP (and deleted records
+ bound to an IP), but since during the reception new records with IP will
+ be added, the blacklisted entry would cease acting during scanning.
+ TxRep always uses the record of th plain email address without IP
+ together with the one bound to an IP address, DKIM signature, or SPF
+ pass (unless the weight factor for the EMAIL reputation is set to zero).
+ AWL uses the score of 100 (resp. -100) for the blacklisting (resp.
+ whitelisting) purposes. TxRep increases the value proportionally to the
+ weight factor of the EMAIL reputation. It is explained in details in the
+ section "BLACKLISTING / WHITELISTING". TxRep can blacklist or whitelist
+ also IP addresses, domain names, and dotless HELO names.
+
+ 7. Sender Identification - AWL identifies a sender on the basis of the
+ email address used, and the originating IP address (better told its part
+ defined by the mask setting). The main purpose of this measure is to
+ avoid assigning false good scores to spammers who spoof known email
+ addresses. The disadvantage appears at senders who send from frequently
+ changing locations or even when connecting through dynamical IP
+ addresses that are not within the block defined by the mask setting.
+ Their score is difficult or sometimes impossible to track. Another
+ disadvantage is, for example, at a spammer persistently sending spam
+ from the same IP address, just under different email addresses. AWL will
+ not find his previous scores, unless he reuses the same email address
+ again. TxRep uses several identificators, and creates separate database
+ entries for each of them. It tracks not only the email/IP address
+ combination like AWL, but also the standalone email address (regardless
+ of the originating IP), the standalone IP (regardless of email address
+ used), the domain name of the email address, the DKIM signature, and the
+ HELO name of the connecting PC. The influence of each individual
+ identificator may be tuned up with the help of weight factors described
+ in the section "REPUTATION WEIGHTS".
+
+ 8. Message Tracking - TxRep (optionally) keeps track of already scanned
+ and/or learned message ID's. This is useful for avoiding to strengthen
+ the reputation score by simply rescanning or relearning the same message
+ multiple times. In the same time it also allows the proper relearning of
+ once wrongly learned messages, or relearning them after the learn
+ penalty or bonus were changed. See the option ""txrep_track_messages"".
+
+ 9. User and Global Storages - usually it is recommended to use the
+ per-user setup of SpamAssassin, because each user may have quite
+ different requirements, and may receive quite different sort of email.
+ Especially when using the Bayesian and AWL plugins, the efficiency is
+ much better when SpamAssassin is learned spam and ham separately for
+ each user. However, the disadvantage is that senders and emails already
+ learned many times by different users, will need to be relearned without
+ any recognized history, anytime they arrive to another user. TxRep uses
+ the advantages of both systems. It can use dual storages: the global
+ common storage, where all email processed by SpamAssassin is recorded,
+ and a local storage separate for each user, with reputation data from
+ his email only. See more details at the setting
+ ""txrep_user2global_ratio"".
+
+ 10. Outbound Whitelisting - when a local user sends messages to an email
+ address, we assume that he needs to see the eventual answer too, hence
+ the recipient's address should be whitelisted. When SpamAssassin is used
+ for scanning outgoing email too, when local users use the SMTP server
+ where SA is installed, for sending email, and when internal networks are
+ defined, TxREP will improve the reputation of all 'To:' and 'CC'
+ addresses from messages originating in the internal networks. Details
+ can be found at the setting ""txrep_whitelist_out"".
+
+ Both plugins (AWL and TxREP) cannot coexist. It is necessary to disable
+ the AWL to allow TxRep running. TxRep reuses the database handling of
+ the original AWL module, and some its parameters bound to the database
+ handler modules. By default, TxRep creates its own database, but the
+ original auto-whitelist can be reused as a starting point. The AWL
+ database can be renamed to the name defined in TxRep settings, and TxRep
+ will start using it. The original auto-whitelist database has to be
+ backed up, to allow switching back to the original state.
+
+ The spamassassin/Plugin/TxRep.pm file replaces both
+ spamassassin/Plugin/AWL.pm and spamassassin/AutoWhitelist.pm. Another
+ two AWL files, spamassassin/DBBasedAddrList.pm and
+ spamassassin/SQLBasedAddrList.pm are still needed.
+
+TEMPLATE TAGS
+ This plugin module adds the following "tags" that can be used as
+ placeholders in certain options. See Mail::SpamAssassin::Conf for more
+ information on TEMPLATE TAGS.
+
+ _TXREP_XXX_Y_ TXREP modifier
+ _TXREP_XXX_Y_MEAN_ Mean score on which TXREP modification is based
+ _TXREP_XXX_Y_COUNT_ Number of messages on which TXREP modification is based
+ _TXREP_XXX_Y_PRESCORE_ Score before TXREP
+ _TXREP_XXX_Y_UNKNOW_ New sender (not found in the TXREP list)
+
+ The XXX part of the tag takes the form of one of the following IDs,
+ depending on the reputation checked: EMAIL, EMAIL_IP, IP, DOMAIN, or
+ HELO. The _Y appendix ID is used only in the case of dual storage, and
+ takes the form of either _U (for user storage reputations), or _G (for
+ global storage reputations).
+
+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.
+
+ use_txrep
+ 0 | 1 (default: 0)
+
+ Whether to use TxRep reputation system. TxRep tracks the long-term
+ average score for each sender and then shifts the score of new
+ messages toward that long-term average. This can increase or
+ decrease the score for messages, depending on the long-term behavior
+ of the particular correspondent.
+
+ Note that certain tests are ignored when determining the final
+ message score:
+
+ - rules with tflags set to 'noautolearn'
+
+ txrep_factor
+ range [0..1] (default: 0.5)
+
+ How much towards the long-term mean for the sender to regress a
+ message. Basically, the algorithm is to track the long-term total
+ score and the count of messages for the sender ("total" and
+ "count"), and then once we have otherwise fully calculated the score
+ for this message ("score"), we calculate the final score for the
+ message as:
+
+ finalscore = score + factor * (total + score)/(count + 1)
+
+ So if "factor" = 0.5, then we'll move to half way between the
+ calculated score and the new mean value. If "factor" = 0.3, then
+ we'll move about 1/3 of the way from the score toward the mean.
+ "factor" = 1 means use the long-term mean including also the new
+ unadjusted score; "factor" = 0 mean just use the calculated score,
+ disabling so the score averaging, though still recording the
+ reputation to the database.
+
+ txrep_dilution_factor
+ range [0.7..1.0] (default: 0.98)
+
+ At any new email from given sender, the historical reputation
+ records are "diluted", or "watered down" by certain fraction given
+ by this factor. It means that the influence of old records will
+ progressively diminish with every new message from given sender.
+ This is important to allow a more flexible handling of changes in
+ sender's behavior, or new improvements or changes of local SA rules.
+
+ Without any dilution expiry (dilution factor set to 1), the new
+ message score is simply add to the total score of given sender in
+ the reputation database. When dilution is used (factor < 1), the
+ impact of the historical reputation average is reduced by the factor
+ before calculating the new average, which in turn is then used to
+ adjust the new total score to be stored in the database.
+
+ newtotal = (oldcount + 1) * (newscore + dilution * oldtotal) / (dilution * oldcount + 1)
+
+ In other words, it means that the older a message is, the less and
+ less impact on the new average its original spam score has. For
+ example if we set the factor to 0.9 (meaning dilution by 10%), the
+ score of the new message will be recorded to its 100%, the last
+ score of the same sender to 90%, the second last to 81% (0.9 * 0.9 =
+ 0.81), and for example the 10th last message just to 35%.
+
+ At stable systems, we recommend keeping the factor close to 1 (but
+ still lower than 1). At systems where SA rules tuning and spam
+ learning is still in progress, lower factors will help the
+ reputation to quicker adapt any modifications. In the same time, it
+ will also reduce the impact of the historical reputation though.
+
+ txrep_learn_penalty
+ range [0..200] (default: 20)
+
+ When SpamAssassin is trained a SPAM message, the given penalty score
+ will be added to the total reputation score of the sender,
+ regardless of the real spam score. The impact of the penalty will be
+ the smaller the higher is the number of messages that the sender
+ already has in the TxRep database.
+
+ txrep_learn_bonus
+ range [0..200] (default: 20)
+
+ When SpamAssassin is trained a HAM message, the given penalty score
+ will be deduced from the total reputation score of the sender,
+ regardless of the real spam score. The impact of the penalty will be
+ the smaller the higher is the number of messages that the sender
+ already has in the TxRep database.
+
+ txrep_autolearn
+ range [0..5] (default: 0)
+
+ When SpamAssassin declares a message a clear spam resp. ham during
+ the mesage scan, and launches the auto-learn process, sender
+ reputation scores of given message will be adjusted by the value of
+ the option ""txrep_learn_penalty"", resp. the ""txrep_learn_bonus""
+ in the same way as during the manual learning. Value 0 at this
+ option disables the auto-learn reputation adjustment - only the
+ score calculated before the auto-learn will be stored to the
+ reputation database.
+
+ txrep_track_messages
+ 0 | 1 (default: 1)
+
+ Whether TxRep should keep track of already scanned and/or learned
+ messages. When enabled, an additional record in the reputation
+ database will be created to avoid false score adjustments due to
+ repeated scanning of the same message, and to allow proper
+ relearning of messages that were either previously wrongly learned,
+ or need to be relearned after modifying the learn penalty or bonus.
+
+ txrep_whitelist_out
+ range [0..200] (default: 10)
+
+ When the value of this setting is greater than zero, recipients of
+ messages sent from within the internal networks will be whitelisted
+ through improving their total reputation score with the number of
+ points defined by this setting. Since the IP address and other
+ sender identificators are not known when sending the email, only the
+ reputation of the standalone email is being whitelisted. The domain
+ name is intentionally also left unaffected. The outbound
+ whitelisting can only work when SpamAssassin is set up to scan also
+ outgoing email, when local users use the SMTP server for sending
+ email, and when "internal_networks" are defined in SpamAssassin
+ configuration. The improving of the reputation happens at every
+ message sent from internal networks, so the more messages is being
+ sent to the recipient, the better reputation his email address will
+ have.
+
+ txrep_ipv4_mask_len
+ range [0..32] (default: 16)
+
+ The AWL database keeps only the specified number of most-significant
+ bits of an IPv4 address in its fields, so that different individual
+ IP addresses within a subnet belonging to the same owner are managed
+ under a single database record. As we have no information available
+ on the allocated address ranges of senders, this CIDR mask length is
+ only an approximation. The default is 16 bits, corresponding to a
+ former class B. Increase the number if a finer granularity is
+ desired, e.g. to 24 (class C) or 32. A value 0 is allowed but is not
+ particularly useful, as it would treat the whole internet as a
+ single organization. The number need not be a multiple of 8, any
+ split is allowed.
+
+ txrep_ipv6_mask_len
+ range [0..128] (default: 48)
+
+ The AWL database keeps only the specified number of most-significant
+ bits of an IPv6 address in its fields, so that different individual
+ IP addresses within a subnet belonging to the same owner are managed
+ under a single database record. As we have no information available
+ on the allocated address ranges of senders, this CIDR mask length is
+ only an approximation. The default is 48 bits, corresponding to an
+ address range commonly allocated to individual (smaller)
+ organizations. Increase the number for a finer granularity, e.g. to
+ 64 or 96 or 128, or decrease for wider ranges, e.g. 32. A value 0 is
+ allowed but is not particularly useful, as it would treat the whole
+ internet as a single organization. The number need not be a multiple
+ of 4, any split is allowed.
+
+ user_awl_sql_override_username
+ string (default: undefined)
+
+ Used by the SQLBasedAddrList storage implementation.
+
+ If this option is set the SQLBasedAddrList module will override the
+ set username with the value given. This can be useful for
+ implementing global or group based TxRep databases.
+
+ txrep_user2global_ratio
+ range [0..10] (default: 0)
+
+ When the option txrep_user2global_ratio is set to a value greater
+ than zero, and if the server configuration allows it, two data
+ storages will be used - user and global (server-wide) storages.
+
+ User storage keeps only senders who send messages to the respective
+ recipient, and will reflect also the corrected/learned scores, when
+ some messages are marked by the user as spam or ham, or when the
+ sender is whitelisted or blacklisted through the API of
+ SpamAssassin.
+
+ Global storage keeps the reputation data of all messages processed
+ by SpamAssassin with their spam scores and spam/ham learning data
+ from all users on the server. Hence, the module will return a
+ reputation value even at senders not known to the current recipient,
+ as long as he already sent email to anyone else on the server.
+
+ The value of the txrep_user2global_ratio parameter controls the
+ impact of each of the two reputations. When equal to 1, both the
+ global and the user score will have the same impact on the result.
+ When set to 2, the reputation taken from the user storage will have
+ twice the impact of the global value. The final value of the TXREP
+ tag will be calculated as follows:
+
+ total = ( ratio * user + global ) / ( ratio + 1 )
+
+ When no reputation is found in the user storage, and a global
+ reputation is available, the global storage is used fully, without
+ applying the ratio.
+
+ When the ratio is set to zero, only the default storage will be
+ used. And it then depends whether you use the global, or the local
+ user storage by default, which in turn is controlled either by the
+ parameter user_awl_sql_override_username (in case of SQL storage),
+ or the "/auto_whitelist_path" parameter (in case of Berkeley
+ database).
+
+ When this dual storage is enabled, and no global storage is defined
+ by the above mentioned parameters for the Berkeley or SQL databases,
+ TxRep will attempt to use a generic storage - user 'GLOBAL' in case
+ of SQL, and in the case of Berkeley database it uses the path
+ defined by '__local_state_dir__/tx-reputation', which typically
+ renders into /var/db/spamassassin/tx-reputation. When the default
+ storages are not available, or are not writable, you would have to
+ set the global storage with the help of the
+ "user_awl_sql_override_username" resp. "auto_whitelist_path
+ settings".
+
+ Please note that some SpamAssassin installations run always under
+ the same user ID. In such case it is pointless enabling the dual
+ storage, because it would maximally lead to two identical global
+ storages in different locations.
+
+ This feature is disabled by default.
+
+ auto_whitelist_distinguish_signed
+ (default: 1 - enabled)
+
+ Used by the SQLBasedAddrList storage implementation.
+
+ If this option is set the SQLBasedAddrList module will keep separate
+ database entries for DKIM-validated e-mail addresses and for
+ non-validated ones. A pre-requisite when setting this option is that
+ a field awl.signedby exists in a SQL table, otherwise SQL operations
+ will fail (which is why we need this option at all - for
+ compatibility with pre-3.3.0 database schema). A plugin DKIM should
+ also be enabled, as otherwise there is no benefit from turning on
+ this option.
+
+ txrep_spf
+ 0 | 1 (default: 1)
+
+ When enabled, TxRep will treat any IP address using a given email
+ address as the same authorized identity, and will not associate any
+ IP address with it. (The same happens with valid DKIM signatures. No
+ option available for DKIM).
+
+ Note: at domains that define the useless SPF +all (pass all), no IP
+ would be ever associated with the email address, and all addresses
+ (incl. the froged ones) would be treated as coming from the
+ authorized source. However, such domains are hopefuly rare, and ask
+ for this kind of treatment anyway.
+
+ REPUTATION WEIGHTS
+ The overall reputation of the sender comprises several elements:
+
+ 1) The reputation of the 'From' email address bound to the originating
+ IP address fraction (see the mask parameters for details)
+ 2) The reputation of the 'From' email address alone (regardless the IP
+ address being currently used)
+ 3) The reputation of the domain name of the 'From' email address
+ 4) The reputation of the originating IP address, regardless of sender's
+ email address
+ 5) The reputation of the HELO name of the originating computer (if
+ available)
+
+ Each of these partial reputations is weighted with the help of these
+ parameters, and the overall reputation is calculation as the sum of the
+ individual reputations divided by the sum of all their weights:
+
+ sender_reputation = weight_email * rep_email +
+ weight_email_ip * rep_email_ip +
+ weight_domain * rep_domain +
+ weight_ip * rep_ip +
+ weight_helo * rep_helo
+
+ You can disable the individual partial reputations by setting their
+ respective weight to zero. This will also reduce the size of the
+ database, since each partial reputation requires a separate entry in the
+ database table. Disabling some of the partial reputations in this way
+ may also help with the performance on busy servers, because the
+ respective database lookups and processing will be skipped too.
+
+ txrep_weight_email
+ range [0..10] (default: 3)
+
+ This weight factor controls the influence of the reputation of the
+ standalone email address, regardless of the originating IP address.
+ When adjusting the weight, you need to keep on mind that an email
+ address can be easily spoofed, and hence spammers can use 'from'
+ email addresses belonging to senders with good reputation. From this
+ point of view, the email address bound to the originating IP address
+ is a more reliable indicator for the overall reputation.
+
+ On the other hand, some reputable senders may be sending from a
+ bigger number of IP addresses, so looking for the reputation of the
+ standalone email address without regarding the originating IP has
+ some sense too.
+
+ We recommend using a relatively low value for this partial
+ reputation.
+
+ txrep_weight_email_ip
+ range [0..10] (default: 10)
+
+ This is the standard reputation used in the same way as it was by
+ the original AWL plugin. Each sender's email address is bound to the
+ originating IP, or its part as defined by the txrep_ipv4_mask_len or
+ txrep_ipv6_mask_len parameters.
+
+ At a user sending from multiple locations, diverse mail servers, or
+ from a dynamic IP range out of the masked block, his email address
+ will have a separate reputation value for each of the different
+ (partial) IP addresses.
+
+ When the option auto_whitelist_distinguish_signed is enabled, in
+ contrary to the original AWL module, TxRep does not record the IP
+ address when DKIM signature is detected. The email address is then
+ not bound to any IP address, but rather just to the DKIM signature,
+ since it is considered that it authenticates the sender more
+ reliably than the IP address (which can also vary).
+
+ This is by design the most relevant reputation, and its weight
+ should be kept high.
+
+ txrep_weight_domain
+ range [0..10] (default: 2)
+
+ Some spammers may use always their real domain name in the email
+ address, just with multiple or changing local parts. This reputation
+ will record the spam scores of all messages send from the respective
+ domain, regardless of the local part (user name) used.
+
+ Similarly as with the email_ip reputation, the domain reputation is
+ also bound to the originating address (or a masked block, if mask
+ parameters used). It avoids giving false reputation based on spoofed
+ email addresses.
+
+ In case of a DKIM signature detected, the signature signer is used
+ instead of the domain name extracted from the email address. It is
+ considered that the signing authority is responsible for sending
+ email of any domain name, hence the same reputation applies here.
+
+ The domain reputation will give relevant picture about the owner of
+ the domain in case of small servers, or corporation with strict
+ policies, but will be less relevant for freemailers like Gmail,
+ Hotmail, and similar, because both ham and spam may be sent by their
+ users.
+
+ The default value is set relatively low. Higher weight values may be
+ useful, but we recommend caution and observing the scores before
+ increasing it.
+
+ txrep_weight_ip
+ range [0..10] (default: 4)
+
+ Spammers can send through the same relay (incl. compromised hosts)
+ under a multitude of email addresses. This is the exact case when
+ the IP reputation can help. This reputation is a kind of a local
+ RBL.
+
+ The weight is set by default lower than for the email_IP reputation,
+ because there may be cases when the same IP address hosts both
+ spammers and acceptable senders (for example the marketing
+ department of a company sends you spam, but you still need to get
+ messages from their billing address).
+
+ txrep_weight_helo
+ range [0..10] (default: 0.5)
+
+ Big number of spam messages come from compromised hosts, often
+ personal computers, or top-boxes. Their NetBIOS names are usually
+ used as the HELO name when connecting to your mail server. Some of
+ the names are pretty generic and hence may be shared by a big number
+ of hosts, but often the names are quite unique and may be a good
+ indicator for detecting a spammer, despite that he uses different
+ email and IP addresses (spam can come also from portable devices).
+
+ No IP address is bound to the HELO name when stored to the
+ reputation database. This is intentional, and despite the
+ possibility that numerous devices may share some of the HELO names.
+
+ This option is still considered experimental, hence the low weight
+ value, but after some testing it could be likely at least slightly
+ increased.
+
+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.
+
+ txrep_factory module
+ (default: Mail::SpamAssassin::DBBasedAddrList)
+
+ Select alternative database factory module for the TxRep database.
+
+ auto_whitelist_path /path/filename
+ (default: ~/.spamassassin/tx-reputation)
+
+ This is the TxRep directory and filename. By default, each user has
+ their own reputation database in their "~/.spamassassin" directory
+ with mode 0700. For system-wide SpamAssassin use, you may want to
+ share this across all users.
+
+ auto_whitelist_db_modules Module ...
+ (default: see below)
+
+ What database modules should be used for the TxRep storage database
+ file. The first named module that can be loaded from the Perl
+ include path will be used. The format is:
+
+ PreferredModuleName SecondBest ThirdBest ...
+
+ ie. a space-separated list of Perl module names. The default is:
+
+ DB_File GDBM_File SDBM_File
+
+ NDBM_File is not supported (see SpamAssassin bug 4353).
+
+ auto_whitelist_file_mode
+ (default: 0700)
+
+ The file mode bits used for the TxRep directory or file.
+
+ 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 0111).
+
+ user_awl_dsn DBI:databasetype:databasename:hostname:port
+ Used by the SQLBasedAddrList storage implementation.
+
+ This will set the DSN used to connect. Example:
+ "DBI:mysql:spamassassin:localhost"
+
+ user_awl_sql_username username
+ Used by the SQLBasedAddrList storage implementation.
+
+ The authorized username to connect to the above DSN.
+
+ user_awl_sql_password password
+ Used by the SQLBasedAddrList storage implementation.
+
+ The password for the database username, for the above DSN.
+
+ user_awl_sql_table tablename
+ (default: txrep)
+
+ Used by the SQLBasedAddrList storage implementation.
+
+ The table name where reputation is to be stored in, for the above
+ DSN.
+
+BLACKLISTING / WHITELISTING
+ When asked by SpamAssassin to blacklist or whitelist a user, the TxRep
+ plugin adds a score of 100 (for blacklisting) or -100 (for whitelisting)
+ to the given sender's email address. At a plain address without any IP
+ address, the value is multiplied by the ratio of total reputation weight
+ to the EMAIL reputation weight to account for the reduced impact of the
+ standalone EMAIL reputation when calculating the overall reputation.
+
+ total_weight = weight_email + weight_email_ip + weight_domain + weight_ip + weight_helo
+ blacklisted_reputation = 100 * total_weight / weight_email
+
+ When a standalone email address is blacklisted/whitelisted, all records
+ of the email address bound to an IP address, DKIM signature, or a SPF
+ pass will be removed from the database, and only the standalone record
+ is kept.
+
+ Besides blacklisting/whitelisting of standalone email addresses, the
+ same method may be used also for blacklisting/whitelisting of IP
+ addresses, domain names, and HELO names (only dotless Netbios HELO names
+ can be used).
+
+ When whitelisting/blacklisting an email address or domain name, you can
+ bind them to a specified DKIM signature or SPF record by appending the
+ DKIM signing domain or the tag 'spf' after the ID in the following way:
+
+ spamassassin --add-addr-to-blacklist=spamming.biz,spf
+ spamassassin --add-addr-to-whitelist=friend@good.org,good.org
+
+ When a message contains both a DKIM signature and an SPF pass, the DKIM
+ signature takes the priority, so the record bound to the 'spf' tag won't
+ be checked. Only email addresses and domains can be bound to DKIM or
+ SPF. Records of IP adresses and HELO names are always without DKIM/SPF.
+
+ In case of dual storage, the black/whitelisting is performed only in the
+ default storage.
+
+REPUTATION LOGICS
+ 1. The most significant sender identificator is equally as at AWL, the
+ combination of the email address and the originating IP address, resp.
+ its part defined by the IPv4 resp. IPv6 mask setting.
+
+ 2. No IP checking for standalone EMAIL address reputation
+
+ 3. No signature checking for IP reputation, and for HELO name reputation
+
+ 4. The EMAIL_IP weight, and not the standalone EMAIL weight is used when
+ no IP address is available (EMAIL_IP is the main indicator, and has the
+ highest weight)
+
+ 5. No IP checking at signed emails (signature authenticates the email
+ instead of the IP address)
+
+ 6. No IP checking at SPF pass (we assume the domain owner is responsable
+ for all IP's he authorizes to send from, hence we use the same identity
+ for all of them)
+
+ 7. No signature used for standalone EMAIL reputation (would be
+ redundant, since no IP is used at signed EMAIL_IP reputation, and we
+ would store two identical hits)
+
+ 8. When available, the DKIM signer is used instead of the domain name
+ for the DOMAIN reputation
+
+ 9. No IP and no signature used for HELO reputation (despite the
+ possibility of the possible existence of multiple computers with the
+ same HELO)
+
+ 10. The full (unmasked IP) address is used (in the address field,
+ instead the IP field) for the standalone IP reputation
+
+LEARNING SPAM / HAM
+ When SpamAssassin is told to learn (or relearn) a given message as spam
+ or ham, all reputations relevant to the message (email, email_ip,
+ domain, ip, helo) in both global and user storages will be updated using
+ the "txrep_learn_penalty" respectively the "rxrep_learn_bonus" values.
+ The new reputation of given sender property (email, domain,...) will be
+ the respective result of one of the following formulas:
+
+ new_reputation = old_reputation + learn_penalty
+ new_reputation = old_reputation - learn_bonus
+
+ The TxRep plugin currently does track each message individually, hence
+ it does not detect when you learn the message repeatedly. It will
+ add/subtract the penalty/bonus score each time the message is fed to the
+ spam learner.
+
+OPTIMIZING TXREP
+ TxRep can be optimized for speed and simplicity, or for the precision in
+ assigning the reputation scores.
+
+ First of all TxRep can be quickly disabled and re-enabled through the
+ option ""use_txrep"". It can be done globally, or individually in each
+ respective "user_prefs". Disabling TxRep will not destroy the database,
+ so it can be re-enabled any time later again.
+
+ On many systems, SQL-based storage may perform faster than the default
+ Berkeley DB storage, so you should consider setting it up. See the
+ section "SQL-BASED STORAGE" for instructions.
+
+ Then there are multiple settings that can reduce the number of records
+ stored in the database, hence reducing the size of the storage, and also
+ the processing time:
+
+ 1. Setting ""txrep_user2global_ratio"" to zero will disable the dual
+ storage, halving so the disk space requirements, and the processing
+ times of this plugin.
+
+ 2. You can disable all but one of the "REPUTATION WEIGHTS". The EMAIL_IP
+ is the most specific option, so it is the most likely choice in such
+ case, but you could base the reputation system on any of the remaining
+ scores. Each of the enabled reputations adds a new entry to the database
+ for each new identificator. So while for example the number of recorded
+ and scored domains may be big, the number of stored IP addresses will be
+ probably higher, and would require more space in the storage.
+
+ 3. Disabling the ""txrep_track_messages"" avoids storing a separate
+ entry for every scanned message, hence also reducing the disk space
+ requirements, and the processing time.
+
+ 4. Disabling the option ""txrep_autolearn"" will save the processing
+ time at messages that trigger the auto-learning process.
+
+ 5. Disabling ""txrep_whitelist_out"" will reduce the processing time at
+ outbound connections.
+
+ 6. Keeping the option ""auto_whitelist_distinguish_signed"" enabled may
+ help slightly reducing the size of the database, because at signed
+ messages, the originating IP address is ignored, hence no additional
+ database entries are needed for each separate IP address (resp. a masked
+ block of IP addresses).
+
+ Since TxRep reuses the storage architecture of the former AWL plugin,
+ for initializing the SQL storage, the same instructions apply also to
+ TxRep. Although the old AWL table can be reused for TxRep, by default
+ TxRep expects the SQL table to be named "txrep".
+
+ To install a new SQL table for TxRep, run the appropriate SQL file for
+ your system under the /sql directory.
+
+ If you get a syntax error at an older version of MySQL, use TYPE=MyISAM
+ instead of ENGINE=MyISAM at the end of the command. You can also use
+ other types of ENGINE (depending on what is available on your system).
+ For example MEMORY engine stores the entire table in the server memory,
+ achieving performance similar to Redis. You would need to care about the
+ replication of the RAM table to disk through a cronjob, to avoid loss of
+ data at reboot. The InnoDB engine is used by default, offering high
+ scalability (database size and concurence of accesses). In conjunction
+ with a high value of innodb_buffer_pool or with the memcached plugin
+ (MySQL v5.6+) it can also offer performance comparable to Redis.
+
Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html?rev=1676792&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.html Wed Apr 29 17:04:09 2015
@@ -0,0 +1,297 @@
+<?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>URIDNSBL - look up URLs against DNS blocklists</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">
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#user_settings">USER SETTINGS</a></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="#notes">NOTES</a></li>
+</ul>
+
+<hr name="index" />
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<h1><a name="name">NAME</a></h1>
+<p>URIDNSBL - look up URLs against DNS blocklists</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<pre>
+ loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
+ uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT</pre>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>This works by analysing message text and HTML for URLs, extracting host
+names from those, then querying various DNS blocklists for either:
+IP addresses of these hosts (uridnsbl,a) or their nameservers (uridnsbl,ns),
+or domain names of these hosts (urirhsbl), or domain names of their
+nameservers (urinsrhsbl, urifullnsrhsbl).</p>
+<p>
+</p>
+<hr />
+<h1><a name="user_settings">USER SETTINGS</a></h1>
+<dl>
+<dt><strong><a name="skip_uribl_checks" class="item">skip_uribl_checks ( 0 | 1 ) (default: 0)</a></strong></dt>
+
+<dd>
+<p>Turning on the skip_uribl_checks setting will disable the URIDNSBL plugin.</p>
+<p>By default, SpamAssassin will run URI DNSBL checks. Individual URI blocklists
+may be disabled selectively by setting a score of a corresponding rule to 0
+or through the uridnsbl_skip_domain parameter.</p>
+<p>See also a related configuration parameter skip_rbl_checks,
+which controls the DNSEval plugin (documented in the Conf man page).</p>
+</dd>
+</dl>
+<dl>
+<dt><strong><a name="uridnsbl_skip_domain_domain1_domain2" class="item">uridnsbl_skip_domain domain1 domain2 ...</a></strong></dt>
+
+<dd>
+<p>Specify a domain, or a number of domains, which should be skipped for the
+URIBL checks. This is very useful to specify very common domains which are
+not going to be listed in URIBLs.</p>
+</dd>
+</dl>
+<dl>
+<dt><strong><a name="clear_uridnsbl_skip_domain_domain1_domain2" class="item">clear_uridnsbl_skip_domain [domain1 domain2 ...]</a></strong></dt>
+
+<dd>
+<p>If no argument is given, then clears the entire list of domains declared
+by <em>uridnsbl_skip_domain</em> configuration directives so far. Any subsequent
+<em>uridnsbl_skip_domain</em> directives will start creating a new list of skip
+domains.</p>
+<p>When given a list of domains as arguments, only the specified domains
+are removed from the list of skipped domains.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="rule_definitions_and_privileged_settings">RULE DEFINITIONS AND PRIVILEGED SETTINGS</a></h1>
+<dl>
+<dt><strong><a name="uridnsbl_name_of_rule_dnsbl_zone_lookuptype" class="item">uridnsbl NAME_OF_RULE dnsbl_zone lookuptype</a></strong></dt>
+
+<dd>
+<p>Specify a lookup. <code>NAME_OF_RULE</code> is the name of the rule to be
+used, <code>dnsbl_zone</code> is the zone to look up IPs in, and <code>lookuptype</code>
+is the type of lookup (<strong>TXT</strong> or <strong>A</strong>). Note that you must also
+define a body-eval rule calling <code>check_uridnsbl()</code> to use this.</p>
+<p>This works by collecting domain names from URLs and querying DNS
+blocklists with an IP address of host names found in URLs or with
+IP addresses of their name servers, according to tflags as follows.</p>
+<p>If the corresponding body rule has a tflag 'a', the DNS blocklist will
+be queried with an IP address of a host found in URLs.</p>
+<p>If the corresponding body rule has a tflag 'ns', DNS will be queried
+for name servers (NS records) of a domain name found in URLs, then
+these name server names will be resolved to their IP addresses, which
+in turn will be sent to DNS blocklist.</p>
+<p>Tflags directive may specify either 'a' or 'ns' or both flags. In absence
+of any of these two flags, a default is a 'ns', which is compatible with
+pre-3.4 versions of SpamAssassin.</p>
+<p>The choice of tflags must correspond to the policy and expected use of
+each DNS blocklist and is normally not a local decision. As an example,
+a blocklist expecting queries resulting from an 'a' tflag is a
+"black_a.txt" ( <a href="http://www.uribl.com/datasets.shtml">http://www.uribl.com/datasets.shtml</a> ).</p>
+<p>Example:</p>
+<pre>
+ uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT
+ body URIBL_SBLXBL eval:check_uridnsbl('URIBL_SBLXBL')
+ describe URIBL_SBLXBL Contains a URL listed in the SBL/XBL blocklist
+ tflags URIBL_SBLXBL net ns</pre>
+</dd>
+<dt><strong><a name="uridnssub_name_of_rule_dnsbl_zone_lookuptype_subtest" class="item">uridnssub NAME_OF_RULE dnsbl_zone lookuptype subtest</a></strong></dt>
+
+<dd>
+<p>Specify a DNSBL-style domain lookup with a sub-test. <code>NAME_OF_RULE</code> is the
+name of the rule to be used, <code>dnsbl_zone</code> is the zone to look up IPs in,
+and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or <strong>A</strong>).</p>
+<p>Tflags 'ns' and 'a' on a corresponding body rule are recognized and have
+the same meaning as in the uridnsbl directive.</p>
+<p><code>subtest</code> is a sub-test to run against the returned data. The sub-test may
+be in one of the following forms: m, n1-n2, or n/m, where n,n1,n2,m can be
+any of: decimal digits, 0x followed by up to 8 hexadecimal digits, or an IPv4
+address in quad-dot form. The 'A' records (IPv4 dotted address) as returned
+by DNSBLs lookups are converted into a numerical form (r) and checked against
+the specified sub-test as follows:
+for a range n1-n2 the following must be true: (r >= n1 && r <= n2);
+for a n/m form the following must be true: (r & m) == (n & m);
+for a single value in quad-dot form the following must be true: r == n;
+for a single decimal or hex form the following must be true:
+ ((r & n) != 0) && ((r & 0xff000000) == 0x7f000000), i.e. within 127.0.0.0/8</p>
+<p>Some typical examples of a sub-test are: 127.0.1.2, 127.0.1.20-127.0.1.39,
+127.0.1.0/255.255.255.0, 0.0.0.16/0.0.0.16, 0x10/0x10, 16, 0x10 .</p>
+<p>Note that, as with <code>uridnsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+<p>Example:</p>
+<pre>
+ uridnssub URIBL_DNSBL_4 dnsbl.example.org. A 127.0.0.4
+ uridnssub URIBL_DNSBL_8 dnsbl.example.org. A 8</pre>
+</dd>
+<dt><strong><a name="urirhsbl_name_of_rule_rhsbl_zone_lookuptype" class="item">urirhsbl NAME_OF_RULE rhsbl_zone lookuptype</a></strong></dt>
+
+<dd>
+<p>Specify a RHSBL-style domain lookup. <code>NAME_OF_RULE</code> is the name of the rule
+to be used, <code>rhsbl_zone</code> is the zone to look up domain names in, and
+<code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or <strong>A</strong>). Note that you must also
+define a body-eval rule calling <code>check_uridnsbl()</code> to use this.</p>
+<p>An RHSBL zone is one where the domain name is looked up, as a string; e.g. a
+URI using the domain <code>foo.com</code> will cause a lookup of
+<code>foo.com.uriblzone.net</code>. Note that hostnames are stripped from the domain
+used in the URIBL lookup, so the domain <code>foo.bar.com</code> will look up
+<code>bar.com.uriblzone.net</code>, and <code>foo.bar.co.uk</code> will look up
+<code>bar.co.uk.uriblzone.net</code>.</p>
+<p>If an URI consists of an IP address instead of a hostname, the IP address is
+looked up (using the standard reversed quads method) in each <code>rhsbl_zone</code>.</p>
+<p>Example:</p>
+<pre>
+ urirhsbl URIBL_RHSBL rhsbl.example.org. TXT</pre>
+</dd>
+<dt><strong><a name="urirhssub_name_of_rule_rhsbl_zone_lookuptype_subtest" class="item">urirhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</a></strong></dt>
+
+<dd>
+<p>Specify a RHSBL-style domain lookup with a sub-test. <code>NAME_OF_RULE</code> is the
+name of the rule to be used, <code>rhsbl_zone</code> is the zone to look up domain names
+in, and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or <strong>A</strong>).</p>
+<p><code>subtest</code> is a sub-test to run against the returned data. The sub-test may
+be in one of the following forms: m, n1-n2, or n/m, where n,n1,n2,m can be
+any of: decimal digits, 0x followed by up to 8 hexadecimal digits, or an IPv4
+address in quad-dot form. The 'A' records (IPv4 dotted address) as returned
+by DNSBLs lookups are converted into a numerical form (r) and checked against
+the specified sub-test as follows:
+for a range n1-n2 the following must be true: (r >= n1 && r <= n2);
+for a n/m form the following must be true: (r & m) == (n & m);
+for a single value in quad-dot form the following must be true: r == n;
+for a single decimal or hex form the following must be true:
+ ((r & n) != 0) && ((r & 0xff000000) == 0x7f000000), i.e. within 127.0.0.0/8</p>
+<p>Some typical examples of a sub-test are: 127.0.1.2, 127.0.1.20-127.0.1.39,
+127.2.3.0/255.255.255.0, 0.0.0.16/0.0.0.16, 0x10/0x10, 16, 0x10 .</p>
+<p>Note that, as with <code>urirhsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+<p>Example:</p>
+<pre>
+ urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
+ urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8</pre>
+</dd>
+<dt><strong><a name="urinsrhsbl_name_of_rule_rhsbl_zone_lookuptype" class="item">urinsrhsbl NAME_OF_RULE rhsbl_zone lookuptype</a></strong></dt>
+
+<dd>
+<p>Perform a RHSBL-style domain lookup against the contents of the NS records
+for each URI. In other words, a URI using the domain <code>foo.com</code> will cause
+an NS lookup to take place; assuming that domain has an NS of <code>ns0.bar.com</code>,
+that will cause a lookup of <code>bar.com.uriblzone.net</code>. Note that hostnames
+are stripped from both the domain used in the URI, and the domain in the
+lookup.</p>
+<p><code>NAME_OF_RULE</code> is the name of the rule to be used, <code>rhsbl_zone</code> is the zone
+to look up domain names in, and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or
+<strong>A</strong>).</p>
+<p>Note that, as with <code>urirhsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+</dd>
+<dt><strong><a name="urinsrhssub_name_of_rule_rhsbl_zone_lookuptype_subtest" class="item">urinsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</a></strong></dt>
+
+<dd>
+<p>Specify a RHSBL-style domain-NS lookup, as above, with a sub-test.
+<code>NAME_OF_RULE</code> is the name of the rule to be used, <code>rhsbl_zone</code> is the zone
+to look up domain names in, and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or
+<strong>A</strong>). <code>subtest</code> is the sub-test to run against the returned data; see
+<urirhssub>.</p>
+<p>Note that, as with <code>urirhsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+</dd>
+<dt><strong><a name="urifullnsrhsbl_name_of_rule_rhsbl_zone_lookuptype" class="item">urifullnsrhsbl NAME_OF_RULE rhsbl_zone lookuptype</a></strong></dt>
+
+<dd>
+<p>Perform a RHSBL-style domain lookup against the contents of the NS records for
+each URI. In other words, a URI using the domain <code>foo.com</code> will cause an NS
+lookup to take place; assuming that domain has an NS of <code>ns0.bar.com</code>, that
+will cause a lookup of <code>ns0.bar.com.uriblzone.net</code>. Note that hostnames are
+stripped from the domain used in the URI.</p>
+<p><code>NAME_OF_RULE</code> is the name of the rule to be used, <code>rhsbl_zone</code> is the zone
+to look up domain names in, and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or
+<strong>A</strong>).</p>
+<p>Note that, as with <code>urirhsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+</dd>
+<dt><strong><a name="urifullnsrhssub_name_of_rule_rhsbl_zone_lookuptype_subtest" class="item">urifullnsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</a></strong></dt>
+
+<dd>
+<p>Specify a RHSBL-style domain-NS lookup, as above, with a sub-test.
+<code>NAME_OF_RULE</code> is the name of the rule to be used, <code>rhsbl_zone</code> is the zone
+to look up domain names in, and <code>lookuptype</code> is the type of lookup (<strong>TXT</strong> or
+<strong>A</strong>). <code>subtest</code> is the sub-test to run against the returned data; see
+<urirhssub>.</p>
+<p>Note that, as with <code>urirhsbl</code>, you must also define a body-eval rule calling
+<code>check_uridnsbl()</code> to use this.</p>
+</dd>
+<dt><strong><a name="tflags_name_of_rule_ips_only" class="item">tflags NAME_OF_RULE ips_only</a></strong></dt>
+
+<dd>
+<p>Only URIs containing IP addresses as the "host" component will be matched
+against the named "urirhsbl"/"urirhssub" rule.</p>
+</dd>
+<dt><strong><a name="tflags_name_of_rule_domains_only" class="item">tflags NAME_OF_RULE domains_only</a></strong></dt>
+
+<dd>
+<p>Only URIs containing a non-IP-address "host" component will be matched against
+the named "urirhsbl"/"urirhssub" rule.</p>
+</dd>
+<dt><strong><a name="tflags_name_of_rule_ns" class="item">tflags NAME_OF_RULE ns</a></strong></dt>
+
+<dd>
+<p>The 'ns' flag may be applied to rules corresponding to uridnsbl and uridnssub
+directives. Host names from URLs will be mapped to their name server IP
+addresses (a NS lookup followed by an A lookup), which in turn will be sent
+to blocklists. This is a default when neither 'a' nor 'ns' flags are specified.</p>
+</dd>
+<dt><strong><a name="tflags_name_of_rule_a" class="item">tflags NAME_OF_RULE a</a></strong></dt>
+
+<dd>
+<p>The 'a' flag may be applied to rules corresponding to uridnsbl and uridnssub
+directives. Host names from URLs will be mapped to their IP addresses, which
+will be sent to blocklists. When both 'ns' and 'a' flags are specified,
+both queries will be performed.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="administrator_settings">ADMINISTRATOR SETTINGS</a></h1>
+<dl>
+<dt><strong><a name="n" class="item">uridnsbl_max_domains N (default: 20)</a></strong></dt>
+
+<dd>
+<p>The maximum number of domains to look up.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="notes">NOTES</a></h1>
+<p>The <code>uridnsbl_timeout</code> option has been obsoleted by the <code>rbl_timeout</code>
+option. See the <code>Mail::SpamAssassin::Conf</code> POD for details on <code>rbl_timeout</code>.</p>
+
+</body>
+
+</html>