Ziel dieser Anleitung

Diese Anleitung baut auf der grommunio-2026.06.1-Installation auf und zeigt Schritt für Schritt, wie du grommunio-antispam mit Rspamd verstehst, prüfst, testest, trainierst und betrieblich einordnest. Der Beitrag ist bewusst praktisch: Du bekommst Befehle, Kontrollpunkte, Screenshots aus einer geprüften grommunio-2026.06.1-Installation und Hinweise, welche Werte du produktiv nicht blind übernehmen solltest.

  • Du erkennst, welche Rspamd-Prozesse in grommunio laufen.

  • Du testest den Mailfilter mit einer sicheren GTUBE-Testnachricht.

  • Du liest Score, Action, Symbole und History richtig.

  • Du trainierst Spam und Ham kontrolliert.

  • Du verstehst, welche Funktionen für produktiven Betrieb wichtig sind: SPF, DKIM, DMARC, RBL/SURBL, Fuzzy, Greylisting, Rate Limits, Neural/Bayes, Multimap und Monitoring.

Die Basisinstallation findest du hier: grommunio 2026.06.1 installieren.

Geprüfte Referenzinstallation

Die Anleitung wurde gegen eine isolierte grommunio-Appliance geprüft. Der Hostname, die Domain und alle Nachrichten sind synthetisch. Die Rspamd-Weboberfläche wurde nicht öffentlich geöffnet, sondern per SSH-Tunnel gegen den lokalen Controller-Port getestet.

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

In der geprüften Referenzinstallation lief grommunio 2026.06.1 mit grommunio-antispam 4.1.5, Postfix 3.10.2 und Redis 8.2.3. Wichtig: Diese Appliance nutzte XFS auf dem Root-Dateisystem und systemd-networkd für die Netzwerkkonfiguration. Das ist ein geprüfter Appliance-Zustand, keine allgemeine Aussage über jede SUSE- oder SLES-Installation.

Architektur: Postfix, Rspamd und Redis

grommunio-antispam basiert auf Rspamd. Rspamd ist ein modularer Mailfilter: eine Nachricht wird von mehreren unabhängigen Prüfungen bewertet. Jede Prüfung liefert ein Symbol und optional Punkte. Aus der Summe entsteht die Action, zum Beispiel no action, add header, greylist oder reject.

  • Postfix nimmt Mail an und übergibt sie per Milter an Rspamd.

  • Der Proxy-Worker lauscht lokal auf Port 11332.

  • Normal-Worker prüfen Nachrichten auf Port 11333.

  • Der Controller mit WebUI und API lauscht lokal auf Port 11334.

  • Redis speichert Zustände wie Bayes, History, Greylisting, Rate-Limits und weitere lernende Daten.

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 der geprüften Installation war `smtpd_milters = inet:localhost:11332` gesetzt. Der Controller war nur auf localhost erreichbar. Genau so sollte es auch produktiv gedacht werden: die Maildienste werden passend veröffentlicht, der Antispam-Controller bleibt im Management-Netz, hinter VPN oder hinter klaren IP-Regeln.

Schritt 1: Dienste und Konfiguration prüfen

Beginne immer mit einer Zustandsprüfung. Wenn Dienste nicht laufen oder die Konfiguration nicht parsebar ist, ist jede fachliche Filteranalyse wertlos.

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

Erwartet ist `syntax OK`, ein aktiver Antispam-Dienst und ein plausibler `rspamc stat`-Output. Warnungen musst du bewerten: DNS-Fehler, fehlende Maps oder kaputte lokale Includes sind oft Betriebsfehler, während eine frische Installation ohne Mailvolumen naturgemäß noch wenig Statistik zeigt.

Schritt 2: Weboberfläche sicher öffnen

Für Administration und Screenshots reicht ein SSH-Tunnel. Du musst Port 11334 nicht öffentlich machen. Das schützt die Controller-API und reduziert die Angriffsfläche.

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 einer grommunio-2026.06.1-Installation mit grommunio-antispam 4.1.5.

