Mail::SpamAssassin::PlUser:Contributed PerMail::SpamAssassin::Plugin::TxRep(3)
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.
_TXREPXXXY_ TXREP modifier
_TXREPXXXYMEAN_ Mean score on which TXREP modification is based
_TXREPXXXYCOUNT_ Number of messages on which TXREP modification is based
_TXREPXXXYPRESCORE_ Score before TXREP
_TXREPXXXYUNKNOWN_ 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, EMAILIP, 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 AT 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.
perl v5.26.3 2022-04-Mail::SpamAssassin::Plugin::TxRep(3)
Linux-Distributionen
Huschi als Linux-Admin