in lib/Mail/SpamAssassin/Plugin/TxRep.pm [239:1123]
sub set_config {
###########################################################################
my($self, $conf) = @_;
my @cmds;
# -------------------------------------------------------------------------
=head1 USER PREFERENCES
The following options can be used in both site-wide (C<local.cf>) and
user-specific (C<user_prefs>) configuration files to customize how
SpamAssassin handles incoming email messages.
=over 4
=item B<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'
=cut
push (@cmds, {
setting => 'use_txrep',
default => 0,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_BOOL
});
=item B<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 (C<total> and C<count>), and then once we have
otherwise fully calculated the score for this message (C<score>), we calculate
the final score for the message as:
finalscore = score + factor * (total + score)/(count + 1)
So if C<factor> = 0.5, then we'll move to half way between the calculated
score and the new mean value. If C<factor> = 0.3, then we'll move about 1/3
of the way from the score toward the mean. C<factor> = 1 means use the
long-term mean including also the new unadjusted score; C<factor> = 0 mean
just use the calculated score, disabling so the score averaging, though still
recording the reputation to the database.
=cut
push (@cmds, {
setting => 'txrep_factor',
default => 0.5,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 1.0) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_factor} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_dilution_factor',
default => 0.98,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0.7 || $value > 1.0) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_dilution_factor} = $value;
}
});
# TODO, not implemented yet, hence no advertising until then
# -------------------------------------------------------------------------
#=item B<txrep_expiry_days>
#
# range [0..10000] (default: 365)
#
#The scores of of messages can be removed from the total reputation, and the
#message tracking entry removed from the database after given number of days.
#It helps keeping the database growth under control, and it also reduces the
#influence of old scores on the current reputation (both scoring methods, and
#sender's behavior might have changed over time).
#
#=cut # ...................................................................
push (@cmds, {
setting => 'txrep_expiry_days',
default => 365,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10000) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_expiry_days} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_learn_penalty',
default => 20,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 200) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_learn_penalty} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_learn_bonus',
default => 20,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 200) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_learn_bonus} = $value;
}
});
=item B<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 L</C<txrep_learn_penalty>>,
resp. the L</C<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.
=cut
push (@cmds, {
setting => 'txrep_autolearn',
default => 0,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 5) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_autolearn} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_track_messages',
default => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_BOOL
});
=item B<txrep_welcomelist_out>
range [0..200] (default: 10)
Previously txrep_whitelist_out which will work interchangeably until 4.1.
When the value of this setting is greater than zero, recipients of messages sent from
within the internal networks will be welcomelisted 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 welcomelisted. The domain name is intentionally also left
unaffected. The outbound welcomelisting 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
C<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.
=cut
push (@cmds, {
setting => 'txrep_welcomelist_out',
aliases => ['txrep_whitelist_out'], # removed in 4.1
default => 10,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 200) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_welcomelist_out} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_ipv4_mask_len',
default => 16,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if (!defined $value || $value eq '')
{return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
elsif ($value !~ /^\d+$/ || $value < 0 || $value > 32)
{return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_ipv4_mask_len} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_ipv6_mask_len',
default => 48,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if (!defined $value || $value eq '')
{return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
elsif ($value !~ /^\d+$/ || $value < 0 || $value > 128)
{return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_ipv6_mask_len} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'user_awl_sql_override_username',
default => '',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<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 welcomelisted or blocklisted
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 C</auto_welcomelist_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 C<user_awl_sql_override_username> resp.
C<auto_welcomelist_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.
=cut
push (@cmds, {
setting => 'txrep_user2global_ratio',
default => 0,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_user2global_ratio} = $value;
}
});
=item B<auto_welcomelist_distinguish_signed> (default: 1 - enabled)
Previously auto_welcomelist_distinguish_signed which will work interchangeably until 4.1.
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.
=cut
push (@cmds, {
setting => 'auto_welcomelist_distinguish_signed',
aliases => ['auto_whitelist_distinguish_signed'], # removed in 4.1
default => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_BOOL
});
=item B<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 forged
ones) would be treated as coming from the authorized source. However, such
domains are hopefully rare, and ask for this kind of treatment anyway.
=back
=cut
push (@cmds, {
setting => 'txrep_spf',
default => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_BOOL
});
=head2 REPUTATION WEIGHTS
The overall reputation of the sender comprises several elements:
=over 4
=item 1) The reputation of the 'From' email address bound to the originating IP
address fraction (see the mask parameters for details)
=item 2) The reputation of the 'From' email address alone (regardless the IP
address being currently used)
=item 3) The reputation of the domain name of the 'From' email address
=item 4) The reputation of the originating IP address, regardless of sender's email address
=item 5) The reputation of the HELO name of the originating computer (if available)
=back
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.
=over 4
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_weight_email',
default => 3,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_weight_email} = $value;
}
});
=item B<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_welcomelist_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.
=cut
push (@cmds, {
setting => 'txrep_weight_email_ip',
default => 10,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_weight_email_ip} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_weight_domain',
default => 2,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_weight_domain} = $value;
}
});
=item B<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).
=cut
push (@cmds, {
setting => 'txrep_weight_ip',
default => 4,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_weight_ip} = $value;
}
});
=item B<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.
=cut
push (@cmds, {
setting => 'txrep_weight_helo',
default => 0.5,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value < 0 || $value > 10) {return $Mail::SpamAssassin::Conf::INVALID_VALUE;}
$self->{txrep_weight_helo} = $value;
}
});
=item B<txrep_report_details>
0 | 1 | 2 (default: 0)
Add TxRep details to the rule's description in the message report or summary,
similar to how RBL rules commonly are showing listed domains.
If enabled (value 1) the identificators (From address bound to originating IP
address fraction, From address alone, domain name bound to originating IP
address fraction, originating IP address and HELO if available) used in
calculating the sender's overall reputation are listed, including the
originating IP address fraction (according to the mask settings) where
applicable.
If this option is set to 2, the listed identificators' individual mean
reputation and count are reported in addition.
Identificators and additional data will only be added to the description on a
message's initial scan. Re-processing a previously already scanned message
will not list the individual idenficators and their respective reputation
values used originally.
This option is disabled by default for now, due to potential formatting issues
caused by the number and length of additional description details.
=cut
push (@cmds, {
setting => 'txrep_report_details',
default => 0,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE
if ($value eq '');
return $Mail::SpamAssassin::Conf::INVALID_VALUE
unless ($value =~ /^[012]$/);
$self->{txrep_report_details} = $value;
}
});
=back
=head1 ADMINISTRATOR SETTINGS
These settings differ from the ones above, in that they are considered 'more
privileged' -- even more than the ones in the B<PRIVILEGED SETTINGS> section.
No matter what C<allow_user_rules> is set to, these can never be set from a
user's C<user_prefs> file.
=over 4
=item B<txrep_factory module>
(default: Mail::SpamAssassin::DBBasedAddrList)
Select alternative database factory module for the TxRep database.
=cut
push (@cmds, {
setting => 'txrep_factory',
is_admin => 1,
default => 'Mail::SpamAssassin::DBBasedAddrList',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<auto_welcomelist_path /path/filename>
(default: ~/.spamassassin/tx-reputation)
Previously auto_whitelist_path which will work interchangeably until 4.1.
This is the TxRep directory and filename. By default, each user
has their own reputation database in their C<~/.spamassassin> directory with
mode 0700. For system-wide SpamAssassin use, you may want to share this
across all users.
=cut
push (@cmds, {
setting => 'auto_welcomelist_path',
aliases => ['auto_whitelist_path'], # removed in 4.1
is_admin => 1,
default => '__userstate__/tx-reputation',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING,
code => sub {
my ($self, $key, $value, $line) = @_;
unless (defined $value && $value !~ /^$/) {return $Mail::SpamAssassin::Conf::MISSING_REQUIRED_VALUE;}
$self->{auto_welcomelist_path} = $value;
}
});
=item B<auto_welcomelist_db_modules Module ...>
(default: see below)
Previously auto_whitelist_db_modules which will work interchangeably until 4.1.
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).
=cut
push (@cmds, {
setting => 'auto_welcomelist_db_modules',
aliases => ['auto_whitelist_db_modules'], # removed in 4.1
is_admin => 1,
default => 'DB_File GDBM_File SDBM_File',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<auto_welcomelist_file_mode>
(default: 0700)
Previously auto_whitelist_file_mode which will work interchangeably until 4.1.
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).
=cut
push (@cmds, {
setting => 'auto_welcomelist_file_mode',
aliases => ['auto_whitelist_file_mode'], # removed in 4.1
is_admin => 1,
default => '0700',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_NUMERIC,
code => sub {
my ($self, $key, $value, $line) = @_;
if ($value !~ /^0?[0-7]{3}$/) {
return $Mail::SpamAssassin::Conf::INVALID_VALUE;
}
$value = '0'.$value if length($value) == 3; # Bug 5771
$self->{auto_welcomelist_file_mode} = untaint_var($value);
}
});
=item B<user_awl_dsn DBI:databasetype:databasename:hostname:port>
Used by the SQLBasedAddrList storage implementation.
This will set the DSN used to connect. Example:
C<DBI:mysql:spamassassin:localhost>
=cut
push (@cmds, {
setting => 'user_awl_dsn',
is_admin => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<user_awl_sql_username username>
Used by the SQLBasedAddrList storage implementation.
The authorized username to connect to the above DSN.
=cut
push (@cmds, {
setting => 'user_awl_sql_username',
is_admin => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<user_awl_sql_password password>
Used by the SQLBasedAddrList storage implementation.
The password for the database username, for the above DSN.
=cut
push (@cmds, {
setting => 'user_awl_sql_password',
is_admin => 1,
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
=item B<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.
=back
=cut
push (@cmds, {
setting => 'user_awl_sql_table',
is_admin => 1,
default => 'txrep',
type => $Mail::SpamAssassin::Conf::CONF_TYPE_STRING
});
$conf->{parser}->register_commands(\@cmds);
}