Rspamd Instead of SpamAssassin: A Meaningful Comparison of Modern Spam Filters

Spam Filter Targets and Unavoidable False Positives

An email spam filter evaluates messages in the email flow based on technical and content-related characteristics. Depending on the product, these may include sender and authentication data, headers, URLs, message text, HTML structure, statistical classifications, and external queries. The goal is not to determine the veracity of an email, but to assess the delivery risk in a transparent manner. Rspamd It also combines numerous test modules for this purpose and can compile the results into a decision-making document.

Several steps must remain separate in this process: The MTA first accepts an SMTP message or rejects it during transmission. The filter then calculates a score, either afterward or during processing. A flag may, for example, be added to the header or, based on downstream rules, move the message to a junk folder. A rejection, on the other hand, terminates the acceptance process; it is therefore the most far-reaching action and not merely a stronger form of flagging.

A False Positive This occurs when a legitimate message is incorrectly classified as spam. This can happen, for example, with a genuine invoice from a supplier whose PDF attachment, payment request, or unfamiliar sender domain triggers multiple checks. If the message is merely flagged, the recipient can still find it; if it is rejected, it never reaches the inbox at all. For business communication, this difference is crucial.

Conversely, a False Negative A spam message that gets past the filter. A typical example would be a campaign with slightly altered text, varying links, and headers that appear technically correct. Such messages increase the risk of phishing, malware, or unsolicited advertising, but this does not automatically mean that a strict rejection is warranted. An email spam filter always strikes a balance between these two types of errors; it does not aim for a zero-error rate.

Threshold values are therefore an operational risk decision. A low rejection threshold may reduce the amount of spam that gets through, but it increases the risk of losing legitimate mail. A higher threshold shifts more responsibility to flagging, quarantining, and user review. A tiered strategy makes sense: first, flagging and monitoring; then, greylisting or stricter measures only where logs, feedback, and the organization’s own email traffic support the decision.

SpamAssassin: Rules, Scores, and Operating Model

SpamAssassin is an extensible, rule- and point-based filter. Among other things, it analyzes headers, body text, HTML, and URLs; in addition, statistical methods, network queries, and plugins are available for functions such as Bayes, SPF, DKIM, or DMARC. Individual matches contribute points to the result. The total of these points yields a score that can be compared to a configured threshold.

Customizations are typically made in .cf-files. These allow you to define header, body, and URI rules with their own scores. This model is particularly transparent when a team needs to understand why a specific rule was triggered. At the same time, the maintenance effort increases with many exceptions, local rule sets, and varying evaluations: Each rule requires a business justification, a documented impact, and regular monitoring.

In continuous server operation, the service typically spamd accepts audit requests, while the lightweight client spamc delivers messages to him. This separation eliminates the need to launch the entire program for each message and is intended for recurring checks. The service can also incorporate SQL or LDAP configurations as well as user-specific settings.

This is relevant for hosting environments: A domain may require different whitelists, while individual mailboxes may have their own preferences or learning histories. Such organically developed structures are not a technical flaw, but they complicate migration. Before making a change, it should therefore be clear which rules are actually business-critical, which were simply carried over from the past, and which tasks are already handled by the MTA or another service.

A well-maintained SpamAssassin installation does not need to be replaced simply because of its age. If the rules are understandable, the integration works reliably, and the administrative effort is commensurate with the volume of email, targeted maintenance may make more sense than a migration. Conversely, a high proportion of special rules that are difficult to maintain is not a reason to blindly copy them: it is a reason to Standard inventory to perform a critical adjustment, regardless of which filter is selected later.

Rspamd: Workers, Icons, and Actions

Rspamd uses a master-worker model. The master manages processes and configuration, while regular workers process messages. Among other things, a proxy worker can receive Milter requests and distribute them to scanners. The controller provides administrative functions and a web interface, but should not be exposed unprotected to the public network. These roles more clearly separate mail traffic, processing, and administration from one another.

Non-blocking input and output are important for the architecture. DNS, Redis, or HTTP queries can be performed asynchronously. If a check is waiting for an external response, this does not necessarily have to halt other scans by the same worker. This does not imply a general performance guarantee: Actual results still depend on the rule set, hardware, DNS latencies, Redis, MTA connectivity, and the actual message mix.

Generating tests in Rspamd Symbols with ratings and additional information. The filter aggregates them into an overall score and can suggest an action, such as add header, greylist or reject. This action does not automatically result in a delivery decision: Only the configuration and specific integration into Postfix, Exim, or Sendmail determine whether and how the MTA enforces it.

That is precisely why existing SpamAssassin thresholds should not be adopted as numerical values. A score reflects the interaction of the activated rules, their weighting, and the available data sources. Even checks with the same name may be weighted differently, aggregated differently, or executed at different times in the two systems. A direct comparison of required_score Using an Rspamd threshold would be technically misleading.

