Raymond Wan wrote:
>
> Not pertaining to Debian (I think)... I was wondering in what
> order are SA's settings read in. Is this correct:
>
> 1) /etc/spamassassin/init.pre
> 2) /etc/spamassassin/local.cf
> 3) /usr/share/spamassassin/*.cf
> 4) ~/.spamassassin/user_prefs
Not quite. I believe the order is this:
1) /etc/spamassassin/*.pre
2a) /var/lib/spamassassin/3.001003/updates_spamassassin_org/*.cf
(if the directory exists)
2b) /usr/share/spamassassin/*.cf
(if the previous directory doesn't exist)
3) /etc/spamassassin/*.cf
4) ~/.spamassassin/user_prefs
Note that only one of 2a and 2b will be read, never both. If you have
run sa-update and created the updates directory, it will be used.
Otherwise, the original rules directory will be used.
> I also have a v310.pre and a v312.pre in /etc/spamassassin/. As I
> am running v3.1.3, can I assume they are backups of init.pre?
Nope, they are all different. v310.pre has plugin lines that were
added in SA 3.1.0. v312.pre has plugin lines that were added in
v3.1.2. They are all read and used by SA.
> I suppose if I change #1-#3, I have to restart the daemon, but not
> #4?
Correct. The user_prefs files are read each time an email comes
through for that user.
> I read in the FAQ that changes to #4 are not read by the SA daemon
> unless allow_user_rules is turned on. As the root user of a
> single-user system, should I turn it on (what is the reason for
> turning it off other
> than potentially slowing down the system; is there a security
> reason?) or should I move everything to #2?
The user_prefs file is always read for configuration changes.
allow_user_rules simply allows the users to create custom rules as
well as making simple changes. The main reasons to leave user rules
off is that they slow down the system and give the possibility of
users writing bad rules.
Everything possible should be in local.cf (or another cf file in that
directory). The only thing that should be in user_prefs are settings
that only apply to that one user.
> The only thing important in user_prefs is:
>
> # Speakers of Asian languages, like Chinese, Japanese and Korean,
> will almost # definitely want to uncomment the following lines. They
> will switch off some # rules that detect 8-bit characters, which
> commonly trigger on mails using CJK # character sets, or that assume
> a western-style charset is in use. #
> #score HTML_COMMENT_8BITS 0
> score UPPERCASE_25_50 0
> score UPPERCASE_50_75 0
> score UPPERCASE_75_100 0
> score OBSCURED_EMAIL 0
>
> which I honestly don't know what it means... :)
Scores for rules can be changed in user_prefs without enabling user
rules. Setting the score to 0 disables the rule. This allows users
to disable or lower the score of rules that they don't like.
In this case, these are rules that commonly trigger on Asian language
emails. So people who expect to see ham messages in those languages
should uncomment those score lines to disable the tests.
--
Bowie
