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:
Have you fully replaced Amavis + SpamAssassin with Rspamd under Plesk?
Any issues or caveats with Plesk's mail stack or control panel?
How stable is Rspamd in long-term production use with Plesk?
How do you manage spam learning and quarantine outside the PES UI?
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!
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).
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:
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.
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:
Postfix + Dovecot still managed through Plesk
Rspamd with Redis (Bayes, history, learning), ClamAV locally integrated
DKIM and DMARC checks active, initial testing of ARC handling (ARC sealing and verification) is underway
Multimap strategies for SURBL, ASN scoring, GeoIP, and custom sender lists (IP, domain, email)
Central whitelist/blacklist file applied to SPF/DKIM/DMARC/SURBL modules
IMAP-based spam/ham learning via cron scripts from participating users’ .Spam folders
Quarantine and symbol inspection via Rspamd WebUI + custom tools
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.
⚠️ Things to keep in mind when setting up Rspamd on Plesk:
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.
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).
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.
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.
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.
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.
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.
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.
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!
as a quick update regarding the “next steps” after parallel operation and testing: We’ve now fully migrated to Rspamd in production and have completely removed Amavis and SpamAssassin from our mail stack.
The current mail filtering setup now includes:
Rspamd 3.12 natively installed (not in Docker), running as the only filter engine after Postfix receives mail
Redis for:
separate databases (Bayes, fuzzy, greylisting, history)
mailbox statistics and efficient caching
ClamAV (locally integrated, without extra licensing costs)
Full DKIM, DMARC, ARC validation and signing
Custom Multimap rules for:
SURBL/URIBL integration
GeoIP-based scoring (GeoBlocking for high-risk countries introduced today)
Force-actions and custom symbol weighting (especially for bulk mailers and “problematic” sender domains)
Bayes and fuzzy learning (Spam/Ham) via automated IMAP scripts and periodic cronjobs
Rspamd WebUI for symbol inspection, learning feedback, and rapid troubleshooting
Automated whitelist updates (managed via GitHub/Gist and regular cron sync)
Note:
It's worth mentioning that several major server providers (including some well-known German and European hosters) now offer Rspamd as a selectable email filter in their management panels. This can significantly simplify initial deployment.
Why did we fully switch?
Postfix now sends all mail directly through Rspamd.
No more double scanning, and much faster mail delivery.
Since moving to this setup, we consistently detect and reject over 95% of incoming spam/phishing mails at the SMTP level (before they even reach the user’s mailbox).
The few borderline cases that do get through are easily re-trained or handled via symbol tweaking and force-action rules.
Challenges and learnings:
Rspamd offers an extensive range of configuration options.
The out-of-the-box configuration is already effective,
but fine-tuning and achieving maximum accuracy with low false positives takes substantial time and ongoing learning.
It's absolutely essential to monitor the Rspamd WebUI "History" (symbol and action logs) regularly in the early phase, as some tuning is always required for local specifics and new spam waves.
Only with continuous adjustment and reviewing did we reach our current excellent filtering level.
Today we introduced GeoBlocking for high-risk countries using GeoIP-based rules—this adds an extra layer of defense against international spam and phishing.
For next week, we plan to enable the Neural Network module in Rspamd to further enhance recognition of subtle spam patterns with AI-based scoring.
Key results so far:
System performance and transparency have improved significantly.
Quarantine and spam learning are now much easier to manage (and can be automated further).
Updates, custom rules, and symbol weighting are all far more transparent and maintainable than with Amavis/PES.
Warning:
While Rspamd offers superior spam detection and performance in my experience, it only reaches its full potential after careful fine-tuning and constant supervision—especially at the beginning.
Admins should be prepared to spend extra time reviewing logs and the WebUI to ensure optimal results and avoid missing important legitimate mails.
Happy to answer any technical questions or go into detail about any part of the setup!
Facebook
Twitter
