So richten Sie benutzerdefinierte SpamAssassin-Regeln in Zimbra ein (sicher)

Welche Zimbra SpamAssassin-Datei sollten Sie bearbeiten?

Für Zimbra Collaboration Suite 8.5 und höher platziert die Zimbra-Dokumentation lokale SpamAssassin-Anpassungen im Verzeichnis `/ etc /opt/zimbra/data/spamassassin/localrules/`. Dort kann eine Regeldatei mit der .cfEndung `.sql` abgelegt werden; das Zimbra-Beispiel verwendet jedoch eine separate Datei für eine benutzerdefinierte Regel. Ältere Zimbra-Versionen verwendeten andere Speicherorte. Überprüfen Sie daher die Version und das Verzeichnis auf Ihrem Server, bevor Sie Änderungen vornehmen. Die aktuelle Paketstruktur kann je nach Version oder Bereitstellung variieren.

Diese Anleitung fügt eine kleine, reversible, seitenweite Regel hinzu, prüft deren Syntax, lädt den E-Mail-Scan-Dienst neu und verifiziert eine zugestellte Nachricht. Sie setzt voraus, dass Sie den Zimbra MTA administrieren. Wenn Sie mehrere MTA-Server betreiben, wenden Sie die Datei auf jedem Server an, der eingehende E-Mails scannt, und laden Sie SpamAssassin dort neu.

Die benutzerdefinierten SpamAssassin-Regeln von Zimbra dokumentieren den Pfad zu den lokalen Regeln und den zmamavisdctl restartBefehl. Die darin enthaltenen Anti-Spam-Richtlinien unterscheiden die ältere ZCS 8-Konfiguration von ZCS 8.5 und späteren Versionen.

Was ändert eine benutzerdefinierte Regel?

Eine SpamAssassin-Regel erkennt ein Nachrichtenmerkmal, vergibt einen symbolischen Regelnamen und trägt zu einer Bewertung bei. SpamAssassin kombiniert diese Bewertung mit anderen Testergebnissen. Zimbra wendet anschließend die konfigurierten Spam-Bekämpfungsschwellen an. Eine Regel allein garantiert nicht, dass eine Nachricht im Junk-Ordner landet oder abgelehnt wird: Die restliche Nachrichtenbewertung und die Servereinstellungen sind entscheidend.

Diese Unterscheidung ist bei der Wahl des Bewertungswerts wichtig. Beginnen Sie mit einem moderaten Wert, prüfen Sie Fehlalarme und erhöhen Sie ihn erst, wenn Tests die Zuverlässigkeit des Signals bestätigen. Vermeiden Sie es, einen hohen Wert aus einem Beispiel zu übernehmen, ohne Ihren eigenen erforderlichen Spam-Bewertungswert und die entsprechende Verwerfungsschwelle zu überprüfen.

Bevor Sie irgendetwas bearbeiten, was sollten Sie überprüfen?

• Version und Pfad: Prüfen Sie Ihre Zimbra-Version und ob der /opt/zimbra/data/spamassassin/localrulesPfad existiert. Der Pfad in dieser Anleitung gilt laut Zimbra-Dokumentation für ZCS 8.5 und höher. Gehen Sie nicht davon aus, dass er auch für ältere Versionen gilt.
• Welcher Host scannt E-Mails? Identifizieren Sie jeden MTA, auf dem Amavis/SpamAssassin ausgeführt wird. Eine auf einem Server installierte Regel erscheint nicht automatisch auf einem anderen unabhängigen MTA.
• Regelabsicht: Wählen Sie ein spezifisches, wiederholbares Nachrichtensignal. Vermeiden Sie Regeln, die allgemeine Begriffe wie „kostenlos“ oder „Angebot“ ohne zusätzliche Belege erfassen.
• Rollback: Vor Änderungen an bestehenden Dateien muss eine Sicherungskopie erstellt werden. Verwenden Sie für die neue Regel einen aussagekräftigen Dateinamen und vermeiden Sie das versehentliche Überschreiben vorhandener .cfDateien.

Hierbei handelt es sich um serverseitige Anpassungen, nicht um Postfachfilter. Alle Benutzer, deren E-Mails den konfigurierten Scanner passieren, können betroffen sein.

Wie formuliert man eine einfache Regel?