From an operational standpoint, separating evaluation from enforcement is an advantage: You can first observe the use of symbols and suggested actions without immediately rejecting them. Only by analyzing your own legitimate messages, identified campaigns, and feedback can you determine which Action Thresholds are reasonable. This turns a technical default setting into a verifiable delivery policy rather than a supposedly objective spam threshold.

Comparison for Daily Email Operations

The differences between SpamAssassin and Rspamd lie less in individual detection rules than in their operational models. Both evaluate emails based on numerous signals, but their approaches to configuration, integration, and distributed operation differ. The following comparison organizes these points as a basis for planning; it is not a substitute for an analysis of your own email traffic.

For a small standalone server, a well-maintained SpamAssassin installation is therefore not a technical emergency. If your own rules are transparent, the service runs stably, and misclassifications are addressed, keeping it in place may mean less effort to make changes. Nevertheless, a fresh installation using Rspamd remains a viable option if its Milter integration and centrally consolidated modules are a better fit for the planned environment.

In hosting environments with multiple scanners, the Scaling more important than the mere number of installed rules. Rspamd’s proxy worker can forward Milter requests to other workers; asynchronous external queries should not block the entire worker in the process. However, this does not imply a general performance guarantee: DNS latencies, rules, hardware, and the message mix determine the actual throughput.

MTA Integration, Redis, and State-Based Modules

The technical integration determines where a email spam filter returns its evaluation to the mail transfer agent. Rspamd can be connected to Postfix and Sendmail via Milter. Exim uses its integration via spamd_address. The filter returns a result, but the MTA and the selected configuration still determine whether a message is flagged, delayed, or rejected.

Not every check requires a shared state. SPF, DKIM, and DMARC evaluate authentication information; DNS-based lists and regular expressions check additional characteristics of an individual message. Although such checks may require external DNS responses, they do not automatically maintain a learning history. Their validity depends, among other things, on proper DNS operation and appropriate weighting within the overall rule set.

Working Differently state-based modules. Bayesian classification stores learned features, greylisting must recognize previous delivery attempts, and rate limits require counters that span multiple connections. Rspamd incorporates Redis into its documented architecture for Bayesian, neural network, and greylisting classification, as well as other states. This allows multiple instances to access shared information.

Redis is therefore neither an interchangeable component nor a prerequisite for every single Rspamd check. Without accessible storage, static modules may still be usable, while learning and reputation functions may be limited or fail. Operators must therefore define availability, network connectivity, access protection, backup procedures, and the response to a Redis failure before going live.

From a practical standpoint, separating responsibilities makes sense: The MTA accepts SMTP connections and enforces the filtering decision, Rspamd evaluates messages, and Redis maintains the necessary state. This division simplifies troubleshooting but increases the number of services that need to be monitored. A slow or unreachable dependency should not be compensated for by ill-considered rejections.

Transfer Rules and Learning Data in a Controlled Manner

A migration begins with an assessment, not by copying all files. Custom rules, in particular, deserve careful review: They may reflect business requirements, but they may also contain outdated exceptions. Rspamd provides a SpamAssassin module that processes only a subset of rules. Therefore, the technical similarity of a rule does not guarantee that it will have the same effect.

Among other things, the module can body-, rawbody-, header-, meta- and uri-Process rules. Network- and HTML-specific plugins, on the other hand, are not fully supported. Loading extensive third-party rule sets without verification can complicate the configuration and put a strain on processing. It is better to adopt only your own rules that are demonstrably needed and to give preference to native modules.

This requires special care Bayesian Training. According to the Rspamd documentation, SpamAssassin Bayesian databases cannot be imported. Rspamd therefore requires new, verified corpora consisting of legitimate messages and spam. Incorrectly classified invoices, newsletters, or marketing campaigns skew the classification in the wrong direction and can exacerbate future misclassifications.

AWL should also not be treated as a file-based rule. While a sender’s past history and a current reputation score pursue related goals, they may use different data sources and weightings. Therefore, first document the intended effect of an existing exception or trust rule. Only then can you decide whether a native Rspamd function or a custom rule tailored to your needs is appropriate.

Safely Implement Rspamd in a Parallel Environment

A productive migration doesn't start by replacing the existing filter, but by taking stock of the current situation. Document the MTA connection, SpamAssassin rules, user-specific exceptions, DNS dependencies, accepted senders, and the current handling of suspicious messages. Also, determine which metrics will be important later on: for example, business emails falsely flagged as spam, campaigns that slipped through, and the manual processing effort required.

First, install Rspamd separately from the main mail path and configure it so that its evaluation is logged but does not alter delivery. The documented “Shadow Mode” allows for exactly this kind of observation: Rspamd checks messages without enforcing its suggested actions. This ensures that SpamAssassin remains the sole active decision-maker during the comparison phase.

Don't just evaluate the total score, but above all the triggered Symbols and the resulting action. A high score may result from authentication errors, URL characteristics, reputation data, or local rules; these causes require different corrective actions. Therefore, for each suspicious message, check the header, recipient group, and the action suggested by the filter before changing scores or modules.

