Artica embeds a full management layer for Rspamd, the high-performance spam filtering engine, directly wired into your SMTP service.
Rspamd inspects every message before it enters the queue (milter protocol), scores it against hundreds of rules, and applies the action you configured:accept, tag, greylist, quarantine or reject.
Everything is driven from the Web console page Rspamd anti-spam, per Postfix instance — no manual editing of /etc/rspamd files is required. Artica renders the whole Rspamd configuration, wires the milter into Postfix and supervises the daemon for you.
¶ Benefits
- Before-queue filtering
Spam is scored during the SMTP transaction.
Rejected messages never enter your queue: no bounce-back scatter, no wasted disk and CPU on junk.
- Graduated response instead of all-or-nothing
Four independent score thresholds (greylist, add header, rewrite subject, reject) let you tag doubtful messages while rejecting only obvious spam.
- Zero-file administration
Artica renderslocal.d/configuration, the Postfix milter wiring and the systemd/monit supervision.
One Apply / rebuild button regenerates and reloads everything consistently.
- Multi-tenant ready
Every Postfix instance (primary +postmultitenants) gets its own Rspamd settings, its own scores and its own milter wiring.
Configuration can be cloned from the primary instance in one click.
- Dedicated Valkey backend
Bayes statistics, greylisting state and fuzzy hashes are stored in a Valkey (Redis-compatible) instance dedicated to Rspamd:
the global Artica Valkey is never reused, so anti-spam load can never disturb other Artica components.
- Bayesian learning built-in
Feed spam/ham samples from the Web console (paste a raw message) or let autolearn thresholds train the filter automatically.
Learning jobs are queued, tracked and retryable.
- Self-healing supervision
A watchdog reconciles the desired state with the running state:
if Rspamd is enabled but down it is restarted automatically; if it is disabled the mail flow is rewired first so mail never stalls on a dead milter.
- Fail-safe by design
The milter default action (what Postfix does if Rspamd is unreachable) is configurable;
the defaultacceptkeeps mail flowing even during an anti-spam outage.
¶ Use cases
- Internet-facing MX:
Reject high-score spam at SMTP time (score ≥ reject threshold), greylist suspicious sources, and keep the queue clean of junk.
- Hosting / multi-tenant relay
Each Postfix instance (tenant) carries its own thresholds and learning mode (shared_global,per_instance,per_domain);
clone the primary instance settings to onboard a new tenant in seconds.
- Corporate gateway with cautious policy:
Keeprejecthigh (or disabled), tag messages with the spam header and a[SPAM]subject prefix, and let the downstream groupware do the foldering.
- Progressive rollout:
Start with milter default actionacceptand header-tagging only; watch the Statistics and Logs tabs; tighten the reject score once you trust the scoring.
- Feedback-driven filtering
Abuse mailbox operators paste missed spam (or false positives) into the Learning tab; the Bayes classifier improves with your real traffic.
¶ How it works
- Postfix passes each incoming message to the rspamd proxy worker through a milter socket (Unix socket
/run/rspamd/rspamd-milter.sockby default — recommended over TCP). - Rspamd computes a score from its symbol rules (SPF, DKIM, DMARC, RBLs, Bayes, fuzzy hashes, regexp rules…).
- The score is compared to your action thresholds (see Actions & scores below) and the resulting action is returned to Postfix during the SMTP transaction.
- Bayes/greylist/fuzzy state is persisted in the dedicated Valkey instance.
- Artica collects hourly counters and top symbols so the Statistics tab can show what actually happens to your traffic.
¶ The Overview tab
The Overview tab is the health cockpit of the integration:
- Status widget — enable or disable the Rspamd integration for the selected Postfix instance. Disabling rewires Postfix first, so mail keeps flowing.
- Status grid — Rspamd installed / version, the Rspamd service state, the dedicated Valkey state and the current milter socket.
- Test configuration — validates the rendered Rspamd configuration before it goes live.
- Apply / rebuild — regenerates every configuration file, rewires the Postfix milter map and reloads the services.
¶ The Instances tab
One row per Postfix instance (the primary instance 0 plus every postmulti tenant), showing its enable state, milter socket and learning mode. Per-row actions:
- Edit — jump to the settings of that instance.
- Enable / Disable — toggle Rspamd filtering for that instance only.
- Apply — re-render and reload that instance's configuration.
- Clone from instance 0 — copy the primary instance's whole Rspamd configuration onto a tenant.
The header button Apply all enabled instances re-applies every enabled instance in one pass — use it after a change that affects all tenants.
¶ The Instance tab (per-instance settings)
- Milter transport
unix(recommended: lower latency, no network exposure) ortcp. - Unix socket
Path of the milter socket presented to Postfix. - Milter default action
What Postfix does when Rspamd is unreachable:accept(fail-open, default),reject,tempfailorquarantine. - Milter daemon name
The{daemon_name}milter macro value (defaults to$myhostname). - Learning mode
disabled,shared_global(one Bayes base for the whole server),per_instanceorper_domain.
Every field is edited in place: click the edit icon, change the value, Apply — Artica validates the value daemon-side before saving it.
¶ The Actions & scores tab
The four thresholds form an escalation ladder :
Greylist score
Temporarily defer the message (legitimate MTAs retry)
- Add-header score
Deliver, but add the spam header so the mailbox can file it - Rewrite-subject score
Deliver with the subject rewritten using the Spam subject prefix ([SPAM] %s) - Reject score
Refuse the message during the SMTP transaction
Keep the order greylist < add header < rewrite subject < reject. Lowering the reject score makes the filter more aggressive; raising it favors tagging over rejection.
¶ The Learning tab
Bayesian learning management:
- Learning settings
Enable/disable learning, choose the learning mode, and configure autolearn: messages scoring above the spam threshold (or below the ham threshold) automatically train the classifier. - Manual learning
Paste a raw message (RFC 822 source, with headers) and click Learn as spam or Learn as ham.
This is the fastest way to correct a miss or a false positive. - Jobs history
Every learning request becomes a tracked job with its status; failed jobs can be retried or deleted.
¶ The Valkey tab
Rspamd needs a Redis-compatible store for Bayes, greylisting and fuzzy state.
Artica provisions a dedicated Valkey instance for Rspamd — the global Artica Valkey is never reused. From this tab you can:
- Check the dedicated Valkey state and endpoint;
- Switch between Unix socket (recommended) and TCP;
- Adjust the database number and the key prefix;
- Restart dedicated Valkey after a change.
¶ The Statistics tab
Traffic analytics with a scope selector (all instances, primary, or a single tenant) and a period selector (24 h / 7 days / 30 days):
- counters: scanned, spam, ham, rejected, greylisted;
- top symbols — which Rspamd rules fire the most (a quick way to understand why mail is being scored);
- top sender / recipient domains.
Statistics are collected every 10 minutes by the Artica daemon and stored per hour, so the page stays fast even on busy gateways.
¶ The Advanced tab
- Controller — Rspamd's own web UI and statistics API. Keep it bound to
127.0.0.1unless you really need remote access;
the console warns you (and asks for confirmation) when a non-loopback bind address is entered.
The controller password is stored as a hash only. - Milter protocol — the milter protocol version negotiated with Postfix (default
6). - Inherit defaults from instance 0 — tenants can follow the primary instance's defaults until a value is explicitly overridden.
¶ The Logs tab
A live tail of the Rspamd daemon log (routed by Artica to /var/log/rspamd/artica-rspamd.log). Use it to verify a startup after Apply / rebuild, watch scans in real time, or diagnose a misbehaving rule.
¶ Command-line reference
All console actions are also available from a shell on the Artica server (useful for scripting or when diagnosing over SSH):
| Command | Purpose |
|---|---|
artica-postfix -status-rspamd |
Show the supervised service state. |
artica-postfix -start-rspamd / -stop-rspamd / -restart-rspamd |
Drive the Rspamd service exactly like the supervision does. |
artica-postfix -reconfigure-rspamd 0 |
Re-render and apply the configuration of Postfix instance 0 (same as Apply / rebuild). |
artica-postfix -install-rspamd / -uninstall-rspamd |
Enable / disable the whole integration (same as the Overview toggle). |
rspamadm configtest |
Rspamd's own configuration validation. |
rspamc stat |
Live counters straight from the running Rspamd. |
¶ Troubleshooting
- Overview shows “Rspamd service: Stopped” — open the Logs tab: a configuration error aborts the startup and is logged there. The Artica watchdog re-checks the desired state every few minutes and restarts an enabled-but-down Rspamd automatically.
- Mail still flows while Rspamd is down — that is the milter default action
accept(fail-open) doing its job. Switch it totempfailif you prefer to defer mail rather than skip filtering. - Greylisting or Bayes seems inactive — check the Valkey tab: both features need the dedicated Valkey to be running. Use Restart dedicated Valkey and re-check the endpoint.
- A tenant ignores your changes — settings are per instance: verify you edited the right instance (Instances tab) and clicked Apply for it, or use Apply all enabled instances.
- Too many false positives — raise the add-header/reject scores, learn the misclassified messages as ham in the Learning tab, and watch which symbols drive the score in Statistics → Top symbols.
¶ Good practices
- Prefer Unix sockets for both the milter and Valkey transports: lower latency and zero network exposure.
- Start permissive: keep the milter default action on
acceptand let the filter tag before you let it reject. - Feed the Bayes filter: a few dozen learned spam/ham samples of your traffic dramatically improve accuracy.
- Watch the top symbols after each threshold change — they tell you which rules drive the scores on your real traffic.
- After any settings change, use Test configuration, then Apply / rebuild, and check the Logs tab.