Mailing List Archive

svn commit: r1871201 [13/17] - in /spamassassin/site/full/3.4.x: ./ doc/
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=1871201&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 Dec 11 22:18:49 2019
@@ -0,0 +1,811 @@
+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 first disable the AWL plugin (if enabled),
+ and back up its database. AWL is loaded in v310.pre and can be disabled
+ by commenting out the loadplugin line:
+
+ # loadplugin Mail::SpamAssassin::Plugin::AWL
+
+ When AWL is not disabled, TxRep will refuse to run.
+
+ TxRep should be enabled by uncommenting the following line in v341.pre:
+
+ loadplugin Mail::SpamAssassin::Plugin::TxRep
+
+ 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 the 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 " WHITELISTING" in BLACKLISTING . 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 message 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. Without this option, or for domains that do not
+ use a DKIM signature, the reputation of legitimate email can get
+ mixed with the reputation of forgeries. A pre-requisite when setting
+ this option is that a field txrep.signedby exists in a SQL table,
+ otherwise SQL operations will fail. A DKIM plugin must also be
+ enabled in order for this option to take effect. This option is
+ highly recommended. Unless you are using a pre-3.3.0 database schema
+ and cannot upgrade, there is no reason to disable this option. If
+ you are upgrading from AWL and using a pre-3.3.0 schema, the
+ txrep.signedby column will not exist. It is recommended that you add
+ this column, but if that is not possible you must set this option to
+ 0 to avoid SQL errors.
+
+ 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 hopefully 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 addresses 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 responsible
+ 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.
+
+ 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 concurrence 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=1871201&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 Dec 11 22:18:49 2019
@@ -0,0 +1,241 @@
+<?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="#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>
+
+<h1 id="NAME">NAME</h1>
+
+<p>URIDNSBL - look up URLs against DNS blocklists</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<pre><code> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
+ uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT</code></pre>
+
+<h1 id="DESCRIPTION">DESCRIPTION</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>
+
+<h1 id="USER-SETTINGS">USER SETTINGS</h1>
+
+<dl>
+
+<dt id="skip_uribl_checks-0-1-default:-0">skip_uribl_checks ( 0 | 1 ) (default: 0)</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 id="uridnsbl_skip_domain-domain1-domain2">uridnsbl_skip_domain domain1 domain2 ...</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 id="clear_uridnsbl_skip_domain-domain1-domain2">clear_uridnsbl_skip_domain [domain1 domain2 ...]</dt>
+<dd>
+
+<p>If no argument is given, then clears the entire list of domains declared by <i>uridnsbl_skip_domain</i> configuration directives so far. Any subsequent <i>uridnsbl_skip_domain</i> 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>
+
+<h1 id="RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</h1>
+
+<dl>
+
+<dt id="uridnsbl-NAME_OF_RULE-dnsbl_zone-lookuptype">uridnsbl NAME_OF_RULE dnsbl_zone lookuptype</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 (<b>TXT</b> or <b>A</b>). 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 &#39;a&#39;, 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 &#39;ns&#39;, 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 &#39;a&#39; or &#39;ns&#39; or both flags. In absence of any of these two flags, a default is a &#39;ns&#39;, 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 &#39;a&#39; tflag is a &quot;black_a.txt&quot; ( http://www.uribl.com/datasets.shtml ).</p>
+
+<p>Example:</p>
+
+<pre><code> uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT
+ body URIBL_SBLXBL eval:check_uridnsbl(&#39;URIBL_SBLXBL&#39;)
+ describe URIBL_SBLXBL Contains a URL listed in the SBL/XBL blocklist
+ tflags URIBL_SBLXBL net ns</code></pre>
+
+</dd>
+<dt id="uridnssub-NAME_OF_RULE-dnsbl_zone-lookuptype-subtest">uridnssub NAME_OF_RULE dnsbl_zone lookuptype subtest</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 (<b>TXT</b> or <b>A</b>).</p>
+
+<p>Tflags &#39;ns&#39; and &#39;a&#39; 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 &#39;A&#39; 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 &gt;= n1 &amp;&amp; r &lt;= n2); for a n/m form the following must be true: (r &amp; m) == (n &amp; 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 &amp; n) != 0) &amp;&amp; ((r &amp; 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><code> uridnssub URIBL_DNSBL_4 dnsbl.example.org. A 127.0.0.4
+ uridnssub URIBL_DNSBL_8 dnsbl.example.org. A 8</code></pre>
+
+</dd>
+<dt id="urirhsbl-NAME_OF_RULE-rhsbl_zone-lookuptype">urirhsbl NAME_OF_RULE rhsbl_zone lookuptype</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 (<b>TXT</b> or <b>A</b>). 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><code> urirhsbl URIBL_RHSBL rhsbl.example.org. TXT</code></pre>
+
+</dd>
+<dt id="urirhssub-NAME_OF_RULE-rhsbl_zone-lookuptype-subtest">urirhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</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 (<b>TXT</b> or <b>A</b>).</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 &#39;A&#39; 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 &gt;= n1 &amp;&amp; r &lt;= n2); for a n/m form the following must be true: (r &amp; m) == (n &amp; 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 &amp; n) != 0) &amp;&amp; ((r &amp; 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><code> urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
+ urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8</code></pre>
+
+</dd>
+<dt id="urinsrhsbl-NAME_OF_RULE-rhsbl_zone-lookuptype">urinsrhsbl NAME_OF_RULE rhsbl_zone lookuptype</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 (<b>TXT</b> or <b>A</b>).</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 id="urinsrhssub-NAME_OF_RULE-rhsbl_zone-lookuptype-subtest">urinsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</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 (<b>TXT</b> or <b>A</b>). <code>subtest</code> is the sub-test to run against the returned data; see &lt;urirhssub&gt;.</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 id="urifullnsrhsbl-NAME_OF_RULE-rhsbl_zone-lookuptype">urifullnsrhsbl NAME_OF_RULE rhsbl_zone lookuptype</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 (<b>TXT</b> or <b>A</b>).</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 id="urifullnsrhssub-NAME_OF_RULE-rhsbl_zone-lookuptype-subtest">urifullnsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest</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 (<b>TXT</b> or <b>A</b>). <code>subtest</code> is the sub-test to run against the returned data; see &lt;urirhssub&gt;.</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 id="tflags-NAME_OF_RULE-ips_only">tflags NAME_OF_RULE ips_only</dt>
+<dd>
+
+<p>Only URIs containing IP addresses as the &quot;host&quot; component will be matched against the named &quot;urirhsbl&quot;/&quot;urirhssub&quot; rule.</p>
+
+</dd>
+<dt id="tflags-NAME_OF_RULE-domains_only">tflags NAME_OF_RULE domains_only</dt>
+<dd>
+
+<p>Only URIs containing a non-IP-address &quot;host&quot; component will be matched against the named &quot;urirhsbl&quot;/&quot;urirhssub&quot; rule.</p>
+
+</dd>
+<dt id="tflags-NAME_OF_RULE-ns">tflags NAME_OF_RULE ns</dt>
+<dd>
+
+<p>The &#39;ns&#39; 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 &#39;a&#39; nor &#39;ns&#39; flags are specified.</p>
+
+</dd>
+<dt id="tflags-NAME_OF_RULE-a">tflags NAME_OF_RULE a</dt>
+<dd>
+
+<p>The &#39;a&#39; 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 &#39;ns&#39; and &#39;a&#39; flags are specified, both queries will be performed.</p>
+
+</dd>
+</dl>
+
+<h1 id="ADMINISTRATOR-SETTINGS">ADMINISTRATOR SETTINGS</h1>
+
+<dl>
+
+<dt id="uridnsbl_max_domains-N-default:-20">uridnsbl_max_domains N (default: 20)</dt>
+<dd>
+
+<p>The maximum number of domains to look up.</p>
+
+</dd>
+<dt id="parse_dkim_uris-0-1">parse_dkim_uris ( 0 / 1 )</dt>
+<dd>
+
+<p>Include DKIM uris in lookups. This option is documented in Mail::SpamAssassin::Conf.</p>
+
+</dd>
+</dl>
+
+<h1 id="NOTES">NOTES</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>
+
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.txt?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDNSBL.txt Wed Dec 11 22:18:49 2019
@@ -0,0 +1,246 @@
+NAME
+ URIDNSBL - look up URLs against DNS blocklists
+
+SYNOPSIS
+ loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
+ uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT
+
+DESCRIPTION
+ 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).
+
+USER SETTINGS
+ skip_uribl_checks ( 0 | 1 ) (default: 0)
+ Turning on the skip_uribl_checks setting will disable the URIDNSBL
+ plugin.
+
+ 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.
+
+ See also a related configuration parameter skip_rbl_checks, which
+ controls the DNSEval plugin (documented in the Conf man page).
+
+ uridnsbl_skip_domain domain1 domain2 ...
+ 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.
+
+ clear_uridnsbl_skip_domain [domain1 domain2 ...]
+ If no argument is given, then clears the entire list of domains
+ declared by *uridnsbl_skip_domain* configuration directives so far.
+ Any subsequent *uridnsbl_skip_domain* directives will start creating
+ a new list of skip domains.
+
+ When given a list of domains as arguments, only the specified
+ domains are removed from the list of skipped domains.
+
+RULE DEFINITIONS AND PRIVILEGED SETTINGS
+ uridnsbl NAME_OF_RULE dnsbl_zone lookuptype
+ Specify a lookup. "NAME_OF_RULE" is the name of the rule to be used,
+ "dnsbl_zone" is the zone to look up IPs in, and "lookuptype" is the
+ type of lookup (TXT or A). Note that you must also define a
+ body-eval rule calling "check_uridnsbl()" to use this.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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" ( http://www.uribl.com/datasets.shtml ).
+
+ Example:
+
+ 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
+
+ uridnssub NAME_OF_RULE dnsbl_zone lookuptype subtest
+ Specify a DNSBL-style domain lookup with a sub-test. "NAME_OF_RULE"
+ is the name of the rule to be used, "dnsbl_zone" is the zone to look
+ up IPs in, and "lookuptype" is the type of lookup (TXT or A).
+
+ Tflags 'ns' and 'a' on a corresponding body rule are recognized and
+ have the same meaning as in the uridnsbl directive.
+
+ "subtest" 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
+
+ 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 .
+
+ Note that, as with "uridnsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ Example:
+
+ uridnssub URIBL_DNSBL_4 dnsbl.example.org. A 127.0.0.4
+ uridnssub URIBL_DNSBL_8 dnsbl.example.org. A 8
+
+ urirhsbl NAME_OF_RULE rhsbl_zone lookuptype
+ Specify a RHSBL-style domain lookup. "NAME_OF_RULE" is the name of
+ the rule to be used, "rhsbl_zone" is the zone to look up domain
+ names in, and "lookuptype" is the type of lookup (TXT or A). Note
+ that you must also define a body-eval rule calling
+ "check_uridnsbl()" to use this.
+
+ An RHSBL zone is one where the domain name is looked up, as a
+ string; e.g. a URI using the domain "foo.com" will cause a lookup of
+ "foo.com.uriblzone.net". Note that hostnames are stripped from the
+ domain used in the URIBL lookup, so the domain "foo.bar.com" will
+ look up "bar.com.uriblzone.net", and "foo.bar.co.uk" will look up
+ "bar.co.uk.uriblzone.net".
+
+ 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 "rhsbl_zone".
+
+ Example:
+
+ urirhsbl URIBL_RHSBL rhsbl.example.org. TXT
+
+ urirhssub NAME_OF_RULE rhsbl_zone lookuptype subtest
+ Specify a RHSBL-style domain lookup with a sub-test. "NAME_OF_RULE"
+ is the name of the rule to be used, "rhsbl_zone" is the zone to look
+ up domain names in, and "lookuptype" is the type of lookup (TXT or
+ A).
+
+ "subtest" 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
+
+ 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 .
+
+ Note that, as with "urirhsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ Example:
+
+ urirhssub URIBL_RHSBL_4 rhsbl.example.org. A 127.0.0.4
+ urirhssub URIBL_RHSBL_8 rhsbl.example.org. A 8
+
+ urinsrhsbl NAME_OF_RULE rhsbl_zone lookuptype
+ Perform a RHSBL-style domain lookup against the contents of the NS
+ records for each URI. In other words, a URI using the domain
+ "foo.com" will cause an NS lookup to take place; assuming that
+ domain has an NS of "ns0.bar.com", that will cause a lookup of
+ "bar.com.uriblzone.net". Note that hostnames are stripped from both
+ the domain used in the URI, and the domain in the lookup.
+
+ "NAME_OF_RULE" is the name of the rule to be used, "rhsbl_zone" is
+ the zone to look up domain names in, and "lookuptype" is the type of
+ lookup (TXT or A).
+
+ Note that, as with "urirhsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ urinsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest
+ Specify a RHSBL-style domain-NS lookup, as above, with a sub-test.
+ "NAME_OF_RULE" is the name of the rule to be used, "rhsbl_zone" is
+ the zone to look up domain names in, and "lookuptype" is the type of
+ lookup (TXT or A). "subtest" is the sub-test to run against the
+ returned data; see <urirhssub>.
+
+ Note that, as with "urirhsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ urifullnsrhsbl NAME_OF_RULE rhsbl_zone lookuptype
+ Perform a RHSBL-style domain lookup against the contents of the NS
+ records for each URI. In other words, a URI using the domain
+ "foo.com" will cause an NS lookup to take place; assuming that
+ domain has an NS of "ns0.bar.com", that will cause a lookup of
+ "ns0.bar.com.uriblzone.net". Note that hostnames are stripped from
+ the domain used in the URI.
+
+ "NAME_OF_RULE" is the name of the rule to be used, "rhsbl_zone" is
+ the zone to look up domain names in, and "lookuptype" is the type of
+ lookup (TXT or A).
+
+ Note that, as with "urirhsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ urifullnsrhssub NAME_OF_RULE rhsbl_zone lookuptype subtest
+ Specify a RHSBL-style domain-NS lookup, as above, with a sub-test.
+ "NAME_OF_RULE" is the name of the rule to be used, "rhsbl_zone" is
+ the zone to look up domain names in, and "lookuptype" is the type of
+ lookup (TXT or A). "subtest" is the sub-test to run against the
+ returned data; see <urirhssub>.
+
+ Note that, as with "urirhsbl", you must also define a body-eval rule
+ calling "check_uridnsbl()" to use this.
+
+ tflags NAME_OF_RULE ips_only
+ Only URIs containing IP addresses as the "host" component will be
+ matched against the named "urirhsbl"/"urirhssub" rule.
+
+ tflags NAME_OF_RULE domains_only
+ Only URIs containing a non-IP-address "host" component will be
+ matched against the named "urirhsbl"/"urirhssub" rule.
+
+ tflags NAME_OF_RULE ns
+ 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.
+
+ tflags NAME_OF_RULE a
+ 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.
+
+ADMINISTRATOR SETTINGS
+ uridnsbl_max_domains N (default: 20)
+ The maximum number of domains to look up.
+
+ parse_dkim_uris ( 0 / 1 )
+ Include DKIM uris in lookups. This option is documented in
+ Mail::SpamAssassin::Conf.
+
+NOTES
+ The "uridnsbl_timeout" option has been obsoleted by the "rbl_timeout"
+ option. See the "Mail::SpamAssassin::Conf" POD for details on
+ "rbl_timeout".
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.html?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.html Wed Dec 11 22:18:49 2019
@@ -0,0 +1,63 @@
+<?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="#RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</a></li>
+</ul>
+
+<h1 id="NAME">NAME</h1>
+
+<p>URIDetail - test URIs using detailed URI information</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<p>This plugin creates a new rule test type, known as &quot;uri_detail&quot;. These rules apply to all URIs found in the message.</p>
+
+<pre><code> loadplugin Mail::SpamAssassin::Plugin::URIDetail</code></pre>
+
+<h1 id="RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</h1>
+
+<p>The format for defining a rule is as follows:</p>
+
+<pre><code> uri_detail SYMBOLIC_TEST_NAME key1 =~ /value1/ key2 !~ /value2/ ...</code></pre>
+
+<p>Supported keys are:</p>
+
+<p><code>raw</code> is the raw URI prior to any cleaning (e.g. &quot;http://spamassassin.apache%2Eorg/&quot;).</p>
+
+<p><code>type</code> is the tag(s) which referenced the raw_uri. <i>parsed</i> is a faked type which specifies that the raw_uri was parsed from the rendered text.</p>
+
+<p><code>cleaned</code> is a list including the raw URI and various cleaned versions of the raw URI (http://spamassassin.apache%2Eorg/, https://spamassassin.apache.org/).</p>
+
+<p><code>text</code> is the anchor text(s) (text between &lt;a&gt; and &lt;/a&gt;) that linked to the raw URI.</p>
+
+<p><code>domain</code> is the domain(s) found in the cleaned URIs.</p>
+
+<p>Example rule for matching a URI where the raw URI matches &quot;%2Ebar&quot;, the domain &quot;bar.com&quot; is found, and the type is &quot;a&quot; (an anchor tag).</p>
+
+<pre><code> uri_detail TEST1 raw =~ /%2Ebar/ domain =~ /^bar\.com$/ type =~ /^a$/</code></pre>
+
+<p>Example rule to look for suspicious &quot;https&quot; links:</p>
+
+<pre><code> uri_detail FAKE_HTTPS text =~ /\bhttps:/ cleaned !~ /\bhttps:/</code></pre>
+
+<p>Regular expressions should be delimited by slashes.</p>
+
+
+</body>
+
+</html>
+
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.txt?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URIDetail.txt Wed Dec 11 22:18:49 2019
@@ -0,0 +1,42 @@
+NAME
+ URIDetail - test URIs using detailed URI information
+
+SYNOPSIS
+ This plugin creates a new rule test type, known as "uri_detail". These
+ rules apply to all URIs found in the message.
+
+ loadplugin Mail::SpamAssassin::Plugin::URIDetail
+
+RULE DEFINITIONS AND PRIVILEGED SETTINGS
+ The format for defining a rule is as follows:
+
+ uri_detail SYMBOLIC_TEST_NAME key1 =~ /value1/ key2 !~ /value2/ ...
+
+ Supported keys are:
+
+ "raw" is the raw URI prior to any cleaning (e.g.
+ "http://spamassassin.apache%2Eorg/").
+
+ "type" is the tag(s) which referenced the raw_uri. *parsed* is a faked
+ type which specifies that the raw_uri was parsed from the rendered text.
+
+ "cleaned" is a list including the raw URI and various cleaned versions
+ of the raw URI (http://spamassassin.apache%2Eorg/,
+ https://spamassassin.apache.org/).
+
+ "text" is the anchor text(s) (text between <a> and </a>) that linked to
+ the raw URI.
+
+ "domain" is the domain(s) found in the cleaned URIs.
+
+ Example rule for matching a URI where the raw URI matches "%2Ebar", the
+ domain "bar.com" is found, and the type is "a" (an anchor tag).
+
+ uri_detail TEST1 raw =~ /%2Ebar/ domain =~ /^bar\.com$/ type =~ /^a$/
+
+ Example rule to look for suspicious "https" links:
+
+ uri_detail FAKE_HTTPS text =~ /\bhttps:/ cleaned !~ /\bhttps:/
+
+ Regular expressions should be delimited by slashes.
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.html?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.html Wed Dec 11 22:18:49 2019
@@ -0,0 +1,117 @@
+<?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="#RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</a></li>
+ <li><a href="#DEPENDENCIES">DEPENDENCIES</a></li>
+</ul>
+
+<h1 id="NAME">NAME</h1>
+
+<p>URILocalBL - blacklist URIs using local information (ISP names, address lists, and country codes)</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<p>This plugin creates some new rule test types, such as &quot;uri_block_cc&quot;, &quot;uri_block_cidr&quot;, and &quot;uri_block_isp&quot;. These rules apply to the URIs found in the HTML portion of a message, i.e. &lt;a href=...&gt; markup.</p>
+
+<pre><code> loadplugin Mail::SpamAssassin::Plugin::URILocalBL</code></pre>
+
+<p>Why local blacklisting? There are a few excellent, effective, and well-maintained DNSBL&#39;s out there. But they have several drawbacks:</p>
+
+<ul>
+
+<li><p>blacklists can cover tens of thousands of entries, and you can&#39;t select which ones you use;</p>
+
+</li>
+<li><p>verifying that it&#39;s correctly configured can be non-trivial;</p>
+
+</li>
+<li><p>new blacklisting entries may take a while to be detected and entered, so it&#39;s not instantaneous.</p>
+
+</li>
+</ul>
+
+<p>Sometimes all you want is a quick, easy, and very surgical blacklisting of a particular site or a particular ISP. This plugin is defined for that exact usage case.</p>
+
+<h1 id="RULE-DEFINITIONS-AND-PRIVILEGED-SETTINGS">RULE DEFINITIONS AND PRIVILEGED SETTINGS</h1>
+
+<p>The format for defining a rule is as follows:</p>
+
+<pre><code> uri_block_cc SYMBOLIC_TEST_NAME cc1 cc2 cc3 cc4</code></pre>
+
+<p>or:</p>
+
+<pre><code> uri_block_cont SYMBOLIC_TEST_NAME co1 co2 co3 co4</code></pre>
+
+<p>or:</p>
+
+<pre><code> uri_block_cidr SYMBOLIC_TEST_NAME a.a.a.a b.b.b.b/cc d.d.d.d-e.e.e.e</code></pre>
+
+<p>or:</p>
+
+<pre><code> uri_block_isp SYMBOLIC_TEST_NAME &quot;DataRancid&quot; &quot;McCarrier&quot; &quot;Phishers-r-Us&quot;</code></pre>
+
+<p>Example rule for matching a URI in China:</p>
+
+<pre><code> uri_block_cc TEST1 cn</code></pre>
+
+<p>This would block the URL http://www.baidu.com/index.htm. Similarly, to match a Spam-haven netblock:</p>
+
+<pre><code> uri_block_cidr TEST2 65.181.64.0/18</code></pre>
+
+<p>would match a netblock where several phishing sites were recently hosted.</p>
+
+<p>And to block all CIDR blocks registered to an ISP, one might use:</p>
+
+<pre><code> uri_block_isp TEST3 &quot;ColoCrossing&quot;</code></pre>
+
+<p>if one didn&#39;t trust URL&#39;s pointing to that organization&#39;s clients. Lastly, if there&#39;s a country that you want to block but there&#39;s an explicit host you wish to exempt from that blacklist, you can use:</p>
+
+<pre><code> uri_block_exclude TEST1 www.baidu.com</code></pre>
+
+<p>if you wish to exempt URL&#39;s referring to this host. The same syntax is applicable to CIDR and ISP blocks as well.</p>
+
+<h1 id="DEPENDENCIES">DEPENDENCIES</h1>
+
+<p>The Country-Code based filtering requires the Geo::IP or GeoIP2 module, which uses either the fremium GeoLiteCountry database, or the commercial version of it called GeoIP from MaxMind.com.</p>
+
+<p>The ISP based filtering requires the same module, plus the GeoIPISP database. There is no fremium version of this database, so commercial licensing is required.</p>
+
+<dl>
+
+<dt id="uri_country_db_path-STRING">uri_country_db_path STRING</dt>
+<dd>
+
+<p>This option tells SpamAssassin where to find the MaxMind country GeoIP2 database. Country or City database are both supported.</p>
+
+</dd>
+</dl>
+
+<dl>
+
+<dt id="uri_country_db_isp_path-STRING">uri_country_db_isp_path STRING</dt>
+<dd>
+
+<p>This option tells SpamAssassin where to find the MaxMind isp GeoIP2 database.</p>
+
+</dd>
+</dl>
+
+
+</body>
+
+</html>
+
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.txt?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_URILocalBL.txt Wed Dec 11 22:18:49 2019
@@ -0,0 +1,85 @@
+NAME
+ URILocalBL - blacklist URIs using local information (ISP names, address
+ lists, and country codes)
+
+SYNOPSIS
+ This plugin creates some new rule test types, such as "uri_block_cc",
+ "uri_block_cidr", and "uri_block_isp". These rules apply to the URIs
+ found in the HTML portion of a message, i.e. <a href=...> markup.
+
+ loadplugin Mail::SpamAssassin::Plugin::URILocalBL
+
+ Why local blacklisting? There are a few excellent, effective, and
+ well-maintained DNSBL's out there. But they have several drawbacks:
+
+ * blacklists can cover tens of thousands of entries, and you can't
+ select which ones you use;
+
+ * verifying that it's correctly configured can be non-trivial;
+
+ * new blacklisting entries may take a while to be detected and entered,
+ so it's not instantaneous.
+
+ Sometimes all you want is a quick, easy, and very surgical blacklisting
+ of a particular site or a particular ISP. This plugin is defined for
+ that exact usage case.
+
+RULE DEFINITIONS AND PRIVILEGED SETTINGS
+ The format for defining a rule is as follows:
+
+ uri_block_cc SYMBOLIC_TEST_NAME cc1 cc2 cc3 cc4
+
+ or:
+
+ uri_block_cont SYMBOLIC_TEST_NAME co1 co2 co3 co4
+
+ or:
+
+ uri_block_cidr SYMBOLIC_TEST_NAME a.a.a.a b.b.b.b/cc d.d.d.d-e.e.e.e
+
+ or:
+
+ uri_block_isp SYMBOLIC_TEST_NAME "DataRancid" "McCarrier" "Phishers-r-Us"
+
+ Example rule for matching a URI in China:
+
+ uri_block_cc TEST1 cn
+
+ This would block the URL http://www.baidu.com/index.htm. Similarly, to
+ match a Spam-haven netblock:
+
+ uri_block_cidr TEST2 65.181.64.0/18
+
+ would match a netblock where several phishing sites were recently
+ hosted.
+
+ And to block all CIDR blocks registered to an ISP, one might use:
+
+ uri_block_isp TEST3 "ColoCrossing"
+
+ if one didn't trust URL's pointing to that organization's clients.
+ Lastly, if there's a country that you want to block but there's an
+ explicit host you wish to exempt from that blacklist, you can use:
+
+ uri_block_exclude TEST1 www.baidu.com
+
+ if you wish to exempt URL's referring to this host. The same syntax is
+ applicable to CIDR and ISP blocks as well.
+
+DEPENDENCIES
+ The Country-Code based filtering requires the Geo::IP or GeoIP2 module,
+ which uses either the fremium GeoLiteCountry database, or the commercial
+ version of it called GeoIP from MaxMind.com.
+
+ The ISP based filtering requires the same module, plus the GeoIPISP
+ database. There is no fremium version of this database, so commercial
+ licensing is required.
+
+ uri_country_db_path STRING
+ This option tells SpamAssassin where to find the MaxMind country
+ GeoIP2 database. Country or City database are both supported.
+
+ uri_country_db_isp_path STRING
+ This option tells SpamAssassin where to find the MaxMind isp GeoIP2
+ database.
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.html?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.html Wed Dec 11 22:18:49 2019
@@ -0,0 +1,51 @@
+<?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="#USER-PREFERENCES">USER PREFERENCES</a></li>
+</ul>
+
+<h1 id="NAME">NAME</h1>
+
+<p>Mail::SpamAssassin::Plugin::VBounce - aid in rescuing genuine bounces</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<pre><code> loadplugin Mail::SpamAssassin::Plugin::VBounce [/path/to/VBounce.pm]</code></pre>
+
+<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>
+
+<dl>
+
+<dt id="whitelist_bounce_relays-hostname-hostname2">whitelist_bounce_relays hostname [hostname2 ...]</dt>
+<dd>
+
+<p>This is used to &#39;rescue&#39; legitimate bounce messages that were generated in response to mail you really *did* send. List the MTA relay hostnames that your outbound mail is delivered through. If a bounce message is found, and it contains one of these hostnames in a &#39;Received&#39; header found the in the message body, it will not be marked as a blowback virus-bounce.</p>
+
+<p>The hostnames can be file-glob-style patterns, so <code>relay*.isp.com</code> will work. Specifically, <code>*</code> and <code>?</code> are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons.</p>
+
+<p>Multiple addresses per line, separated by spaces, is OK. Multiple <code>whitelist_bounce_relays</code> lines are also OK.</p>
+
+</dd>
+</dl>
+
+
+</body>
+
+</html>
+
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.txt
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.txt?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.txt (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_VBounce.txt Wed Dec 11 22:18:49 2019
@@ -0,0 +1,27 @@
+NAME
+ Mail::SpamAssassin::Plugin::VBounce - aid in rescuing genuine bounces
+
+SYNOPSIS
+ loadplugin Mail::SpamAssassin::Plugin::VBounce [/path/to/VBounce.pm]
+
+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.
+
+ whitelist_bounce_relays hostname [hostname2 ...]
+ This is used to 'rescue' legitimate bounce messages that were
+ generated in response to mail you really *did* send. List the MTA
+ relay hostnames that your outbound mail is delivered through. If a
+ bounce message is found, and it contains one of these hostnames in a
+ 'Received' header found the in the message body, it will not be
+ marked as a blowback virus-bounce.
+
+ The hostnames can be file-glob-style patterns, so "relay*.isp.com"
+ will work. Specifically, "*" and "?" are allowed, but all other
+ metacharacters are not. Regular expressions are not used for
+ security reasons.
+
+ Multiple addresses per line, separated by spaces, is OK. Multiple
+ "whitelist_bounce_relays" lines are also OK.
+

Added: spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_WhiteListSubject.html
URL: http://svn.apache.org/viewvc/spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_WhiteListSubject.html?rev=1871201&view=auto
==============================================================================
--- spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_WhiteListSubject.html (added)
+++ spamassassin/site/full/3.4.x/doc/Mail_SpamAssassin_Plugin_WhiteListSubject.html Wed Dec 11 22:18:49 2019
@@ -0,0 +1,46 @@
+<?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>
+</ul>
+
+<h1 id="NAME">NAME</h1>
+
+<p>Mail::SpamAssassin::Plugin::WhiteListSubject - whitelist by Subject header</p>
+
+<h1 id="SYNOPSIS">SYNOPSIS</h1>
+
+<pre><code> loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject
+
+ header SUBJECT_IN_WHITELIST eval:check_subject_in_whitelist()
+ header SUBJECT_IN_BLACKLIST eval:check_subject_in_blacklist()
+
+ score SUBJECT_IN_WHITELIST -100
+ score SUBJECT_IN_BLACKLIST 100
+
+ whitelist_subject [Bug *]
+ blacklist_subject Make Money Fast</code></pre>
+
+<h1 id="DESCRIPTION">DESCRIPTION</h1>
+
+<p>This SpamAssassin plugin module provides eval tests for whitelisting and blacklisting particular strings in the Subject header. String will match anywhere in the subject. The value for whitelist_subject or blacklist_subject are strings which may contain file -glob -style patterns, similar to the other whitelist_* config options. Note that each subject/string must be a separate *_subject command, all whitespace is included in the string.</p>
+
+
+</body>
+
+</html>
+
+