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.
hostname -fcat /etc/os-release | grep -E '^(PRETTY_NAME|VARIANT|ID_LIKE)='rpm -qa | grep -Ei 'grommunio-antispam|rspamd|postfix|redis' | sortrspamd --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.
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.
systemctl is-active grommunio-antispam postfix redis@grommuniorspamadm configtestrspamc statjournalctl -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.
ssh -L 11334:127.0.0.1:11334 root@mail.example.test# Danach lokal im Browser öffnen:# http://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.
Screenshot: Actions und Maps in der Rspamd-Konfiguration; lokale Overrides gehören kontrolliert dokumentiert.
rspamadm configdump actionsrspamadm configdump spfrspamadm configdump dkimrspamadm 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.
cat > /tmp/ham.eml <<'EOF'From: Alex Example <alex@example.test>To: Admin Example <admin@example.test>Subject: Lab Termin fuer MailfilterDate: Mon, 7 Sep 2026 10:00:00 +0200Message-ID: <ham-001@example.test>MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Hallo,das ist eine harmlose interne Testnachricht fuer die Antispam-Validierung.EOFrspamc 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.
cat > /tmp/gtube.eml <<'EOF'From: Sender Example <sender@example.net>To: Alex Example <alex@example.test>Subject: GTUBE Lab TestDate: Mon, 7 Sep 2026 10:05:00 +0200Message-ID: <spam-gtube-001@example.net>MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8This is a safe spam-filter test message.XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34XEOFrspamc 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.
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.
rspamc learn_spam /tmp/gtube.emlrspamc learn_ham /tmp/ham.emlrspamc 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.
Screenshot: History nach dem GTUBE-Test mit Action, Score, Symbolen und Scan-Zeit.
journalctl -u postfix --since "2 hours ago" --no-pagerjournalctl -u grommunio-antispam --since "2 hours ago" --no-pagermailq
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.
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.
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";}EOFprintf '%s\n' 'partner.example' > /etc/grommunio-antispam/local.d/trusted_sender_domain.maprspamadm configtestsystemctl 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.
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.
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.
dig TXT example.com +shortdig TXT _dmarc.example.com +shortdig 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.
rspamadm configdump rblrspamadm configdump surblrspamc 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.
rspamadm configdump fuzzy_checkrspamadm configdump phishingjournalctl -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.
rspamadm configdump greylistrspamadm configdump ratelimitrspamc 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.
rspamadm configdump classifier-bayes 2>/dev/null || rspamadm configdump statisticsrspamadm configdump neuralrspamc 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.
rspamadm configdump antivirusrspamadm configdump external_servicesjournalctl -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.
systemctl is-active grommunio-antispam postfix redis@grommuniomailqrspamc statdf -hjournalctl -u grommunio-antispam --since "24 hours ago" --no-pager | tail -200
Produktions-Checkliste
Controller-Port 11334 nur intern, per VPN, Bastion oder IP-Restriktion erreichbar machen.
SPF, DKIM und DMARC für alle sendenden Domains prüfen und schrittweise härten.
Postfix-Milter-Integration prüfen und `milter_default_action` bewusst setzen.
Redis-Instanz, Bayes-Daten, History und lokale Maps in Backup und Restore aufnehmen.
Actions erst nach Beobachtung realer Mailströme anpassen.
Greylisting, Rate Limits und Rejects zunächst mit Monitoring begleiten.
False-Positive- und False-Negative-Prozess definieren.
Updates mit Wartungsfenster, Snapshot/Backup und Rollback-Plan ausführen.
Logs, Queue, DNS, Zertifikate, Speicherplatz und Scan-Zeiten überwachen.
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.






