Goal of this guide

This guide builds on the grommunio 2026.06.1 installation and shows step by step how you understand, verify, test, train and operate grommunio-antispam with Rspamd. It is deliberately practical: you get commands, checkpoints, screenshots from a validated grommunio 2026.06.1 installation and guidance on which values you should not copy blindly into production.

  • You identify which Rspamd processes run inside grommunio.

  • You test the mail filter with a safe GTUBE test message.

  • You read score, action, symbols and history correctly.

  • You train spam and ham in a controlled way.

  • You understand which features matter in production: SPF, DKIM, DMARC, RBL/SURBL, fuzzy checks, greylisting, rate limits, neural/Bayes, multimap and monitoring.

The baseline installation is here: install grommunio 2026.06.1.

Validated reference installation

This guide was validated against an isolated grommunio appliance. Hostname, domain and messages are synthetic. The Rspamd web interface was not exposed publicly; it was tested through an SSH tunnel to the local controller port.

bash
hostname -f
cat /etc/os-release | grep -E '^(PRETTY_NAME|VARIANT|ID_LIKE)='
rpm -qa | grep -Ei 'grommunio-antispam|rspamd|postfix|redis' | sort
rspamd --version

The validated reference installation used grommunio 2026.06.1 with grommunio-antispam 4.1.5, Postfix 3.10.2 and Redis 8.2.3. Important: this appliance used XFS for the root filesystem and systemd-networkd for network configuration . That is a validated appliance state, not a general statement about every SUSE or SLES installation.

Architecture: Postfix, Rspamd and Redis

grommunio-antispam is based on Rspamd. Rspamd is a modular mail filter: a message is evaluated by multiple independent checks. Each check produces a symbol and optionally a score. The accumulated score results in an action such as no action, add header, greylist or reject.

  • Postfix receives mail and passes it to Rspamd via milter.

  • The proxy worker listens locally on port 11332.

  • Normal workers scan messages on port 11333.

  • The controller with web UI and API listens locally on port 11334.

  • Redis stores state such as Bayes, history, greylisting, rate limits and other learning data.

bash
ss -ltnp | grep -E ':(25|587|11332|11333|11334)\b'
postconf -n | grep -Ei 'milter|content_filter'
systemctl list-units --type=service --all | grep -Ei 'redis|valkey'

In the validated installation, `smtpd_milters = inet:localhost:11332` was configured. The controller was reachable only on localhost. That is the right production model as well: publish mail services as needed, but keep the antispam controller inside a management network, behind VPN or behind explicit IP rules.

Step 1: Verify services and configuration

Always start with a state check. If services are not running or configuration does not parse, every functional filter analysis is meaningless.

bash
systemctl is-active grommunio-antispam postfix redis@grommunio
rspamadm configtest
rspamc stat
journalctl -u grommunio-antispam --since "30 minutes ago" --no-pager

Expected output is `syntax OK`, an active antispam service and plausible `rspamc stat` output. Evaluate warnings carefully: DNS failures, missing maps or broken local includes are often operational issues, while a fresh installation naturally has little statistical data.

Step 2: Open the web interface safely

An SSH tunnel is enough for administration and screenshots. You do not need to expose port 11334 publicly. This protects the controller API and reduces attack surface.

bash
ssh -L 11334:127.0.0.1:11334 root@mail.example.test


# Danach lokal im Browser öffnen:
# http://127.0.0.1:11334/
127.0.0.1:11334

Screenshot: Dashboard of a grommunio 2026.06.1 installation with grommunio-antispam 4.1.5.

Step 3: Understand actions, scores and symbols

Rspamd does not make a magical yes/no decision. It collects symbols, adds scores and recommends an action. In the validated baseline configuration, the thresholds were greylist 4, add header 6 and reject 15. In production, change these values only after observing real mail flows.

127.0.0.1:11334

Screenshot: Actions and maps in the Rspamd configuration; local overrides should be controlled and documented.

bash
rspamadm configdump actions
rspamadm configdump spf
rspamadm configdump dkim
rspamadm configdump dmarc

Do not edit shipped defaults directly. Add local files in `local.d` and always run `rspamadm configtest` afterwards. In the grommunio appliance, the configuration path is `/etc/grommunio-antispam`; generic Rspamd documentation often uses `/etc/rspamd`.

Step 4: Scan a first message

Create a harmless test message first and scan it with `rspamc symbols`. Do not look only at the action; look at the reasoning: missing Received headers, test domains or DNS issues can cause higher scores in synthetic tests than in a real mail flow.

bash
cat > /tmp/ham.eml <<'EOF'
From: Alex Example <alex@example.test>
To: Admin Example <admin@example.test>
Subject: Lab Termin fuer Mailfilter
Date: Mon, 7 Sep 2026 10:00:00 +0200
Message-ID: <ham-001@example.test>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8


