Bug 8126 - unable to manage global WL / BL
Summary: unable to manage global WL / BL
Status: REOPENED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: 4.0.0
Hardware: PC FreeBSD
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-08 07:53 UTC by martin
Modified: 2023-05-11 05:41 UTC (History)
3 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description martin 2023-05-08 07:53:01 UTC 
We have txrep and user preferences in a database.
In local.cf, I set user_awl_sql_override_username to 0 (we use user's ids in the database)
txrep_user2global_ratio is set to 5.

Now, txrep itself is working and adds rows to the table both with the specific user's id and 0 as the "global" id.

However, if - as root - I run this:

spamassassin --add-addr-to-welcomelist=somedomain.tld,spf

the username being used for the purpose of txrep is not '0'.
Also, no entries whatsoever are being added to (or modified) in the txrep table using this command.

To make matters worse:
The spamassassin command does not (like sa-learn or spamc) allow overriding the username.
spamc on the other hand cannot be used to issue for the --add-addr-to-welcomelist functionality.

At the moment, this seems to me to prevent me from managing the global WL or BL.

I guess I must be missing something? Does all this work as intended?
Comment 1 Bill Cole 2023-05-10 19:39:46 UTC 
user_awl_sql_override_username is a username. It is NOT a number, unless you have users who have numbers as their usernames…  Please review the documentation for its possible values and usage. 

Also note: SpamAssassin refuses to run as 'root' in some circumstances. If your users do not have unique UIDs, you should use an unprivileged account for managing per-user databases.
Comment 2 martin 2023-05-11 04:58:33 UTC 
(In reply to Bill Cole from comment #1)
> Also note: SpamAssassin refuses to run as 'root' in some circumstances. If
> your users do not have unique UIDs, you should use an unprivileged account
> for managing per-user databases.

I am not sure I managed to convey what the problem is, so let me rephrase:

Ignore what I said about numbers. It does not matter anyway as tried with uuids and it does not change a thing.

txrep itself works. Per user-stuff works.
Entries are added in the database for individual users and for the 'global' reputation. It is all virtual users anyway, there are no system users involved anywhere.

The txrep table is filled exactly how I would expect and it matches the documentation just fine.

As soon as I want to manage either individual or global blocklists or welcomelists, though, none of this works.

I am unable to modify global welcomelists / blocklists using
spamassassin --add-addr-to-welcomelist=somedomain.tld,spf

Running that command will NEITHER produce error / warning output NOR modify the txrep database table in any way.
Comment 3 Henrik Krohns 2023-05-11 05:41:13 UTC 
(In reply to martin from comment #0)
>
> To make matters worse:
> The spamassassin command does not (like sa-learn or spamc) allow overriding
> the username.
> spamc on the other hand cannot be used to issue for the
> --add-addr-to-welcomelist functionality.

Looks enough reason alone to keep this bug open.

I just copy pasted the -u option from sa-learn to spamassassin:

Sending        trunk/lib/spamassassin-run.pod
Sending        trunk/spamassassin.raw
Transmitting file data ..done
Committing transaction...
Committed revision 1909738.