Schritt 3: Actions, Scores und Symbole verstehen

Rspamd trifft keine magische Ja/Nein-Entscheidung. Es sammelt Symbole, addiert Scores und empfiehlt eine Action. In der geprüften Ausgangskonfiguration lagen die Schwellwerte bei greylist 4, add header 6 und reject 15. Produktiv änderst du solche Werte erst nach Beobachtung realer Mailströme.

127.0.0.1:11334

Screenshot: Actions und Maps in der Rspamd-Konfiguration; lokale Overrides gehören kontrolliert dokumentiert.

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

Bearbeite ausgelieferte Defaults nicht direkt. Lege lokale Dateien in `local.d` an und prüfe danach immer `rspamadm configtest`. Bei grommunio heißt der Konfigurationspfad in der Appliance `/etc/grommunio-antispam`; Beispiele aus generischer Rspamd-Dokumentation verwenden häufig `/etc/rspamd`.

Schritt 4: Erste Nachricht scannen

Erstelle zuerst eine harmlose Testnachricht und prüfe sie über `rspamc symbols`. Achte nicht nur auf die Action, sondern auf die Begründung: Symbole wie fehlende Received-Header, Test-Domains oder DNS-Probleme können in synthetischen Tests höhere Scores verursachen als in einer echten Mailkette.

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 der geprüften Testausführung wurde diese Nachricht wegen synthetischer Merkmale als `add header` bewertet. Das ist ein gutes Beispiel dafür, warum du Test-Ergebnisse erklären musst: Die Technik funktioniert, aber die Datenbasis entspricht nicht vollständig einer echten Produktionsmail.

Schritt 5: Spam mit GTUBE sicher testen

Für reproduzierbare Tests verwendest du GTUBE. Das ist eine harmlose Testsignatur, die Spamfilter wie eine Spam-Erkennung behandeln sollen. So musst du keine echte Spam-Mail speichern oder weiterleiten.

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

Der GTUBE-Test lieferte `Action: reject`, `Score: 15.00 / 15.00` und das Symbol `GTUBE`. Damit ist der Filterpfad vom Client über Rspamd bis zur Action nachvollziehbar.

127.0.0.1:11334

Screenshot: Scan/Learn mit GTUBE: die Oberfläche zeigt Reject, Score und auslösendes Symbol.

Schritt 6: Bayes-Lernen kontrolliert einsetzen

Bayes-Lernen ist wertvoll, aber nur mit sauberen Trainingsdaten. Trainiere eindeutige Spam-Beispiele als Spam und eindeutige False Positives als Ham. Wenn Benutzer ungeprüft alles melden, verschlechterst du die Qualität des Filters.

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

Nach dem Lernen wurde im Dashboard ein Ham-Learn sichtbar. Für produktive Systeme gehören ein Meldeprozess, Stichprobenprüfung, Backup der Zustandsdaten und regelmäßige Kontrolle der False-Positive-Rate dazu.

Schritt 7: History und konkrete Ursachen lesen

Die History ist der schnellste Weg von einer Benutzerbeschwerde zur Ursache. Öffne die konkrete Nachricht und prüfe Absender, Empfänger, Betreff, Action, Score, Scan-Zeit und Symbole. Erst danach entscheidest du, ob DNS, Reputation, Content, Attachment, URL, Bayes oder eine lokale Regel verantwortlich war.

127.0.0.1:11334

Screenshot: History nach dem GTUBE-Test mit Action, Score, Symbolen und Scan-Zeit.

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

Schritt 8: Symbols als Tuning-Grundlage nutzen

Die Symbols-Ansicht zeigt, welche Prüfungen existieren und wie sie bewertet werden. Das ist der bessere Startpunkt als blind Schwellenwerte zu erhöhen. Wenn ein Symbol regelmäßig falsche Ergebnisse liefert, prüfst du zuerst DNS, lokale Maps, Authentifizierung und reale Beispiele.