Hallo,


das ist eine harmlose interne Testnachricht fuer die Antispam-Validierung.
EOF


rspamc symbols < /tmp/ham.eml

In the validated test run, this message was classified as `add header` because of synthetic characteristics. This is a useful example: the technology works, but the data basis is not identical to a real production message.

Step 5: Test spam safely with GTUBE

Use GTUBE for reproducible tests. It is a harmless test signature that spam filters are expected to classify as spam. This avoids storing or forwarding real spam.

bash
cat > /tmp/gtube.eml <<'EOF'
From: Sender Example <sender@example.net>
To: Alex Example <alex@example.test>
Subject: GTUBE Lab Test
Date: Mon, 7 Sep 2026 10:05:00 +0200
Message-ID: <spam-gtube-001@example.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8


This is a safe spam-filter test message.
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
EOF


rspamc symbols < /tmp/gtube.eml

The GTUBE test returned `Action: reject`, `Score: 15.00 / 15.00` and the `GTUBE` symbol. This validates the filter path from client to Rspamd action.

127.0.0.1:11334

Screenshot: Scan/Learn with GTUBE: the interface shows reject, score and triggering symbol.

Step 6: Use Bayes learning carefully

Bayes learning is valuable, but only with clean training data. Train clear spam examples as spam and clear false positives as ham. If users report everything without review, you can make filtering worse.

bash
rspamc learn_spam /tmp/gtube.eml
rspamc learn_ham /tmp/ham.eml
rspamc stat

After learning, the dashboard showed a ham learn entry. In production, add a reporting workflow, sample review, backup of state data and regular false-positive checks.

Step 7: Read history and concrete causes

History is the fastest path from a user complaint to the cause. Open the concrete message and check sender, recipient, subject, action, score, scan time and symbols. Only then decide whether DNS, reputation, content, attachment, URL, Bayes or a local rule caused the classification.

127.0.0.1:11334

Screenshot: History after the GTUBE test with action, score, symbols and scan time.

bash
journalctl -u postfix --since "2 hours ago" --no-pager
journalctl -u grommunio-antispam --since "2 hours ago" --no-pager
mailq

Step 8: Use symbols as tuning input

The symbols view shows which checks exist and how they are scored. This is a better starting point than blindly raising thresholds. If a symbol repeatedly produces wrong results, first check DNS, local maps, authentication and real examples.

127.0.0.1:11334

Screenshot: Symbols show which individual checks Rspamd includes in the overall score.

Step 9: Plan allowlists, denylists and multimap cleanly

Exceptions are useful, but dangerous when too broad. Use specific senders, partner domains or technical relay IP addresses. Do not globally allow large freemail or cloud domains.

bash
cat > /etc/grommunio-antispam/local.d/multimap.conf <<'EOF'
TRUSTED_SENDER_DOMAIN {
  type = "from";
  filter = "email:domain";
  map = "/etc/grommunio-antispam/local.d/trusted_sender_domain.map";
  score = -5.0;
  description = "Trusted sender domains reviewed by mail operations";
}
EOF


printf '%s\n' 'partner.example' > /etc/grommunio-antispam/local.d/trusted_sender_domain.map
rspamadm configtest
systemctl reload grommunio-antispam

Production changes need a review process: who may add exceptions, how long do they last, which samples justify the exception and when is it reviewed again?

Step 10: Understand test selectors

Selectors extract fields from messages. They help you verify whether a rule sees the value you expect: SMTP sender, recipient, headers, subject, IP, MIME structure or URL components.

127.0.0.1:11334

Screenshot: Test selectors with a synthetic message; useful before adding custom rules and maps.

Important feature areas in grommunio-antispam

  • SPF, DKIM, DMARC and ARC validate identity and authenticity of mail flows.

  • RBL and SURBL evaluate IPs, domains and URLs through reputation data.

  • Fuzzy checks detect known or similar spam content.

  • Bayes and neural improve classification through training and learning models.

  • Greylisting and rate limits slow suspicious delivery patterns.

  • Multimap, force actions and local maps implement controlled exceptions and rules.

  • Milter headers can make results visible in message headers.

  • External services and antivirus integration are extension points, but they need deliberate planning and monitoring.

127.0.0.1:11334

Screenshot: Throughput and actions support operations, especially after policy or DNS changes.

Place SPF, DKIM, DMARC and ARC correctly

These checks are not cosmetic extras; they are the trust chain of your mail domains. SPF validates whether the sending server belongs to the domain. DKIM validates the message signature. DMARC combines SPF and DKIM with a domain policy. ARC helps when messages pass through forwarders or mailing lists.

bash
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT default._domainkey.example.com +short