SpamAssassin unterstützt Regeltypen wie Header-Regeln header, bodyHeader uri-Regeln, Body-Regeln und metaURI-Regeln. Header-Regeln sind nützlich, wenn ein bestimmter Betreff oder Header-Wert das Signal ist. Body-Regeln durchsuchen den Textinhalt von Nachrichten. Die SpamAssassin-Dokumentation weist darauf hin, dass normale Body-Regeln auf dekodierten Text angewendet werden und den Betreff standardmäßig als Teil des Nachrichtentextes behandeln. Verwenden Sie eine URI-Regel, wenn es speziell um Links geht.

Hier ist ein bewusst eingeschränktes Beispiel, das einen kleinen Punktzuwachs vergibt, wenn der Betreff einer Testnachricht eine bestimmte Formulierung enthält. Ersetzen Sie diese Formulierung durch ein Signal, das Sie in Ihren eigenen E-Mails verifiziert haben; dieses Beispiel ist keine allgemeine Spam-Signatur.

header LOCAL_SUBJECT_REVIEW Subject =~ /\bExample Vendor Alert\b/i
score LOCAL_SUBJECT_REVIEW 2.0
describe LOCAL_SUBJECT_REVIEW Subject contains the review phrase

Der symbolische Name muss eindeutig sein und Buchstaben, Ziffern und Unterstriche enthalten. Die headerZeile definiert die Übereinstimmung, scoresteuert die bei einem Treffer vergebenen Punkte und describeliefert eine Erklärung im SpamAssassin-Bericht. Die Beschreibung sollte kurz und prägnant sein und anderen Administratoren den Zweck des Tests verdeutlichen.

Die Konfigurationsreferenz von SpamAssassin beschreibt die Syntax der Header- und Body-Regeln, das Bewertungsverhalten und Details zu regulären Ausdrücken. Die installierte Zimbra-Version von SpamAssassin kann von der aktuellen Apache-Dokumentation abweichen. Vermeiden Sie daher die Verwendung neuerer Regelfunktionen, bis Sie deren Unterstützung lokal bestätigt haben.

Wie installiert man die Regel unter Zimbra 8.5 und höher?

1. Stellen Sie mit einem Administratorkonto, das zum Zimbra-Dienstkonto wechseln kann, eine Verbindung zum MTA her.
2. Überprüfen Sie das Installationsverzeichnis und das Verzeichnis „local-rules“. Zum Beispiel:
   su - zimbra
ls -ld /opt/zimbra/data/spamassassin/localrules
3. Wählen Sie einen Dateinamen, der noch nicht existiert, z. B. „.existieren“ local_subject_review.cf. Prüfen Sie zuerst:
   ls -l /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
   Falls die Datei existiert, untersuchen Sie sie und wählen Sie einen anderen Namen, anstatt sie zu überschreiben.
4. Erstellen Sie die neue Datei als zimbraBenutzer mit Ihrem Editor und fügen Sie die drei oben genannten Regelzeilen hinzu:
   vi /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
5. Speichern Sie die Datei und überprüfen Sie anschließend den Eigentümer und den Inhalt:
   ls -l /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf
cat /opt/zimbra/data/spamassassin/localrules/local_subject_review.cf

Falls das Verzeichnis fehlt, halten Sie an und überprüfen Sie die Zimbra-Version sowie deren dokumentierte Konfiguration. Erstellen Sie kein gleichnamiges Verzeichnis an einem beliebigen Ort; SpamAssassin wird es möglicherweise nicht laden.

Wie sollte man es validieren und neu laden?

Führen Sie vor dem Neuladen die Syntaxprüfung von SpamAssassin durch. Die Apache-Befehlszeilendokumentation beschreibt dies --lintals Regelsatz- und Konfigurationssyntaxprüfung. Führen Sie als Zimbra-Benutzer den Befehl aus, spamassassin --lintfalls die entsprechende ausführbare Datei in der Zimbra-Umgebung verfügbar ist. Falls der Befehl nicht gefunden wird oder die Zimbra-Konfiguration nicht geladen wird, suchen Sie die mitgelieferte ausführbare Datei und verwenden Sie den für die jeweilige Version passenden Konfigurationspfad, anstatt die Prüfung auf einer anderen Systeminstallation durchzuführen. Ein fehlerfreies Linting-Ergebnis prüft die Syntax; es beweist jedoch nicht, dass Ihr Muster mit den beabsichtigten Nachrichten übereinstimmt.

Die Befehlsreferenz von SpamAssassin erklärt die Option „lint“. Nach erfolgreicher Validierung starten Sie Amavis als dieser zimbraBenutzer neu, damit der Scanner die geänderten Regeln lädt.

zmamavisdctl restart

