Kurzüberblick

Getestete Basis ist die openSUSE-basierte grommunio Appliance 2026.06.1. Die Beispiele verwenden durchgehend die neutrale Appliance-Domain https://mail.example.test; Pfade wie /web/, /admin/, /auth/, /chat/, /meet/ und /files/ liegen auf derselben Appliance.Dieser Beitrag zeigt, wie du grommunio-antispam mit Rspamd auf der bestehenden grommunio Appliance prüfst, konfigurierst und testest.

Du öffnest Rspamd aus dem grommunio Admin Interface, testest GTUBE, History, Symbols, Bayes-Lernen, Allowlist, Denylist, Logs und die technische Abnahme.

Getestete Umgebung

  • grommunio 2026 auf der openSUSE-basierten grommunio Appliance.

  • Alle Appliance-Befehle werden direkt auf der grommunio Appliance ausgeführt.

  • Öffentliche Beispiele verwenden durchgehend die neutrale Appliance-Domain https://mail.example.test.

Voraussetzungen

Eine bestehende oder geplante grommunio-Umgebung, passende DNS-Namen, TLS, administrative Zugänge und ein klares Ziel für Mail, Collaboration oder Betrieb.

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, echte Appliance-Screenshots 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 Appliance-Grundlage

Die Anleitung wurde gegen eine isolierte grommunio-Appliance geprüft. Hostname, Domain und Nachrichten sind synthetisch, die Schritte entsprechen aber dem produktiven Administrationsweg. Die Rspamd-Weboberfläche wurde nicht über einen freien Controller-Port veröffentlicht, sondern über den grommunio-Admin-Pfad `https://mail.example.test:8443/antispam/` geprüft.

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

Geprüft wurde 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 der geprüfte 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 Appliance war `smtpd_milters = inet:localhost:11332` gesetzt. Der Controller war nur lokal beziehungsweise über den grommunio-Admin-Pfad erreichbar. Genau so sollte es auch produktiv gedacht werden: 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 ein frisch aufgebautes System ohne Mailvolumen naturgemäß noch wenig Statistik zeigt.

Schritt 2: Weboberfläche aus dem Admin Interface öffnen

In der geprüften Appliance öffnest du Rspamd direkt aus dem grommunio Admin Interface. Die erreichbare URL lautet `https://mail.example.test:8443/antispam/`; ein separater öffentlicher Controller-Port ist dafür nicht nötig.

bash
https://mail.example.test:8443/antispam/
https://mail.example.test:8443/antispam/

Screenshot: Dashboard der geprüften grommunio-2026.06.1-Appliance 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 Konfiguration lagen die Schwellwerte bei greylist 4, add header 6 und reject 15. Produktiv änderst du solche Werte erst nach Beobachtung realer Mailströme.

https://mail.example.test:8443/antispam/

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 synthetische Nachricht 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 bei synthetischen Nachrichten 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: Testtermin für 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 für die Antispam-Validierung.
EOF


rspamc symbols < /tmp/ham.eml

In der geprüften Umgebung wurde diese Nachricht wegen synthetischer Merkmale als `add header` bewertet. Das ist ein gutes Beispiel dafür, warum du Testergebnisse 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 Funktionstest
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.

https://mail.example.test:8443/antispam/

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.

https://mail.example.test:8443/antispam/

Screenshot: History nach dem Funktionstest 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.

https://mail.example.test:8443/antispam/

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

Mail falsch bewertet: erst analysieren, dann Ausnahmen setzen

Allowlisting ist nicht der erste Schritt. Wenn du eine legitime Mail sofort erlaubst, ohne die Ursache zu verstehen, versteckst du DNS-, Authentifizierungs-, Reputations- oder Trainingsprobleme. Arbeite deshalb immer in dieser Reihenfolge:

bash
Mail falsch bewertet?
  -> SPF, DKIM und DMARC korrekt?
  -> Reputation von IP, Domain und URLs plausibel?
  -> Bayes oder Neural beteiligt?
  -> lokale Regel, Map oder Override beteiligt?
  -> erst dann kontrollierte Allowlist, Denylist oder Ausnahme setzen

Schritt 9: Allowlist, Denylist und Multimap sauber planen

Ausnahmen sind nützlich, aber gefährlich, wenn sie zu breit sind. Trenne deshalb Regeldefinition und dynamische Map-Dateien: die Multimap-Regel liegt in `/etc/grommunio-antispam/local.d`, die durch Admin-Prozesse gepflegten Listen liegen unter `/var/lib/grommunio-antispam`. So bleiben Paketdefaults unangetastet und die Listen können kontrolliert gesichert, versioniert oder über ein internes Tool gepflegt werden.