A meaningful comparison includes specific examples of both desired and undesired edge cases. For example, a legitimate invoice from a known supplier might contain a PDF file and an external tracking link. A varied spam campaign, on the other hand, constantly changes the subject line, text blocks, and sender, but retains typical URLs or structural characteristics. Both types of messages reveal whether individual characters contribute in a meaningful way or whether a rule is too broad.

Yoke Threshold values Only enable this once there are sufficient verifiable examples. Rspamd’s score scale is not equivalent to any previous SpamAssassin score; therefore, directly adopting it may trigger inappropriate actions. Decide separately when to simply add headers, when to temporarily greylist, and under what conditions to reject messages. The MTA integration determines whether and how an action is actually enforced.

After a planned observation period, the switchover takes place in a controlled manner: Rspamd becomes the active filter, while SpamAssassin remains installed and configurable but no longer makes decisions in the mail flow. This fallback period should include defined responsibilities, a documented method for reverting to the previous configuration, and criteria for terminating the process. In addition, a clearly defined firewall configuration is helpful; the article explains the basics of a phased migration. Netfilter vs. nftables.

Operation, Logging, and Systematic Troubleshooting

In the event of an unexpected rejection, the diagnosis begins with the specific message and its processing chain, not with a blanket relaxation of the filter threshold. Check the MTA log, the Rspamd result, the triggered flags, the score, and the suggested action. Only this analysis will reveal whether, for example, a local rule, a DNS-based check, or MTA enforcement caused the rejection.

Spam that slipped through requires a reverse analysis. Determine whether the message reached Rspamd at all, which symbols are missing, and whether a configured action was not triggered due to the score. If expected DNS results are missing, investigate the resolver, reachability, and response times before writing new content rules. Not every campaign can be effectively captured by a single threshold.

A Redis outage must be handled separately because it can affect state-based functions. Check the filter’s connection to the storage, the Redis service logs, and then determine which modules depend on this state. Static checks can still provide results, but Bayesian training, greylisting, or other state-dependent evaluations require a functioning data store.

If an expected rule does not trigger, first check its actual loading location, syntax, and the message format it is supposed to process. Header, plaintext, HTML, and URL checks examine different types of data. In SpamAssassin, rule files can be checked with a syntax check before deployment; the following command checks the configuration and does not affect production mail delivery.

spamassassin --lint

For recurring issues, keep track of timestamps, queue behavior, DNS queries, and response errors in a single view. This allows you to determine whether a delayed delivery is caused by the MTA, an external query, or the filtering process. For more in-depth Linux telemetry and monitoring of running systems, see the supplementary article bpftool for modern kernel analysis Technical Fundamentals.

Do not reflexively change global scores or extensive rule sets after a single incident. Instead, secure the relevant message in accordance with data protection regulations, compare it with similar cases, and document the cause along with the change. This Error analysis ensures transparent corrections and reduces the risk that an exception rule will later incorrectly handle large volumes of legitimate or unwanted emails.

Make a decision based on the server profile

It makes sense to continue running SpamAssassin specifically if the existing mail server is reliably managed with its own rules, per-user settings, and operational workflows. The system can be expanded based on rules and points and supports plugins as well as various configuration and storage methods. Switching simply because an installation is old offers no technical benefit if there is no specific operational problem.

Rspamd is an obvious choice for a new build if Milter integration, modern authentication checks, centralized control, and stateful modules are planned together from the start. Its architecture includes worker roles for processing, proxy connections, and administration; at the same time, DNS and, if applicable, Redis must be operated reliably as operational dependencies. This is an architectural decision, not a general performance guarantee.

For established hosting environments with many special cases, the Parallel operation usually the most robust option. It reveals which of your own SpamAssassin rules are still needed, whether Rspamd symbols accurately reflect the expected causes, and which recipient groups are particularly sensitive to misclassifications. Only on this basis can a decision be made regarding a complete transition or a deliberate decision to stick with the existing setup.

The choice therefore depends less on the number of mailboxes alone than on maintenance capacity and dependencies. Those who can consistently manage Redis, DNS resolvers, log analysis, and updates can run Rspamd—including its learning and state-based features—consistently. If these resources are lacking, a lean, well-documented setup with clear rules may pose the lower operational risk.

Regardless of the product, do not deploy the Rspamd controller on the network without protection. The documentation recommends local binding or firewall protection; for remote access, access protection and a password hash are required. Furthermore, do not adopt third-party rules or historical scores without verifying them. Individual measurements or conspicuous campaigns do not constitute a basis for a global filtering policy.

The right decision, therefore, is a Risk Assessment: Protection against unwanted messages must be balanced against the consequences of losing legitimate emails. For each action, define who is responsible for it, how it is reviewed, and how to revert to the previous state. This ensures that the email spam filter remains a manageable part of email operations rather than an automated system that is difficult to understand.