On Tuesday 22 June 2004 21:58, p dont think might have typed:
> All,
>
> Appologies for top-posting, but it seems best to start off with a
> summary:
>
> I have the same need as Shaun, which is to keep user prefs in a database,
> where they are easily accessed by other tools, however, I have no need (nor
> desire) to migrate our Bayes and AWL databases into SQL.
> Ideally, I'd simply like to add the -q option to spamd (and have spamd
> know that everything besides user prefs is still in the location listed by
> the virtual-config-dir parameter), but that's just not how it works ATM.
> Or 2nd best would be to have some setting in the user prefs that points to
> a HOME directory... bayes_path *might* work (haven't tried because there's
> no awl_path anyway), but I digress.
One of the systems I run, uses per-user Bayes DBs, but all of the user prefs
are stored in SQL. A minor hack to Conf.pm was needed to make spamd
recognise this.
DB: email
Table: spamassassin
+-------------------+---------------------+----------------------------------------------------+--------+
| username | preference | value
| prefid |
+-------------------+---------------------+----------------------------------------------------+--------+
| [EMAIL PROTECTED] | required_hits | 3
| 2 |
| [EMAIL PROTECTED] | rewrite_subject | 1
| 3 |
| [EMAIL PROTECTED] | subject_tag | [SPAM _HITS_]
| 4 |
| [EMAIL PROTECTED] | report_safe | 1
| 5 |
| [EMAIL PROTECTED] | bayes_path | /path/to/dhill/.spamassassin |
6 |
| [EMAIL PROTECTED] | auto_whitelist_path | /path/to/dhill/.awl |
7 |
local.cf:
user_scores_dsn DBI:mysql:email:localhost:3306
user_scores_sql_username USER
user_scores_sql_password PASS
user_scores_sql_table spamassassin
Conf.pm:
sub parse_scores_only {
my ($self) = @_;
$self->_parse ($_[1], 0); # don't copy $rules!
}
Normally, that 0 is a 1, which prevents the bayes_path etc from loading.
Bit of a dirty hack, but it works wonders :)
