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!

 

[Daveo]

Thanks for that @Jürgen_T.

Will give that a go on my local test server.

When will you be posting the next steps (shown at bottom of current guide) ?

 

[Jürgen_T]

Hi @Daveo , hi all,


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)
  • ASN scoring
  • Sender-based whitelists/blacklists (all managed centrally)
• 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!


Best regards,
Jürgen

 

[Daveo]

OK. I'm running it successfully in parallel on local test server.

Unable to do the next steps to migrate fully over to Rspamd, as unsure how to proceed.

Awaiting a follow up "Next Steps" guide please.

 

[Jürgen_T]

Disable Amavis / SpamAssassin​

• Fully uninstall “Plesk Email Security” from the Plesk UI
• In master.cf: make sure no Amavis pipes are left
• Restart postfix and rspamd to avoid conflicts

---

️ 2. Enable Rspamd Milter in Postfix​

Open your main.cf file:
sudo nano /etc/postfix/main.cf


Add the following lines:

# Enable Rspamd Milter
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_default_action = accept

Then restart Postfix:

sudo systemctl restart postfix

This enables Rspamd to filter all inbound (and optionally outbound) mail via milter.

---

3. Enable Redis-based configuration​

Use dedicated Redis databases:

• Bayes filter (e.g. DB 6 for HAM, DB 7 for SPAM)
• Fuzzy hashing (e.g. DB 3)
• Greylisting (e.g. DB 5)

Adjust config files like:
classifier-bayes.conf
worker-fuzzy.inc

• greylist.conf

---

4. Automate Bayes & Fuzzy training​

• Create a cronjob for training
• Define training folders (e.g. .spam_learned/)
• Make sure Bayes hits min_learns threshold

---

5. Consolidate whitelist management​

• Use centralized maps for domains, IPs, emails: /etc/rspamd/maps.d/
• Include them in modules like multimap.conf, spf.conf, surbl.conf using .include(...)

---

6. Enable GeoIP-based filtering​

• Add greylisting for high-risk countries
• Use geoip = true in multimap
• Set correct GeoLite DB path in geoip.conf