PS:
I just did the following test:
As the user, filter.sh is executed as, I did test the following:
1. /usr/bin/vendor_perl/spamc -x -E -u ww < /tmp/spam
As the user, who owns the user_prefs, I did test the following:
2. /usr/bin/vendor_perl/spamc -x -E < /tmp/spam
3. spamassassin --test-mode -D < /tmp/spam
Unfortunately, spamc seems to not have a verbosity trigger ... so I can
only judge on the results:
1. This is, how the filter.sh issues the command. This brings the same
result like 2.
2. This brings the same result, I see in my Inbox: The mail gets
processed, but ~ww/.spamassassin/user_prefs seems to be ignored; the
mail only gets a score of 3.8.
3. When I execute the "spamassassin" - program, everything looks as if
it gets processed correctly: the user_prefs is read, the mail gets a
score of 100.1 and is considered spam.
So, does this mean I should switch to use "spamassassin" instead of
"spamc" in my filter.sh script instead? Manpage of spamc reads:
"""
Spamc is the client half of the spamc/spamd pair. It should be used in
place of "spamassassin" in scripts to process mail.
[...]
Spamc has extremely low overhead in loading, so it should be much faster
to load than the whole spamassassin program.
"""
- What is the "whole spamassassin program"; are there features missing
in spamc (like respecting user_prefs file)?
- Is it wise to use spamassassin when the developers intend spamc to be
used for this purpose?
- How do I get spamc to respect user_prefs file?
Best regards,
Marc
Am 09.09.2015 um 13:47 schrieb Marc Richter:
Hi jdow,
hi Matus,
thanks for your replies.
Regardless if it's necessary or not, I have done so. It also happens
regularly by cron (all 3 hours), along with other jobs like sa-learn,
sa-update and sa-compile.
> On 09.09.2015 11:12 Matus wrote:
>
> have you tried running spamassassin -D ? maybe there's somethign
> invalid in SA's configuration or your user_prefs
When I issue "spamassassin --test-mode -D" as the user the filter.sh -
runs as, I get this in the long output:
dbg: config: read file /var/lib/spamassassin/.spamassassin/user_prefs
So, it tries to read the user_prefs from the daemon's home, what is
clear, because it cannot know what user the file "belongs" to, in
test-mode.
When I run that as the user (ww) the mail and desired user_prefs belongs
to, it works, so no use in that.
How can I make use of the "-D" cmdline option in the normal mail-flow in
a way it gets logged by journald? Can I simply add "-D" to the filter.sh
script and it get's caught in journald's database?
How else can I test this?
Sorry if I'm slow in understanding atm ...
Best regards,
Marc
