Originally Posted by cbj4074
Indeed I was missing something "obvious".
The solution is to include the --username switch to the 'sa-learn' executable, e.g.:
# sa-learn --username=amavis --spam /var/vmail/example.com/trainer/Maildir/.Spam/cur
This enables one to execute the command as "root" or "vmail", which provides for the necessary permissions, while at the same time adding the tokens to the "amavis" user's database.
Actually, this was not the solution; I was mistaken.
Users on the SpamAssassin mailing list pointed-out that the --username switch is intended for use with virtual user configurations, e.g., those tied to a SQL database of some kind. (It's worth noting that using an invalid --username doesn't throw a warning or error, and seems to use the current username instead.)
The solution was to "hard-code" the SpamAssassin Bayes database location in the configuration file (typically /etc/spamassassin/local.cf
on Debian/Ubuntu systems):
With this directive in-place, the sa-learn
command will always use the specified database (unless the --username argument is provided [and is valid]).
To ensure that the correct database is being used:
# spamassassin -D -t < /usr/share/doc/spamassassin/examples/sample-spam.txt 2>&1 | egrep '(bayes:|whitelist:|AWL)'
dbg: bayes: tie-ing to DB file R/O /var/lib/amavis/.spamassassin/bayes_toks
dbg: bayes: tie-ing to DB file R/O /var/lib/amavis/.spamassassin/bayes_seen
The directive is having the intended effect; even though the command is executed as "root", the Amavis user's database file is used.
Now, when training SpamAssassin, the sa-train
executable can be called as the "root" user, which allows for access to the mailboxes in /var/vmail
while at the same time populating the correct Bayes database (Amavis's).