I have reset the changes and started afresh (hence the force push, and, a need to re-review everything 😆). The new var SPAM_SUBJECT is agnostic of the underlying anti-spam system. This should better reflect maintainer's views (including mine) and help transitioning between anti-spam systems.

PS: @polarathene noted there is no equivalent of SA_KILL in conjunction with SPAMASSASSIN_SPAM_TO_INBOX. This is, IMO, useless with Rspamd: just set reject = 100; in Rspamd's configuration. This way, no e-mail will be rejected if that's what you're after. Just a side note, unrelated to changes made in this PR.

For visibility / discoverability, since the feedback has been hidden, related Sieve insights / advice related to spam:

• Spam extensions for better integration / logic and support if ever necessary.
• Sieve example for supporting _SCORE_ tag functionality of Amavis+SA. Also includes references to several rspamd headers
• Supporting both anti-spam services spam flag headers in Sieve
• Related issues / background, including a difference in support / behaviour between Amavis+SA and rspamd for ensuring delivery.

there is no equivalent of SA_KILL in conjunction with SPAMASSASSIN_SPAM_TO_INBOX. This is, IMO, useless with Rspamd: just set reject = 100; in Rspamd's configuration. This way, no e-mail will be rejected if that's what you're after

SA_KILL is basically the equivalent of your reject rspamd setting, except it was agnostic to the action taken, it was a score threshold that triggered a different final action, however DMS only supported adjusting that action between D_PASS and D_BOUNCE via SPAMASSASSIN_SPAM_TO_INBOX toggle.

In the past users had done the same workaround approach by setting SA_KILL to 1000. However SA_KILL also triggered some other behaviour such as adding a copy to quarantine. It was basically a marker for what is definitely spam, and the quarantine could be used for spam training, while still allowing the mail through to the junk folder.

I don't know how useful either of the two settings really are for users to configure though, just that we previously defaulted to D_BOUNCE and that was not what users were happy with, but at the time SA_KILL was set to 6.31 like SA_TAG2, which meant if it was considered as flagged for spam it'd be bounced without the user knowing. Legitimate mail was scoring 8 in some cases. SA_KILL was later bumped to 10, which came after changing the default D_BOUNCE to D_PASS (deliver to users junk).

I don't know how well rspamd reject maps to SA scores, but if they're roughly equal I guess that's fine and we won't have any user complaints 🤷‍♂️ Just bringing up that difference in support between the two services in DMS for awareness.

@polarathene It seems like #3838 broke our docs preview deployment (https://github.com/docker-mailserver/docker-mailserver/actions/runs/7679465094/job/20930390342)?

Few adjustments and it looks good to go 👍

🚀

May want to wait to see if @casperklein has any input regarding this change impact to SpamAssassin / SA_SPAM_SUBJECT?

👍🏼

@polarathene It seems like #3838 broke our docs preview deployment

Oh damn, I didn't pay attention to the difference in similar parameter names _ => -, whoops! 😬

I've read #3804. Did I understand it correctly, that rspam is not capable of adding a X-SPAM Header and at the same time changing the subject? That's a pity 😆

I really don't like when features are reinvented (in sieve) that are build-in and working perfectly in SA 😞 IMO this is the job of a spam filter and not dovecots..

Code LGTM. Just one thing, see above.

Documentation preview for this PR is ready! 🎉

Built with commit: 6364495

I've read #3804. Did I understand it correctly, that rspam is not capable of adding a X-SPAM Header and at the same time changing the subject? That's a pity 😆

Indeed; I originally assumed this was the case. It really is a shame..

I really don't like when features are reinvented (in sieve) that are build-in and working perfectly in SA 😞 IMO this is the job of a spam filter and not dovecots..

I agree, but here I guess "it is what it is" fits most. With this change, we're one step closer to being agnostic to the underlying anti-spam (a silver lining), though.

Hey!

Thanks very much for this.

Is there a summary somewhere of what the breaking changes will be for this?

Many thanks, again! 🥳

Yes, there is - have a look at our changelog (CHANGELOG.md) 👍🏼

For reference here is the rspamd issue report I was referring to when I said that I did think that this PR would probably fix my spam rewrote emails not being moved to Spam folder : rspamd/rspamd#3078 (comment)

To be confirmed