1. Runtime Architecture: Async C/Lua vs Preforked Perl

The core architectural divide between Rspamd and SpamAssassin is their underlying language runtime and concurrency model:

SpamAssassin: Written in Perl, SpamAssassin operates via the spamd daemon or through milters like amavisd-new. It relies on a preforked process model where each incoming email allocates or locks an entire Perl interpreter process. Each worker compiles regex rules, evaluates body parts sequentially, and queries external DNSBLs synchronously or semi-asynchronously. This introduces high CPU context switching and limits horizontal scaling on multicore systems.

Rspamd: Written in C99, Rspamd employs an asynchronous event-driven architecture powered by libevent and LuaJIT. A single master process controls a pool of lightweight non-blocking worker processes. Network I/O, DNS queries, and Redis lookups are completely asynchronous; a single worker process can handle thousands of concurrent SMTP connection streams without spawning additional operating system threads or processes.

-- Rspamd: High-speed asynchronous Lua rule with Redis check
rspamd_config:register_symbol({
  name = 'CORP_URIBL_CHECK',
  score = 4.5,
  callback = function(task)
    local urls = task:get_urls()
    for _, url in ipairs(urls) do
      if url:get_tld() == 'suspicious.top' then
        return true
      end
    end
    return false
  end
})

# SpamAssassin: Traditional regex rule in local.cf
body     LOCAL_SUSPICIOUS_TLD  /https?:\/\/[^\/]+\.suspicious\.top/i
score    LOCAL_SUSPICIOUS_TLD  4.5
describe LOCAL_SUSPICIOUS_TLD  Detects suspicious top-level domains

2. Throughput, Concurrency & Memory Footprint

Under burst conditions (such as handling a flash inbound marketing campaign or sudden dictionary attack), SpamAssassin’s memory consumption escalates rapidly. Running 50 concurrent spamd child processes easily consumes 4 GB to 6 GB of RAM, with CPU utilization hitting 100% on regex backtracking.

Rspamd processes the same volume utilizing under 150 MB of total RAM. Benchmarks across bare-metal NVMe clusters demonstrate Rspamd sustaining over 8,000 to 12,000 messages per second on an 8-core server, whereas an optimized SpamAssassin cluster tops out between 250 and 400 messages per second on identical hardware.

3. Redis Integration, Fuzzy Hashing & Neural Modules

Rspamd treats Redis as a first-class citizen. It utilizes Redis for:

• Fuzzy Hashing: Instant detection of polymorphic bulk spam by hashing image and text structures rather than exact byte matches.
• Dynamic Rate Limiting: Enforcing outbound and inbound per-domain, per-IP, and per-user recipient limits in real time.
• Bayes Classification: Sub-millisecond token storage and retrieval across distributed cluster nodes.
• Deep Neural Networks: The built-in neural module trains perceptrons on historical spam/ham scores, continuously refining classification accuracy without manual rule tweaking.

4. Cryptographic Auth: Native DKIM/ARC vs External Milters

In a traditional Postfix + SpamAssassin stack, implementing modern email authentication requires chaining multiple separate milters: OpenDKIM for DKIM signing/verification, OpenDMARC for DMARC enforcement, and OpenARC for Authenticated Received Chain validation. Each milter adds a TCP/Unix socket hop, increasing latency and failure surface.

Rspamd incorporates native, optimized C modules for DKIM signing, DKIM verification, ARC validation, and strict DMARC reporting. A single milter socket connection between Postfix/KumoMTA and Rspamd handles content inspection, antispam scoring, dynamic cryptographic signing, and reputation logging in a single pass.

5. Rspamd vs SpamAssassin Technical Matrix