Rspamd and aliases

J

jigster

Verified User
Joined
Jul 23, 2021
Messages
118
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.
 
I have a problem on a server where forwarded emails are not scanned, but this only occurs on one server, even though the configuration appears to be identical. The destination server for the forwards then scans the emails and rejects them, which leads to bounces on the server that does not scan the forwards.


Where in rspamd are the settings for scanning on forwarders?
 
I came here to report this same problem, but found that you already posted it.

After a bit more experimentation, here is what I have found works (with a couple of issues):

You have bob@domainA forwarding to john@domainB. bob@domainA does not have a mailbox, it is only a forwarder. Both domains are on the same server (no external forwarding in this scenarion)

Set both domains to the same spam settings EXCEPT set domainA to deliver to Inbox and set domainB to deliver to the user spam folder. This way, the spam going to domainA gets marked as spam (and subject tagged if desired) and then it gets sent to domainB (with the subject tagging) and domainB puts it into the spam folder.

IF you telll domainA to put it into user spam folder, then it tries to go to a non-existant folder (as that user doesn't actually exist) and ends up inside the default spam folder which seems impossible to access.

IF you disable spam checking on domainA, then it will still go to spam on domainB but it will not have subject tagging.

This has problems though:

First, I assume that the forwarded messages are double-spam checked (and using double the resources per message).

Second, since the spam settings are global per domain, if you have any real accounts on domainA, those users will be getting their spam into their inbox instead of their spam folder. This could be mitigated if there was a way to have separate spam controls per user instead of per domain only.
 
mejay said:
After a bit more experimentation, here is what I have found works (with a couple of issues):
Click to expand...
Thanks for the input. It's even more of a struggle if the forwarder points to the SAME domain. Having spam settings per email user would be very useful and would at least allow for some control of this situation. I've just started a feature request over at https://feedback.directadmin.com (yet to be published).
 
Sieve rules work if rspamd does not move the email first. Make sure that your spam settings are set to leave the email in the inbox, and then setup your sieve rules to move it to the user spam folder. (I used subject contains spam because I am doing subject tagging, but you should be able to use header instead if you aren't tagging). I just tried this myself with the subject filter and it worked properly. The same-domain forwarded spam went to the user spam folder. It also worked for non-same-domain forwarded spam.
 
You must log in or register to reply here.
Back
Top