> A quick look through the spamassassin code notes
> that the SQL parsing does something similar to
> this for each row:
>
> "preference \t value \n"
>
> and joins them all together.
Hmm.. I could swear it uses preference\s+value (brb, checking code)
Line 224 of Conf/Parser.pm in sub parse() says
my($key, $value) = split(/\s+/, $line, 2);
yes, SQL.pm uses \t at line 152, but that is okay, because it feeds
$text to parse() in Parser.pm - If you set your database up right,
everything will work fine.
> preference name value
> describe RULE1 a description
> score RULE1 1.2
> required_score 5.0
mysql> select username,preference,value from sa_rules where preference
like 'score%' limit 2;
+-----------+-------------------------+-------+
| username | preference | value |
+-----------+-------------------------+-------+
| %nmgi.com | score USER_IN_BLACKLIST | 10 |
| $GLOBAL | score USER_IN_BLACKLIST | 10 |
+-----------+-------------------------+-------+
Works fine as you can see here...
[EMAIL PROTECTED] Conf]# echo -e "From: [EMAIL PROTECTED]" | spamc -u
'[EMAIL PROTECTED]' | grep USER_IN_BLACKLIST
* 10 USER_IN_BLACKLIST From: address is in the user's
black-list
And I know I've tested "describe RULE" as the preference in the past
and it works just fine also.
Give it a shot... I don't think there is a need to change this code.
The only thing that doesn't work with SQL prefs is defining new rules..
Body, header, full, etc. You can change the describe and score via SQL,
but for some reason, new rules cannot be read in from SQL due to the
timing of the call I believe. I haven't dug much deaper than that.
D