bash
install -d -m 0750 -o groas -g grommunio /var/lib/grommunio-antispam/maps


cat > /etc/grommunio-antispam/local.d/multimap.conf <<'EOF'
WHITELIST_SENDER_DOMAIN {
  type = "from";
  filter = "email:domain";
  map = "/var/lib/grommunio-antispam/maps/whitelist_sender_domain.map";
  score = -5.0;
  description = "Whitelisted sender domains reviewed by mail operations";
}


WHITELIST_SENDER_ADDRESS {
  type = "from";
  filter = "email";
  map = "/var/lib/grommunio-antispam/maps/whitelist_sender_address.map";
  score = -5.0;
  description = "Whitelisted sender addresses reviewed by mail operations";
}


BLACKLIST_SENDER_DOMAIN {
  type = "from";
  filter = "email:domain";
  map = "/var/lib/grommunio-antispam/maps/blacklist_sender_domain.map";
  score = 8.0;
  description = "Blacklisted sender domains reviewed by mail operations";
}


BLACKLIST_SENDER_ADDRESS {
  type = "from";
  filter = "email";
  map = "/var/lib/grommunio-antispam/maps/blacklist_sender_address.map";
  score = 8.0;
  description = "Blacklisted sender addresses reviewed by mail operations";
}
EOF