# DMARC fuer neue Domains zuerst beobachten:
# v=DMARC1; p=none; rua=mailto:dmarc@example.com


# Erst nach Auswertung verschaerfen:
# v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
# v=DMARC1; p=reject; rua=mailto:dmarc@example.com

For production domains, usually start DMARC in observation mode. Once legitimate senders, forwarders, newsletter systems and partner mail servers are understood, you can move deliberately to `quarantine` or `reject`.

Evaluate RBL, SURBL and URL checks

RBLs evaluate sending IPs or networks, while SURBL and URL checks evaluate domains and links inside the message. These hits are often strong signals, but should not be interpreted in isolation. For false positives, check whether a legitimate service is compromised, misconfigured or only temporarily listed.

bash
rspamadm configdump rbl
rspamadm configdump surbl
rspamc symbols < /tmp/gtube.eml | grep -E 'RBL|SURBL|URL|PHISH|Action|Score' || true

Validate fuzzy, phishing and content patterns

Fuzzy checks detect known or similar content without requiring every message to be identical. Phishing and URL modules evaluate suspicious targets, redirects and patterns. In production, DNS must work reliably and external lookups must not be slowed down by firewall, proxy or resolver issues.

bash
rspamadm configdump fuzzy_check
rspamadm configdump phishing
journalctl -u grommunio-antispam --since "1 hour ago" --no-pager | grep -Ei 'fuzzy|phishing|surbl|resolve|timeout' || true

Enable greylisting and rate limits deliberately

Greylisting delays suspicious delivery attempts, and rate limits restrict unusual sending patterns. Both features can be effective, but they intentionally introduce friction. Do not enable them blindly; operate them with monitoring, exceptions for legitimate systems and clear communication.

bash
rspamadm configdump greylist
rspamadm configdump ratelimit
rspamc stat | grep -Ei 'greylist|reject|add header|no action'

Operate Bayes, neural and training data

Bayes and neural are learning mechanisms. They need clean data, time and control. A fresh system already catches a lot through rules, reputation and authentication; learning becomes important when real false positives and false negatives are classified cleanly.

bash
rspamadm configdump classifier-bayes 2>/dev/null || rspamadm configdump statistics
rspamadm configdump neural
rspamc stat

Treat training data as operational data. If Redis, Bayes or maps are lost, the filter does not start from zero technically, but important local experience is missing.

Integrate antivirus and external services consciously

grommunio-antispam provides interfaces for antivirus and external checks. Whether you enable them depends on operating model, privacy, latency, licensing and existing security architecture. The key point: external checks must be monitored so timeouts do not damage mail flow.

bash
rspamadm configdump antivirus
rspamadm configdump external_services
journalctl -u grommunio-antispam --since "1 hour ago" --no-pager | grep -Ei 'antivirus|external|timeout|error' || true

Monitoring and Day-2 operations

In daily operations, rejects are not the only signal. Monitor scan time, queue length, DNS resolution, Redis state, mail volume, error log, certificates, disk space, updates and unusual action shifts. This is where dashboard, throughput, history and logs become valuable together.

bash
systemctl is-active grommunio-antispam postfix redis@grommunio
mailq
rspamc stat
df -h
journalctl -u grommunio-antispam --since "24 hours ago" --no-pager | tail -200

Production checklist

  1. Expose controller port 11334 only internally through VPN, bastion or IP restriction.

  2. Validate SPF, DKIM and DMARC for all sending domains and harden gradually.

  3. Verify Postfix milter integration and set `milter_default_action` deliberately.

  4. Include Redis instance, Bayes data, history and local maps in backup and restore.

  5. Adjust actions only after observing real mail flows.

  6. Monitor greylisting, rate limits and rejects during rollout.

  7. Define a false-positive and false-negative process.

  8. Run updates with maintenance window, snapshot/backup and rollback plan.

  9. Monitor logs, queue, DNS, certificates, disk space and scan times.

  10. Document which local overrides exist and why.

Order in the grommunio series

If you are building grommunio from scratch, start with the installation guide. This antispam article is the next Day-2 step. For SSO and central authentication, continue with grommunio-auth.

More product context is available on the grommunio-antispam page.

Sources and validated basis

  • grommunio documentation: architecture and the role of grommunio-antispam in the suite.

  • Rspamd documentation: symbols, score model, actions, worker model and core features.

  • Validated reference installation: grommunio 2026.06.1, grommunio-antispam 4.1.5, Postfix milter, Redis, GTUBE scan, Bayes learning and WebUI screenshots.

Operate grommunio antispam in production

ForgeOne plans and operates grommunio as a collaboration platform including licensing, mail flow, DNS, Rspamd tuning, monitoring, backup and support. If you want to use grommunio as an Exchange alternative or mail security platform, we can review architecture, licensing and rollout with you.

Discuss grommunio antispam