Rspamd and aliases

J

jigster

Verified User
Joined
Jul 23, 2021
Messages
116
If a domain has email forwarders, it seems that any spam detected by rspamd (and spamassassin) for those forwarders is being moved to the spam folder of the account's admin user. This is fine for forwarders pointing to external addresses, but when the alias points to an email address in the same account/domain, we would like the spam to be placed in the spam folder of the destination address in the same domain.

I've looked at the rules in /usr/local/directadmin/data/templates/filter_userspamfolder (after reading https://docs.directadmin.com/change...t-to-save-to-spambox-if-account-doesn-t-exist), but not sure how these rules could be modified/extended to check if the forwarder destination is local and if so, send the spam there (to the spam folder), not the admin's? Any ideas anyone? Thanks
 
rSpamd checks incoming emails at the very first arrive and apply actions per settings. Probably another result (per your needs) can be get by using Sieve rules. Once can adjust sieve rules using RoundCube webinterface, when using RoundCube for creating Sieve rules, they are applicable to a specific email account only. This is what came to mind only now, and I never tested it.

If you give it a try the sieve rules should be created under account's admin user.
 
Yeah that might work. We have a lot of email users who don't have access to the DA admin user so I'll need to automate any solution so it works when an email forwarder is set up. I guess I'd need a post-email-alias hook of some kind. I'll look into this idea, thanks.
 
I'm struggling with a sensible sieve rule: I believe sieve's 'fileinto' can only be used to move emails to a folder within the same account. And a 'redirect' to the forwarder destination would result in the email being rescanned by Rspamd, which seems like a waste of resources because the emails would have to be processed twice by Rspamd. But currently seems like the only option. Any other ideas?

Then I can use the DirectAdmin hook forwarder_(create|delete)_(pre|post).sh to automate the creation/deletion of the sieve rules.
 
jigster said:
Any other ideas?
Click to expand...

In theory when you process an email with Sieve you might add a custom header to such an email. Then you might check in Exim whether or not the header exists, and skip the second scan with rspamd if the header exists. And again, these are only my thoughts, and I did not test them in practice.
 
zEitEr said:
In theory when you process an email with Sieve you might add a custom header to such an email. Then you might check in Exim whether or not the header exists, and skip the second scan with rspamd if the header exists. And again, these are only my thoughts, and I did not test them in practice.
Click to expand...
Thanks, I did consider that as an option, along with using a pipe to a script, but it all seemed a bit complex for such a simple task! And a header that bypasses spam filtering might be vulnerable to abuse. Thanks for your help as always @zEitEr
 
Alternatively you might disable spam scanning of incoming emails to forwarders. This is the default behaviour of SpamAssassin. rSpamd scans all emails.

If none of these options work for you, then you might consider requesting the new option from Directadmin developers.
 
Disabling spam scanning of incoming emails to local-destination-forwarders (but do scan 'real' email addresses and also external-destination forwarders) sounds like the perfect solution. Any idea how to implement that? Strange that spamassassin doesn't scan incoming emails to forwarders but rspamd does. I thought DA had both set up more or less the same way.
 
Last edited:
It seems with the way DirectAdmin now moves spam to the spam folder (https://docs.directadmin.com/change...t-to-save-to-spambox-if-account-doesn-t-exist), sieve filters don't work at all on spam (it's not triggering dovecot sieve at all)! And this is for ALL email addresses, not just forwarders, so no users can't have individual sieve filters in Roundcube for spam emails. Is this an unintended bug, or known and considered acceptable?

Another issue with the way spam is moved: if you have a :fail: alias set up for an admin email account so emails bounce, DirectAdmin bypasses this, and moves the spam emails for forwarders to the admin address anyway. So it will just fill up with spam over time as no-one looks at the email (because it's supposed to bounce emails).

It would be so much better if the code in /usr/local/directadmin/data/templates/filter_userspamfolder could be altered so instead of moving emails to the admin user spam folder for forwarders, it checks the alias file and if the destination is in the same domain, it moves spam to the spam folder of the destination. Then only use the admin email spam folder for external forwarders (or even just blackhole those emails).

Just my thoughts! Anyway, for the purpose of this thread, sieve filters cannot be used as a solution for moving forwarder-spam, which severely limits the possible options!

The only option I can think of is to use the hook forwarder_(create|delete)_(pre|post).sh to check if a forwarder destination is local upon creation, and if yes to turn off spam checks for that forwarder. But this is not ideal as we'd prefer all emails to be scanned.
 
You must log in or register to reply here.
Back
Top