SpamAssassin vs Rspamd — choosing your spam filter

The two real choices for spam filtering on a self-hosted mail server are SpamAssassin (the 25-year-old default that ships with most mail packages) and Rspamd (the modern challenger that's faster, more accurate, and easier to integrate). This article compares them and gives practical setup for whichever you pick.

The short version

• SpamAssassin: ubiquitous, well-documented, slow (perl rule engine), older detection capability. Use it if you're maintaining an existing setup or if your distro's mail stack assumes it.
• Rspamd: faster (C-based), better accuracy out of the box, native integration with Postfix, web UI for tuning. Use it for new mail server setups.

For a new install, Rspamd. For inheriting a SpamAssassin-based setup, don't necessarily migrate — it works fine; the migration is more work than the marginal accuracy gain.

Why Rspamd is faster and more accurate

• Written in C with Lua scripting for rules; SpamAssassin is Perl. Single-message check: SA ~1-2 seconds, Rspamd ~50ms.
• Built-in Bayesian classifier with per-user / per-domain stats, no separate sa-learn step.
• Native fuzzy hashing for catching modified spam variants.
• Modern reputation services (DNSBLs, URIBLs, custom hash databases) baked in.
• Active development; SpamAssassin's release cadence is slow and rule updates lag.

Rspamd setup with Postfix + Dovecot

# Debian / Ubuntu
apt install rspamd redis-server
# AlmaLinux (EPEL)
dnf install rspamd redis

Rspamd uses Redis for Bayesian and statistics storage. Default Redis on localhost is fine.

Configure Postfix to send incoming mail through Rspamd via milter:

# /etc/postfix/main.cf
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_rcpt_macros = i {rcpt_addr}

systemctl restart postfix
systemctl enable --now rspamd

Web UI at http://<your-vps>:11334/ (set a password in /etc/rspamd/local.d/worker-controller.inc first — don't expose the UI publicly without authentication).

Bayesian training

Rspamd auto-trains as users move mail to/from spam folders (via Dovecot's "antispam plugin" or via IMAP MOVE/COPY hooks). To prime the classifier with a known corpus:

# Train spam
rspamc learn_spam /var/mail/myuser/.Junk/cur/*

# Train ham
rspamc learn_ham /var/mail/myuser/cur/*

After a few hundred messages of each, Bayesian accuracy is usable. Active training (user moves a spam message into the spam folder) keeps it tuned.

Tuning thresholds

By default, Rspamd applies these actions based on score:

• Score > 15: reject at SMTP (sender gets a bounce).
• Score 7-15: add header, deliver to spam folder.
• Score < 7: deliver normally.

Edit /etc/rspamd/local.d/actions.conf to adjust:

reject = 12;
add_header = 6;
greylist = 4;

Conservative tuning advice: start with defaults, watch a few hundred messages, then nudge. Aggressive rejection thresholds catch the most spam but also false-positive legitimate mail from misconfigured senders.

SpamAssassin setup (if you inherit one)

Standard pipeline is Postfix → spamass-milter → SpamAssassin → Postfix → Dovecot:

apt install spamassassin spamass-milter

# Enable the daemon
systemctl enable --now spamd
systemctl enable --now spamass-milter

Postfix integration via milter (same as Rspamd):

# /etc/postfix/main.cf
smtpd_milters = unix:/var/spool/postfix/spamass/spamass.sock
milter_default_action = accept

Training is via sa-learn:

sa-learn --spam /var/mail/myuser/.Junk/cur/*
sa-learn --ham  /var/mail/myuser/cur/*

Less integration polish than Rspamd; if you're considering switching, the migration is mostly about retraining Bayesian (Rspamd can import SA training corpora, but it's easier to just retrain from your current spam folder).

The DNSBL question

Both filters use DNS-based blocklists (DNSBLs) — Spamhaus ZEN, Barracuda BRBL, SpamCop. These are very effective for the volumetric stuff. Default configs query several DNSBLs in parallel. Two caveats:

• Free/public DNSBLs have query-volume limits. For high-volume servers you may need to mirror them locally (rsync from Spamhaus) or pay for query access.
• DNSBL results sometimes change. A sender that was on a list yesterday isn't today; the spam folder slowly clears as the score shifts.

Greylisting — should you bother

Greylisting temporarily rejects unknown sender/recipient pairs with a 4xx code; legitimate senders retry and pass, spammers usually don't. Effective historically (~80% spam reduction in the early 2000s), less so now (spammers retry too).

Rspamd's greylist module is on by default; SpamAssassin needs postgrey as a separate package. See the dedicated greylisting article in this category for when it's worth enabling.

What spam filtering doesn't help with

SPF/DKIM/DMARC failures by your OWN domain (sender misconfiguration) — see the related articles on each. A filter inbound on YOUR server catches spam FROM others; configuring outbound correctly is a separate job that affects whether YOUR mail lands in others' inboxes.