127.0.0.1:11334

Screenshot: Symbols zeigen, welche Einzelprüfungen Rspamd in die Gesamtbewertung einrechnet.

Schritt 9: Allowlist, Denylist und Multimap sauber planen

Ausnahmen sind nützlich, aber gefährlich, wenn sie zu breit sind. Nutze konkrete Absender, Partnerdomains oder technische Relay-IP-Adressen. Setze keine globale Allowlist für große Freemail- oder 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

Für produktive Änderungen brauchst du einen Review-Prozess: Wer darf Ausnahmen anlegen, wie lange gelten sie, welche Beispiele belegen die Ausnahme und wann wird sie erneut geprüft?

Schritt 10: Test-Selectors verstehen

Selectors extrahieren Felder aus Nachrichten. Damit prüfst du, ob eine Regel wirklich den Wert sieht, den du erwartest: SMTP-Absender, Empfänger, Header, Subject, IP, MIME-Struktur oder URL-Bestandteile.

127.0.0.1:11334

Screenshot: Test-Selectors mit synthetischer Nachricht; nützlich vor eigenen Regeln und Maps.

Wichtige Feature-Bereiche in grommunio-antispam

  • SPF, DKIM, DMARC und ARC prüfen die Identität und Authentizität von Mailflüssen.

  • RBL und SURBL bewerten IPs, Domains und URLs über Reputationsdaten.

  • Fuzzy Checks erkennen bekannte oder ähnliche Spam-Inhalte.

  • Bayes und Neural verbessern Bewertungen über Trainings- und Lernmodelle.

  • Greylisting und Rate Limits bremsen verdächtige Zustellmuster.

  • Multimap, Force Actions und lokale Maps bilden kontrollierte Ausnahmen und Regeln ab.

  • Milter Headers sorgen dafür, dass Ergebnisse sichtbar in Mailheader geschrieben werden können.

  • External Services und Antivirus-Integration sind Erweiterungspunkte, müssen aber bewusst geplant und überwacht werden.

127.0.0.1:11334

Screenshot: Durchsatz und Actions helfen beim Betrieb, besonders nach Policy- oder DNS-Änderungen.

SPF, DKIM, DMARC und ARC richtig einordnen

Diese Prüfungen sind keine kosmetischen Zusatzfelder, sondern die Vertrauenskette deiner Mail-Domains. SPF prüft, ob der sendende Server zur Domain passt. DKIM prüft die Signatur der Nachricht. DMARC verbindet SPF und DKIM mit einer Domain-Policy. ARC hilft, wenn Nachrichten über Weiterleitungen oder Mailinglisten laufen.

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

Starte DMARC für produktive Domains meist mit Beobachtung. Wenn legitime Sender, Weiterleitungen, Newsletter-Systeme und Partner-Mailserver sauber erfasst sind, kannst du kontrolliert auf `quarantine` oder `reject` gehen.

RBL, SURBL und URL-Prüfungen bewerten

RBLs prüfen sendende IPs oder Netzwerke, SURBL- und URL-Prüfungen bewerten Domains und Links innerhalb der Nachricht. Diese Treffer sind oft stark, aber nie isoliert zu betrachten. Prüfe bei False Positives, ob ein legitimer Dienst kompromittiert, falsch konfiguriert oder nur temporär gelistet ist.

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

Fuzzy, Phishing und Inhaltsmuster prüfen

Fuzzy Checks erkennen bekannte oder ähnliche Inhalte, ohne dass jede Nachricht exakt gleich sein muss. Phishing- und URL-Module prüfen verdächtige Zieladressen, Umleitungen und Muster. Für produktiven Betrieb ist wichtig, dass DNS funktioniert und externe Lookups nicht durch Firewall, Proxy oder Resolver-Probleme ausgebremst werden.

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

Greylisting und Rate Limits kontrolliert aktivieren

