wiki:load-sa-rules.pl

The load-sa-rules.pl script

This script scans certain directories on your server, looking for SpamAssassin rules to add to the Maia Mailguard database. If it finds a rule it doesn't know about yet, the rule gets added to the database. If it finds a known rule, it updates the rule's score as necessary, in the event it may have changed. You should run this script as a "finishing step" every time you update your SpamAssassin rules, to ensure that Maia Mailguard always has the most up-to-date set of SpamAssassin rules and scores in its database.

You can safely run this script anytime you add new SpamAssassin rules or update your SpamAssassin rule files with new scores. The script will not add the same rule twice, but it will update the score value of a rule that it has seen before. If you use a scheduled job to fetch updated versions of popular SpamAssassin rule sets, e.g. RulesDuJour and/or sa-update, add this script to the end of your update job to make sure the changes are picked up by Maia Mailguard.

If you use the RulesDuJour script to automatically update your third-party SpamAssassin rules for you (highly recommended), you'll want to modify the SA_RESTART setting in the /etc/rulesdujour/config file to ensure that it runs load-sa-rules.pl after it makes any rule changes:

SA_RESTART="/var/amavisd/maia/scripts/load-sa-rules.pl;/etc/init.d/amavisd restart";

If you use the sa-update script to update your core SpamAssassin rules (also highly recommended), you'll want to chain your commands so that load-sa-rules.pl gets called whenever a rules update takes places:

sa-update && /var/amavisd/maia/scripts/load-sa-rules.pl && /etc/init.d/amavisd restart

The following command-line options are supported:

--local-cf-dir=<directory>     : SpamAssassin local.cf directory
--system-rules-dir=<directory> : SpamAssassin core rules directory
--user-rules-dir=<directory>   : SpamAssassin user_prefs directory
--help                         : display this help text
--debug                        : display detailed debugging information
--quiet                        : display only error messages

These rules directories can also be specified in the /etc/maia.conf file:

$system_rules_dir is the first place SpamAssassin looks for its rules. These are the core rules as issued by the SpamAssassin development team. When initially installed, these rules are usually in /usr/share/spamassassin or somesuch, but if you use the sa-update script to automatically update your core rules, these will typically end up in /var/lib/spamassassin/%%VERSION%%. SpamAssassin will always look for the updated version first, and will ignore the older rules if updated rules are available. For that reason alone, it's often best to leave $system_rules_dir = undef, to let the script use SpamAssassin's own logic to find the correct directory.

# The directory where SpamAssassin's core rules can be found.
# If you wish to specify the directory yourself, you can use the
# %%VERSION%% macro to replace the actual SpamAssassin version number.
#$system_rules_dir = "/usr/share/spamassassin";
#$system_rules_dir = "/var/lib/spamassassin/%%VERSION%%";  # sa-update
$system_rules_dir = undef;  # default: let the script find it

$local_cf_dir is the directory where SpamAssassin's local.cf file can be found. SpamAssassin looks here for any site-wide rule overrides here--rules loaded later override earlier rules, so if you want to modify a rule's score, it's traditional to do so in a *.cf file in this directory, such as the local.cf file itself. Usually the script can find this directory well enough on its own, but if for some reason it's not finding it properly you can tell it explicitly where to look with this setting.

# The directory where SpamAssassin's local.cf file can be found.
#$local_cf_dir = "/etc/mail/spamassassin";
$local_cf_dir = undef;  # default: let the script find it

$user_rules_dir is where your amavis user's user_prefs file can be found. This optional file can contain user-specific rule overrides. In a Maia Mailguard installation, there's only one "user" as far as SpamAssassin is concerned, so there's really no reason to put overrides in the amavis user's user_prefs file--you'd be just as well off putting your overrides in the system's local.cf file instead. Still, the script will look for rule overrides in this directory as well, because SpamAssassin will.

# The directory where your amavis user's user_prefs file can be found.
#$user_rules_dir = "/var/amavisd/.spamassassin";
#$user_rules_dur = "~/.spamassassin";
$user_rules_dir = undef;  # default: let the script find it
Last modified 15 years ago Last modified on Apr 13, 2006, 12:16:42 AM