Question Migration from Plesk Email Security (Amavis, SpamAssassin 3.x) to Rspamd 3.12 – Experiences?

[Jürgen_T]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.70

Hi everyone,
I'm planning to switch from the default Plesk Email Security stack (Amavis, SpamAssassin 3.x, Pyzor, Razor, etc.) to a more modern and efficient solution based on Rspamd 3.12 on my Ubuntu 22.04 server.

The decision comes mainly due to:

• a massive increase in spam recently, with more sophisticated techniques slipping past traditional filters, the lack of support for SpamAssassin 4.0.1 in Plesk Email Security (PES), which means we're stuck with an outdated and less effective version and the need for better performance, more transparency, and better integration with modern standards like DMARC, ARC, and neural scoring
  My current system:

• Plesk Obsidian v18.0.70
• Ubuntu 22.04.5 LTS
• Postfix + Dovecot
• Dedicated server with 32 GB RAM
• Manual integration of ClamAV and custom SpamAssassin rules in 50-user
• 
  
• I’ve set up Rspamd with ClamAV and DKIM/DMARC support as a native installation (not via Docker), and initial tests are promising. However, before fully decommissioning Amavis and SpamAssassin, I’d love to hear from others who've already done this.

Key questions:

1. Have you fully replaced Amavis + SpamAssassin with Rspamd under Plesk?
2. Any issues or caveats with Plesk's mail stack or control panel?
3. How stable is Rspamd in long-term production use with Plesk?
4. How do you manage spam learning and quarantine outside the PES UI?
5. Any recommendations for Rspamd performance tuning (e.g. with Redis or multithreading)?

I’d really appreciate your feedback and insights – especially if you’ve tackled similar challenges. Thanks in advance!


Best regards,
Jürgen

 

[Kaspar]

I don't have any experience with using Rspamd on a Plesk server. I don't think there should any issue using it with Plesk, but there is just no way to mange it from within Plesk (unless you create your own Plesk extension to do so).

I have used Rspamd in the past on other servers (just not with Plesk). I've never been really impressed with it's spam recognizing abilities. From what I remember it's more efficient (uses less server resources) and does a better job out of the box in recognizing spam compared to spamassassin. Rspamd has a pretty active community as well, which is nice. However I've found that there are many more options and plugins for spamassassin to tweak spamassassin which make spamassassin more powerfull and can outperformed Rspamd.

It might be different now, it's been a couple of years since I last used Rspamd. I've never bothered to use Rspamd again since spamassassin does a pretty good job for me (but I heavily customized my spamassassin setup).

 

[Jürgen_T]

Thanks for your input – much appreciated!


I totally agree with you: SpamAssassin can be extremely powerful when heavily customized. I’ve also maintained a fairly extensive setup over the years with custom rules in 50-user, Razor, Pyzor, DNSBL tuning, and even DKIM/ARC scoring workarounds. So yes – with enough tweaking, SA can really shine.

That said, my motivation to test Rspamd 3.12 stems from:

• the rising volume and sophistication of current spam attacks
• SA 4.0.1 not being available in Plesk Email Security
• and the need for better performance, faster processing, and modern scoring features (neural, ARC, etc.)

I’ve now implemented a full native (non-Docker) Rspamd setup with:

• Redis for Bayesian learning
• ClamAV integration
• DKIM/DMARC/ARC validation
• GeoIP-based scoring (e.g. country-specific weights)
• and custom rules with symbol reweighting for specific IP ranges and ASNs.

The results so far look promising, but I’m still fine-tuning the thresholds and learning behavior. I’ll be happy to share the results here after a few thousand messages have been processed – particularly regarding false positives and overall spam recognition.

Thanks again – it’s great to hear from someone who’s worked both sides of the fence.


Best regards,
Jürgen

 

[Jürgen_T]

I've recently put Rspamd 3.12 into full production as a complete replacement for Amavis + SpamAssassin on my Plesk server (Ubuntu 22.04, Obsidian 18.0.70) – natively installed, without Docker or containerization.

Current Setup:​

1. Postfix + Dovecot still managed through Plesk
2. Rspamd with Redis (Bayes, history, learning), ClamAV locally integrated
3. DKIM and DMARC checks active, initial testing of ARC handling (ARC sealing and verification) is underway
4. Multimap strategies for SURBL, ASN scoring, GeoIP, and custom sender lists (IP, domain, email)
5. Central whitelist/blacklist file applied to SPF/DKIM/DMARC/SURBL modules
6. IMAP-based spam/ham learning via cron scripts from participating users’ .Spam folders
7. Quarantine and symbol inspection via Rspamd WebUI + custom tools
8. Currently achieving ~85% spam detection accuracy

