Normalize scores with sender reputation records.
warden --task=antispam:plugin:txrepOption |
Value | Default | Description |
|---|---|---|---|
--use_txrep |
<1|0> | 1 | 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. |
--txrep_factor |
<0-1.0> | 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 will move to half way between the calculated score and the new mean value. If factor = 0.3, then we will 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 |
<0.7-1.0> | 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 senders 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 |
<0-20> | 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 |
<0-200> | 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 |
<0-5> | 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 |
<1|0> | 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_welcomelist_out |
<string> | 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 |
<0-32> | 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 |
<0-128> | 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. |
--txrep_spf |
<1|0> | 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). |
--txrep_weight_email |
<int> | 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 the 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. We recommend using a relatively low value for this partial reputation. |
--txrep_weight_email_ip |
<int> | 10 | This is the standard reputation used in the same way as it was by the original AWL plugin. Each senders 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 |
<int> | 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 |
<int> | 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 |
<int> | 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. |
--default |
<yes> | Reset all settings to their default values. | |
--default_option |
<option> | Reset a specific setting to its default value. | |
--reload |
<yes> | Reload the service after saving settings. |
// disable txrep
warden --task=antispam:plugin:txrep --use_txrep=0 --reload=yes
// reset use_txrep to its default value
warden --task=antispam:plugin:txrep --default_option=use_txrep --reload=yes
// reset all settings to their default values
warden --task=antispam:plugin:txrep --default=yes --reload=yes