Greylisting verzögert verdächtige Zustellversuche, Rate Limits begrenzen auffällige Sendemuster. Beide Funktionen können wirksam sein, erzeugen aber bewusst Reibung. Deshalb gehören sie nicht blind scharfgestellt, sondern mit Monitoring, Ausnahmen für legitime Systeme und klarer Kommunikation betrieben.

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

Bayes, Neural und Trainingsdaten betreiben

Bayes und Neural sind lernende Verfahren. Sie brauchen saubere Daten, Zeit und Kontrolle. Ein frisches System erkennt bereits viel über Regeln, Reputation und Authentifizierung; das Lernen wird dann wichtig, wenn reale False Positives und False Negatives sauber klassifiziert werden.

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

Behandle Trainingsdaten wie Betriebsdaten. Wenn Redis, Bayes oder Maps verloren gehen, startet der Filter fachlich nicht bei null, aber wichtige lokale Erfahrungen fehlen.

Antivirus und externe Services bewusst anbinden

grommunio-antispam bringt die Schnittstellen für Antivirus- und externe Prüfungen mit. Ob du sie aktivierst, hängt von Betriebsmodell, Datenschutz, Latenz, Lizenzierung und vorhandener Security-Architektur ab. Wichtig ist: externe Checks gehören überwacht, damit Timeouts nicht den Mailflow beschädigen.

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 und Day-2-Betrieb

Im laufenden Betrieb zählen nicht nur Rejects. Beobachte Scan-Zeit, Queue-Länge, DNS-Auflösung, Redis-Zustand, Mailvolumen, Fehlerlog, Zertifikate, Speicherplatz, Updates und auffällige Änderungen bei den Actions. Genau dafür sind Dashboard, Throughput, History und Logs gemeinsam wertvoll.

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

Produktions-Checkliste

  1. Controller-Port 11334 nur intern, per VPN, Bastion oder IP-Restriktion erreichbar machen.

  2. SPF, DKIM und DMARC für alle sendenden Domains prüfen und schrittweise härten.

  3. Postfix-Milter-Integration prüfen und `milter_default_action` bewusst setzen.

  4. Redis-Instanz, Bayes-Daten, History und lokale Maps in Backup und Restore aufnehmen.

  5. Actions erst nach Beobachtung realer Mailströme anpassen.

  6. Greylisting, Rate Limits und Rejects zunächst mit Monitoring begleiten.

  7. False-Positive- und False-Negative-Prozess definieren.

  8. Updates mit Wartungsfenster, Snapshot/Backup und Rollback-Plan ausführen.

  9. Logs, Queue, DNS, Zertifikate, Speicherplatz und Scan-Zeiten überwachen.

  10. Dokumentieren, welche lokalen Overrides warum existieren.

Reihenfolge in der grommunio-Serie

Wenn du grommunio neu aufbaust, lies zuerst die Installationsanleitung. Danach passt dieser Antispam-Beitrag als nächster Day-2-Schritt. Für SSO und zentrale Anmeldung geht es weiter mit grommunio-auth.

Mehr zum Produkt findest du auf der grommunio-antispam-Seite.

Quellen und geprüfte Grundlage

  • grommunio-Dokumentation: Architektur und Rolle von grommunio-antispam in der Suite.

  • Rspamd-Dokumentation: Symbole, Score-Modell, Actions, Worker-Modell und zentrale Features.

  • Geprüfte Referenzinstallation: grommunio 2026.06.1, grommunio-antispam 4.1.5, Postfix-Milter, Redis, GTUBE-Scan, Bayes-Lernen und WebUI-Screenshots.

grommunio-Antispam produktiv betreiben

ForgeOne plant und betreibt grommunio als Collaboration-Plattform inklusive Lizenzierung, Mailflow, DNS, Rspamd-Tuning, Monitoring, Backup und Support. Wenn du grommunio als Exchange-Alternative oder Mail-Security-Plattform einsetzen willst, prüfen wir gemeinsam Architektur, Lizenzmodell und Rollout.