Das Beispiel für benutzerdefinierte Regeln von Zimbra verwendet diesen Dienstbefehl. Bei einer Installation mit mehreren MTAs wiederholen Sie die Dateibereitstellung und den Neustart des Dienstes für jeden relevanten Scanner. Falls Ihre Version einen anderen Dienstbefehl verwendet, befolgen Sie die entsprechende Zimbra-Dokumentation.

Woran erkennt man, ob die Regel funktioniert?

Senden Sie eine Testnachricht über denselben eingehenden Pfad, den auch die Benutzer verwenden. Verwenden Sie für eine Nachricht den exakten Betreff aus der Regel und senden Sie anschließend eine ähnliche Nachricht ohne diesen. Überprüfen Sie die ursprünglichen Header der zugestellten Nachricht, insbesondere X-Spam-Statusden Header „ LOCAL_SUBJECT_REVIEWscore“ und den Score-Beitrag. Vergleichen Sie die beiden Nachrichten und ermitteln Sie, wo Zimbra die jeweilige Nachricht zugestellt hat.

Das Ergebnis ist nützlich, wenn die Regel nur im vorgesehenen Test auftritt und die Gesamtpunktzahl die erwartete Verarbeitung liefert. Fehlt der Testname, überprüfen Sie, ob die Nachricht diesen MTA passiert hat, der Dateiname auf „.js“ endet .cf, die Datei sich im korrekten Verzeichnis „localrules“ befindet, der Scanner erfolgreich neu gestartet wurde und die Beispielnachricht tatsächlich dem regulären Ausdruck entspricht. Beachten Sie, dass E-Mail-Clients Diagnose-Header in ihrer normalen Ansicht ausblenden können; öffnen Sie daher den Nachrichtenquelltext oder die vollständigen Header.

Was passiert, wenn die Regel zu Fehlalarmen führt oder keine Übereinstimmung findet?

• Zu viele legitime Nachrichten stimmen überein: Reduzieren Sie die Punktzahl oder schränken Sie den regulären Ausdruck ein. Testen Sie anhand von Beispielen erwünschter und unerwünschter E-Mails, bevor Sie die Punktzahl erhöhen.
• Keine übereinstimmenden Nachrichten: Überprüfen Sie den genauen Headernamen, den regulären Ausdruck (Groß-/Kleinschreibung wird nicht beachtet), die Maskierung, die Dateierweiterung, den Pfad und einen Neustart des Dienstes. Bei URLs sollte eine uriRegel ausgewertet werden, anstatt anzunehmen, dass eine Regel im Nachrichtentext der beste Test ist.
• Lint meldet einen Fehler: Korrigieren Sie die angegebene Zeile und führen Sie Lint erneut aus, bevor Sie den Vorgang neu starten. Eine fehlerhafte benutzerdefinierte Regel kann Konfigurationsprobleme verursachen oder verhindern, dass erwartete Tests geladen werden.
• Die Regel wird angezeigt, aber die E-Mail verbleibt im Posteingang: Das kann normal sein, solange die hinzugefügten Punkte den Gesamtscore nicht über den konfigurierten Spam-Schwellenwert anheben. Überprüfen Sie den vollständigen X-Spam-StatusScore und die lokalen Grenzwerte für die Spambehandlung.

Um die Änderungen rückgängig zu machen, entfernen Sie nur die hinzugefügte benutzerdefinierte Datei und starten Sie Amavis neu. Wenn Sie eine bestehende Datei geändert haben, stellen Sie die gespeicherte Kopie wieder her und überprüfen Sie die Konfiguration, bevor Sie sie neu laden. Führen Sie ein kurzes Änderungsprotokoll mit dem Zweck der Regel, der Bewertung, den Testmeldungen und dem Namen der Wiederherstellungsdatei, damit zukünftige Administratoren die Regel überprüfen können.

Versions- und Verhaltensbeschränkungen

Die von Zimbra veröffentlichten Pfadhinweise beziehen sich explizit auf ZCS 8.5 und höher und dokumentieren ein anderes Layout für frühere Versionen. Die genaue Version von SpamAssassin und die Schwellenwerte sind installationsspezifisch. Eine gültige Regel kann sich bei unterschiedlichen Nachrichtenformaten, Relays und Mail-Flow-Pfaden unterschiedlich verhalten. Prüfen Sie die Dokumentation Ihrer installierten Version, testen Sie auf einer kontrollierten Route und beurteilen Sie die Ergebnisse anhand von Nachrichtenkopfzeilen und realen Fehlalarmbeispielen anstatt nur anhand des Regeltextes.