On 16.09.24 13:07, Sirius wrote:
On mån, 2024/09/16 at 11:41:24 +0200, Richard via dovecot wrote:
On 16.09.24 09:50, Sirius wrote:
On sön, 2024/09/15 at 14:30:19 +0200, Richard via dovecot wrote: [snip] I do the same as you. Not exactly. I'm on rspamd 3.9.1-1~82f43560f~bookworm. From rspamd's repo. Ah, that may be the source of your problems.
Parts of my problem, but not in this case actually. My solution is now in the thread with Aki Tuomi. Seems to have been an unlucky combination of outdated rspamc handling and using bash's "exec" where it seems to not belong.
I only have sieve_global_extensions enabled. As user scripts aren't supposed to be able to access external programs I don't see any benefit configuring that setting I did it in case I want to have stricter personal settings than the rest of my family. The default global sieve cuts spam off at a score of 10. Personally, I may end up lowering that to 8.0-8.5 somewhere.
Good to know
[snip]
sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environmentI only had +vnd.dovecot.pipe in here. Let's the if adding +vnd.dovecot.environment changes anything.
sieve_spamtest_status_type = score sieve_spamtest_status_header = X-Spam_score: (-?[[:digit:]]+\.[[:digit:]]) sieve_spamtest_max_value = 6 sieve_before = /etc/dovecot/sieve/global-spam.sieveI never configured these. What are their use? I've just set up another sieve script (which seems to be working just fine) to sort out all messages marked as spam into the users junk directory. Is this just to do that? This comes from https://github.com/darix/dovecot-sieve-antispam-rspamd/ which is what I ended up adapting as it was not an exact match for my environment.
First two lines does the spam testing based on the score rspamd have assigned the incoming message (hence the last three sieve extensions in the section above).
Interesting solution. Didn't know dovecot could do that. I have a larger sieve script that will match all messages containing a spam flag in the header - our spam filter is actually a secondary one, because while the primary is a commercial one, it's pretty bad so it misses a lot - and some typical keywords from the subject you won't ever find in a legit mail and move them to junk. Also, I have some logic to help keep ham out of the junk directory if rspamd is falsely categorizing mail as spam from known trustworthy senders, as rspamd's whitelisting is quite flaky.
The only other thing was to get the password out of /etc/rspamd/worker-controller.inc and put it in /etc/dovecot/rspamd-controller.password (or whatever file your learn-{sp,h}am script points at to get the password). It needed to be pointed at 127.0.0.1:11334 for the socket. What is the password needed for? Because manually executing rspamc doesn't ask for some password either. The worker-controller.inc does point at 127.0.0.1 and ::1, but no port seems to be configured. When you connect to rspamd controller (port 11334), it is authenticated. Presumably so that not just anyone can report spam/ham and mess up the scoring. If it runs only on loopback and there is no port-forwarding, authentication is perhaps unnecessary, but it makes sense to have it enabled anyway if someone else can log into the system as a regular user.
Good to know, but I think it may be safer to use worker-normal instead with setting allow_learn to true in its config. That way you don't need the higher privileges the controller has. And you shouldn't need the worker-controller's password. At least as far as I understand https://rspamd.com/doc/workers/normal.html. But I in my trials, sending mail to the port of worker-normal still requires the password of worker-controller. So that's only theoretical. Also, as all of this has no permissions for normal user to access it, it's a bit redundant.
Worth checking how rspamc calls into rspamd (maybe you use a socket in /run or similar) and see if they have defaulted to authentication on for the sockets. Or roll rspamd back to previous version for the time being.
Thankfully that's all resolved now adding the port to use (and currently the password, maybe that can be dropped somehow). So I guess rspamd changed its behavior at some point I didn't notice and deprecated the old ways.
But thanks for the details.