---

️ Setup Effort vs. Results​

Initial setup with Rspamd is significantly more involved compared to Plesk Email Security (PES), which offers a quick click-and-go solution.
However, Rspamd provides a highly transparent and modular architecture with fine-grained control over all filtering decisions.

A major advantage:
ClamAV can be integrated easily and at no extra cost, whereas PES requires a paid license for antivirus functionality.

Additional Features in Use or Under Development:​

Local fuzzy hashes for HAM and SPAM​

In addition to global fuzzy feeds, we now generate local fuzzy hash files based on trained mail samples.
This helps detect recurring patterns, especially in region-specific spam or frequent legitimate messages within an organization.

GeoIP-based scoring​

We're currently testing country-specific weighting via GeoIP2, e.g.:

• Stricter scoring for high-risk countries
  Integration is handled through custom rule symbols. Positive scores for trusted regions​

  
  force_actions and symbol weighting for bulk mailers

Services like Sendgrid, Mailchimp, or Amazon SES are treated differently –
with custom SPF/DKIM scoring, forgery detection, and force_action rules where needed.

Goal​

To build a performant, transparent, and maintainable mail filtering solution –
fully integrated into the mail system, but independent of the Plesk GUI.

I'm very interested to hear from others who have taken similar approaches or have insights to share.

 

[Daveo]

@Jürgen_T are you able to post setup instructions on how to do this please.

Willing to try this on my local Plesk server, before deploying it to my live Plesk server.

 

[Jürgen_T]

Hi everyone, @Daveo


as requested, I've documented the full installation process of Rspamd on Plesk, running it in parallel with Amavis/SpamAssassin. The guide includes:

• repository setup (incl. Redis separation and ARM/i386 fix),
• postfix milter configuration without breaking Plesk’s DKIM/DMARC service,
• SURBL tuning with whitelist integration,
• WebUI activation and safe testing without affecting production mail flow.

Full guide is now online here:
Installing Rspamd on Plesk and Running It in Parallel with

⚠️ Things to keep in mind when setting up Rspamd on Plesk:​

1. i386 warning with repository setup
   When adding the Rspamd repository, make sure to omit the [arch=amd64] flag to avoid i386 warnings, especially on ARM-based servers.
2. Rspamd doesn’t replace the existing Plesk Milter!
   Ensure you append Rspamd’s milter to the existing Plesk Milter entry, rather than replacing it. This will prevent breaking DKIM/DMARC signing (Plesk uses port 12768).
3. Redis default database (db=0)
   If using Redis for multiple services (like Nextcloud or Matomo), configure Rspamd to use db = 1 and secure access with a password in the Redis config to avoid data conflicts.
4. Don’t disable Amavis blindly
   Test Rspamd in parallel with Amavis first. Do not remove Amavis from Postfix before verifying that Rspamd is working as expected.
5. WebUI default without password
   By default, Rspamd’s WebUI has no password. Be sure to use rspamadm pw to set a password and avoid exposing the UI without authentication.
6. Centralize whitelists
   To avoid false positives (e.g., legitimate domains marked as spam), create a centralized whitelist file and use force_actions to neutralize SURBL hits from trusted domains.
7. Rspamd does not directly replace SpamAssassin
   Rspamd needs to be actively configured in Postfix (e.g., through smtpd_milters). It won’t automatically replace SpamAssassin without manual configuration.
8. Plesk UI still geared towards Amavis/SpamAssassin
   The Plesk UI continues to show Amavis/SpamAssassin-related settings. Rspamd’s settings must be managed through its own WebUI or configuration files.
9. Postfix master.cf needs to be adjusted for Rspamd’s full functionality
   For Rspamd to function properly, you will need to adjust the master.cf of Postfix to enable the correct processing.
   However, Postfix updates often overwrite main.cf and master.cf, meaning that you'll need a mechanism to track these changes and easily reapply your custom adjustments after an update.
   Consider using a version control system or script to compare and apply necessary changes quickly.

Would be happy to hear your feedback or suggestions – and feel free to extend or adapt the setup for your environment!