An email filter should spend its time judging messages, not falling over while reading them. Rspamd’s latest patch is a reminder that the machinery around spam scoring deserves attention too.
The official release index dates Rspamd 4.2.1 to October 1, 2026. That makes it fresh news for this week’s maintenance list. Our earlier article covered 4.1.0; this update has a different practical angle: check the filter’s health and configuration, rather than reaching immediately for more permissive spam thresholds.
What changed, without the alarm bells
The 4.2.1 release notes describe fixes for heap overflow and use-after-free defects in HTTP handling, plus hardening of fuzzy storage. They also report repaired HTTP map handling and IPv6 RBL allowlists. The project recommends upgrading, especially where untrusted clients can reach fuzzy storage.
That is enough reason to assess your installation. This article does not assign a CVE number, claim active exploitation, or declare every deployment remotely exploitable. Those details are not established by the release notice. Keep confirmed defects and your server’s actual exposure as separate questions.
When a working filter has missing instructions
A particularly useful upstream map bug report describes large HTTP maps delivered using chunked transfer encoding picking up trailing data. The reporter observed parsing failures that affected per-user settings, with broken cached data surviving restarts.
For administrators, my recommendation is to check more than whether the process is running. Make an inventory of the maps your installation depends on, then confirm they load and that a representative rule actually applies. Include the business-specific exceptions that nobody remembers until a customer calls.
Avoid deleting every cache as a first response. Record the error, identify the affected map, and establish a targeted recovery procedure with whoever maintains the installation. An unexplained reset may remove the symptom while also removing the evidence you needed to understand it.
IPv6 deserves a real test
The IPv6 allowlist report documents an RBL allowlist result being logged without preventing subsequent blacklist checks. Its example involved a custom Abusix configuration and mail arriving from Gmail over IPv6. That example is not proof that every Gmail delivery was mishandled.
If your installation uses this kind of rule, I recommend a controlled comparison of legitimate messages arriving over IPv4 and IPv6. Examine the symbols and final action rather than relying on the sender’s reputation alone. Do not globally allowlist a large provider to make one complaint disappear; find which local policy produced the decision.
A maintenance plan you can repeat
Start with the installed package version and the package maintainer’s advice. If your distribution supplies backported fixes, ask which package contains them. Do not assume that switching repositories or installing upstream code is the right upgrade path for a managed mail platform.
My suggested preparation is simple: save the relevant configuration, record the current package, agree on a maintenance window, and have a recovery plan. Keep a small set of legitimate test messages that reflect real workflows, including an invoice, a contact-form notification, and a message from a regular correspondent. Handle those samples as private business data.
Rspamd’s quick-start documentation provides these checks:
sudo rspamadm configtest
sudo systemctl status rspamd
rspamc message.eml
The service check assumes a systemd installation. A local scan of a saved message checks scanning; it does not by itself prove live mail delivery or reproduce the original SMTP context. After the upgrade, also send controlled messages through the actual mail path and confirm arrival, filtering decisions, and relevant logs.
Write down the outcome, including any failures left unresolved. Resist changing thresholds at the same time unless the evidence calls for it: otherwise you will struggle to tell whether the update or the policy adjustment changed the result.
What this means for kalfaoglu.net customers
If your service uses Rspamd, ask the administrator whether the applicable fixes are installed and whether filtering was checked afterward. This article does not claim that any particular Kalfaoglu server has already been updated.
For a wrongly filtered message, supply the approximate time, sender, recipient, and message identifier through your normal support channel. Avoid sending passwords or unrelated mailbox contents. A precise example gives the administrator something to investigate; “email is strange today” mostly gives everyone a longer afternoon.