printf '%s\n' 'partner.example' > /var/lib/grommunio-antispam/maps/whitelist_sender_domain.map
: > /var/lib/grommunio-antispam/maps/whitelist_sender_address.map
: > /var/lib/grommunio-antispam/maps/blacklist_sender_domain.map
: > /var/lib/grommunio-antispam/maps/blacklist_sender_address.map
chown groas:grommunio /var/lib/grommunio-antispam/maps/*.map
chmod 0640 /var/lib/grommunio-antispam/maps/*.map


rspamadm configtest
systemctl reload grommunio-antispam
rspamc symbols < /tmp/ham.eml | grep -E 'WHITELIST|BLACKLIST|Action|Score' || true

Nutze konkrete Absender, Partnerdomains oder technische Relay-IP-Adressen. Setze keine globale Allowlist für große Freemail- oder Cloud-Domains. Nach jeder Änderung prüfst du `rspamadm configtest`, lädst den Dienst neu, sendest oder scannst eine konkrete Testmail und kontrollierst History, Score und Symbole.

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.

https://mail.example.test:8443/antispam/

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

Wichtige Feature-Bereiche in grommunio-antispam

Ordne die Funktionen nach Problemklasse. Reputation beantwortet die Frage, ob Absender, IP, Domain oder URL vertrauenswürdig wirken. Content- und Phishing-Prüfungen betrachten Inhalt, Links, Anhänge und Muster. Delivery Controls steuern Zustellverhalten und Geschwindigkeit. Learning passt Bewertungen über saubere Trainingsdaten an. Diese Gruppen helfen dir, nicht jedes Problem mit derselben Ausnahme zu lösen.

  • 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.

https://mail.example.test:8443/antispam/

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 für neue Domains zuerst beobachten:
# v=DMARC1; p=none; rua=mailto:dmarc@example.com


# Erst nach Auswertung verschärfen:
# 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.

Spam kommt durch: False Negatives prüfen

Wenn Spam zugestellt wird, erhöhst du nicht sofort globale Schwellenwerte. Prüfe zuerst, ob die Nachricht den Filterpfad überhaupt durchlaufen hat, welche Symbole gesetzt wurden und ob eine lokale Ausnahme den Score gedrückt hat.

  1. Scan- und Milter-Pfad prüfen: Postfix muss Rspamd erreichen.

  2. History öffnen und Action, Score, Symbole und Scan-Zeit lesen.

  3. Reputation prüfen: RBL, SURBL, URL-Checks und DNS-Auflösung.

  4. Bayes/Neural prüfen: wurde die Nachricht falsch als Ham gelernt?

  5. Lokale Maps prüfen: Allowlist, Force Action oder Override beteiligt?

  6. Kontrolliert als Spam lernen und danach mit einer vergleichbaren Nachricht erneut testen.

  7. Eigene Regel erst dann ergänzen, wenn wiederholbare Beispiele und klare Ursache vorliegen.

bash
postconf -n | grep -Ei 'milter|smtpd_milters'
journalctl -u postfix --since "2 hours ago" --no-pager | grep -Ei 'milter|rspamd|reject|warning' || true
rspamc symbols < /tmp/suspect.eml
rspamc learn_spam /tmp/suspect.eml
rspamadm configtest

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

Backup und Restore realistisch planen

Rspamd speichert keine Mailboxdaten. Für grommunio-antispam sicherst du vor allem lokale Konfiguration, lokale Maps und relevante Zustandsdaten. Nicht jeder Redis-Zähler ist gleich kritisch, aber Bayes/Learn-State, History, Greylisting- und Rate-Limit-Zustände können für Betrieb und Analyse wichtig sein.

  • Sichern: `/etc/grommunio-antispam`, lokale Includes, lokale Maps unter `/var/lib/grommunio-antispam`, dokumentierte Secrets und Betriebsnotizen.

  • Prüfen: Redis-Daten, Bayes/Learn-State, History, Greylisting und Rate-Limits nach gewünschtem Wiederanlaufverhalten.

  • Nicht verwechseln: Maildaten liegen in grommunio/Gromox, nicht in Rspamd/Redis.

  • Nach Restore testen: `rspamadm configtest`, Dienststart, Weboberfläche, GTUBE, Ham-Test, History und eine echte Zustellstrecke.

Reihenfolge in der grommunio-Serie

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

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

Spam automatisch lernen mit grommunio-spam-run

Die geprüfte grommunio-2026.06.1-Appliance bringt mit grommunio-spam-run.service und grommunio-spam-run.timer eine eigene Implementierung für Spam-Training mit. Verwende dafür keine alten Community-Skripte als Standard. Das mitgelieferte Script liegt unter /usr/sbin/grommunio-spam-run.sh und lernt Nachrichten aus dem Junk-Ordner der Benutzer mit rspamc learn_spam.

Wichtig: Lernen ist nicht dasselbe wie Löschen. Der Timer ruft das Script ohne Löschparameter auf. Das Löschen trainierter Junk-Mails passiert nur, wenn das Script bewusst mit -d gestartet wird. Aktiviere automatisches Löschen nicht blind, weil falsch einsortierte Nachrichten sonst zuerst trainiert und danach entfernt werden könnten.

bash
systemctl cat grommunio-spam-run.service
systemctl cat grommunio-spam-run.timer
systemctl status grommunio-spam-run.timer
rspamc stat

Im validierten Lab waren Service und Timer vorhanden, aber nicht per Preset aktiviert. Der manuelle Lauf war erfolgreich; ohne vorbereitete Trainingsnachrichten blieb die Zahl gelernter Nachrichten erwartungsgemäß bei 0. Für Produktion aktivierst du den Timer erst, wenn Junk-Folder, False-Positive-Prozess und Monitoring geklärt sind.

bash
systemctl enable --now grommunio-spam-run.timer
systemctl start grommunio-spam-run.service
journalctl -u grommunio-spam-run.service --since "10 minutes ago"
rspamc stat

Automatisches Ham-Learning war in der installierten Appliance nicht als eigener grommunio-Ham-Run-Timer vorhanden. Ham-Training gehört deshalb in einen kontrollierten Review-Prozess mit geprüften Beispielen, nicht in eine frei erfundene Timer-Anleitung.

Ergebniskontrolle / Technische Abnahme

Installation

Prüfung
Pakete und Komponenten prüfen
Erwartetes Ergebnis
Der Baustein ist vollständig installiert
Status
PASS

Dienste

Prüfung
systemd-Services prüfen
Erwartetes Ergebnis
Die notwendigen Dienste sind aktiv
Status
PASS

Netzwerk

Prüfung
Ports und URLs prüfen
Erwartetes Ergebnis
Der Baustein ist über die vorgesehenen Pfade erreichbar
Status
PASS

Grundfunktion

Prüfung
Standalone-Test ausführen
Erwartetes Ergebnis
Die Kernfunktion funktioniert vor der tieferen Integration
Status
PASS

Authentifizierung

Prüfung
SSO/Login testen
Erwartetes Ergebnis
Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich
Status
PASS oder N/A

grommunio Web

Prüfung
Integration aus Web prüfen
Erwartetes Ergebnis
Der Baustein ist aus grommunio Web erreichbar oder nutzbar
Status
PASS oder N/A

End-to-End

Prüfung
Realen Benutzerworkflow testen
Erwartetes Ergebnis
Der vollständige Workflow ist nachvollziehbar erfolgreich
Status
PASS

Neustart

Prüfung
Dienste neu starten
Erwartetes Ergebnis
Die Funktion bleibt nach einem Neustart erhalten
Status
PASS

Logs

Prüfung
Relevante Logs kontrollieren
Erwartetes Ergebnis
Keine blockierenden Fehler im geprüften Ablauf
Status
PASS