Solved "Spam" messages forwarding correctly via Forwarding sieve rule?

[d19dotca]

Hi @girish - just continuing the conversation a little bit from the other thread...

I created a mailbox for the one user which used to be a mailing list. The goal was to ensure the recipient gets their spam messages too due to the sensitive nature of their job (their target email off-box should be doing the spam filtering, not me at the Cloudron level).

The mailbox has the following sieve filter set (which was used with the "Forwarding" feature in Roundcube there):

# rule:[Forwarding]
if true
{
	redirect "targetEmail@example.com";
}

However, it seems that spam is still not being forwarded to the recipient as it gets caught in the spam folder and the email server logs never seem to indicate it gets forwarded on either compared to when a message is not marked as spam. So it doesn't seem this solves the problem in my case at all.

Anything I'm doing wrong here?

[girish]

@d19dotca the user sieve filters cannot process spam because spam processing happens before user filters are processed. so at this point, what we have is: mailing lists which won't forward spam and mailbox + sieve rule which cannot process spam.

[girish]

@d19dotca thinking more about this what we can do is to maybe disable the code that disable spam forwarding for lists on your server (this basically bring you back to 6.2 behavior). maybe it saves you a lot of trouble having to experiment with all these things. If you write to support@cloudron.io, i can do that.

The idea would be that we get this sorted in the next release.

[d19dotca]

the user sieve filters cannot process spam because spam processing happens before user filters are processed. so at this point, what we have is: mailing lists which won't forward spam and mailbox + sieve rule which cannot process spam

@girish I'm a bit unsure why the suggestion was made to convert into a mailbox instead of mailing list then if that can't work either then. In the other post, you wrote:

A work around is to simple create a mailbox and then create a forward (this forwards everything)

And so I acted on that, but seems like that's not working either then.

what we can do is to maybe disable the code that disable spam forwarding for lists on your server (this basically bring you back to 6.2 behavior). maybe it saves you a lot of trouble having to experiment with all these things.

I really don't mind at all with experimenting with these things, as long as I at least have a little bit of control. haha. I'd hate to go back to an older version's behaviour mostly for fear that this may cause issues down the road with future updates or something like that. If it can be fixed within the next week or so, it may be okay. If it will be a long while yet then I guess I may need to go that route.

I really wish it was just updated to allow disabling spam filtering on a mailing list since they are different than a mailbox and spam filtering on a mailing list is a bit more critical than on a mailbox where users can at least access the spam messages if needed from the spam folder - I strongly feel this is how it should have been designed from the beginning since as we both agree the current spam controls are ridged and not very flexible. Once that changes, then I agree that this feature may be completely unnecessary to disallow spam filtering, but until such time as those features are present, then we really need that option.

[girish]

@d19dotca I think I confused myself and misled you into creating a mailbox. Just to clarify it all again:

• Mailing list will not forward spam. It detects spam using the X-Spam-Score header which spamassassin sets.
• This means that you can control what is spam by adding custom Spam Assassin rules. For example, I add this rule below and send it with the subject as test and gtube body. The mail gets forwarded. Without it, the mail is not forwarded as spam.

header LOCAL_DEMONSTRATION_SUBJECT	Subject =~ /\btest\b/i
score LOCAL_DEMONSTRATION_SUBJECT	-1000

I think for your case, we essentially want to mark mails for a specific mailbox as not spam entirely. So, I think we need something like below (the list name is founders@cloudron.space). Because a mailing list gets "translated", we have to use the X-Envelope-To header which the mail server attaches to all mail.

header PASS_EVERYTHING_THROUGH	X-Envelope-To =~ /founders@cloudron\.space/i
score PASS_EVERYTHING_THROUGH	-1000

Would something like the above work? Please ignore what I said about mailboxes. That won't work because user sieve filters are run after spam processing and spam mail never reaches user sieve filters.

[d19dotca]

@girish Ah okay, no worries, it happens. Thanks for clarifying it.

Interesting approach. So in other words, a sort of "workaround allowlist" for SpamAssassin would be creating a new rule that checks the X-Envelope-To and give it a value of something like -100 which will prevent it from being flagged as spam. Right? That may work then! I'll give it a try. Great idea Girish! I'll let ya know how it goes.

[d19dotca]

I've set them now accordingly. Looking fruther into it, I see that there may be an easier option of whitelist_to <emailAddress> based on what I see in https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html#WHITELIST-AND-BLACKLIST-OPTIONS

I wonder if that'd be a cleaner option to add, seems like it may be set in the same area as all the rules and scoring lines.

[d19dotca]

I can confirm through testing that if I add a section to the SpamAssassin rules such as the following, this works! So this is a great workaround to not having direct whitelisting capabilities, using the whitelist_to rule and score.

# whitelisting addresses
score USER_IN_WHITELIST_TO -1000
whitelist_to email1@example.com
whitelist_to email2@example.com

Using the above (but of course substituting the actual email addresses) worked in my testing. I think this is a "cleaner" method and sees to work well (so far).

Side note: I just made the USER_IN_WHITELIST_TO score so low because of the GTUBE test which has such a high score itself, that way I can make sure it gets delivered to the inbox directly in my testing using GTUBE messages.

[d19dotca]

Slightly related note: It looks like whitelist_to is deprecated (so it still works for now) and is to be replaced by welcomelist_to but when I set this I get the following error: Bad syntax in custom config (lint failed)

It seems that a new 'plugin' for SpamAssassin must be enabled for that to work, so just a heads up for future versions as this may need to be added / enabled to keep the whitelist_to functionality working in future versions.

Reference: https://github.com/apache/spamassassin/blob/39ea11b27b55f99a945d2542779175d393d35334/rules/60_whitelist.cf & https://github.com/apache/spamassassin/blob/a83ce43f4f67ed996c0331a2ef8bc693161c4bd2/lib/Mail/SpamAssassin/Conf.pm

[girish]

Good notes to follow up when we look into email in the next release.

IIRC, whitelist setting is a bit dangerous because it allows "spoofed" emails as it pretty much bypasses all the SPF/DMARC/DKIM checks. Meaning, Cloudron does not reject mail if those checks do not pass because there are too many misconfigured mail servers out there. Instead we tag the failures and allow spamassassin to score the rules. whitelisting makes spamassassin bypass the checks altogether.