Hallo zusammen,
mir ist bei der Nutzung der E-Mail Inhaltsfilter in ISPConfig etwas aufgefallen, das vermutlich auch andere Admins betrifft – insbesondere diejenigen, die keine tiefen Postfix/Regex-Kenntnisse haben.
Es geht nicht um einen Fehler, sondern eher um eine Benutzerfreundlichkeits-Falle, in die man leicht hineingerät.
Ausgangssituation
In ISPConfig kann man unter
E-Mail - Inhalt filtern (Header / Body Checks)
einfach Begriffe eintragen, z. B.: Casino, Lidl Aktion, Musterstraße etc.. Als Anwender geht man ganz natürlich davon aus, dass diese Wörter dann im Mailinhalt gesucht und bei einem Treffer die gewählte Aktion (REJECT, DISCARD usw.) ausgeführt wird.
Technischer Hintergrund
ISPConfig schreibt diese Einträge in:
/etc/postfix/header_checks
/etc/postfix/body_checks
Diese sind in Postfix als
regexp:/etc/postfix/header_checks
regexp:/etc/postfix/body_checks
eingebunden.
Das bedeutet: Postfix erwartet gültige Regex-Patterns, keine reinen Textwörter.
Ein Eintrag wie, Casino REJECT Casino, ist für Postfix kein gültiger Request und wird still ignoriert.
Im Log seiht man dann nur: regexp map ... ignoring unrecongnized request
Für den Anwender sieht es aber so aus, als würde der Filter einfach "nicht richtig greifen".
Weiteres Problem: Umlaute & Mail-Kodierung
zusätzlich werden Mailtexte oft quoted-printable kodiert.
Beispiel: Musterstraße taucht im Body dann als "Musterstra=C3=9Fe" auf. Ein Filter auf /Musterstraße/ greift daher nicht zuverlässig, selbst wenn das Regex korrekt wäre.
Warum das für Anwender schwierig ist
Die aktuelle Eingabe suggeriert: "Trage hier Wörter ein, die blockiert werden sollen."
Tatsächlich ist es aber nötig, das der Anwender über ausreichendes Wissen über:
- Regex-Kenntnisse (/Begriff/)
- Wissen über Mail-Kodierungen
- Umgang mit Leerzeichen in Regex ([[:space:]]+) verfügt.
Das ist für viele Administratoren, die ISPConfig bewusst wegen der GUI nutzen, nicht offensichtlich.
Mögliche Verbesserungsideen
Das ist nur als UX-Vorschlag gemeint - nicht als Kritik am aktuellen System.
Automatische Regex-Erzeugung
Wen ein Benutzer Casino einträgt, könnte ISPConfig intern speichern: /Casino/,
bei Lidl Aktion automatisch /Lidl[[:space:]]+Aktion/
der Benutzer arbeitet weiter mit Klartext, ISPConfig erzeugt die Regex.
„Body-Filter arbeiten auf technisch kodierten E-Mail-Inhalten. Umlaute und Sonderzeichen können anders dargestellt sein. Für zuverlässige Filterung sind einfache Wortstämme empfehlenswert.“
☑ Einfacher Text (empfohlen)
☐ Erweiterter Regex-Modus
So bleiben Experten flexibel, Einsteiger werden aber nicht ins Regex-Land geworfen.
Langfristig: Alternative über Rspamd
Da viele Systeme inzwischen Rspamd nutzen, wäre es ggf. auch denkbar, Inhaltsbegriffe optional dort als Textfilter-Regeln abzulegen. Rspamd kommt mit Encodings und Textmustern oft robuster klar als Postfix body_checks.
Fazit
Die Funktion an sich ist absolut sinnvoll und leistungsfähig – nur die Darstellung in der GUI lässt nicht erkennen, dass hier Regex-Syntax erwartet wird.
Ein kleiner Zwischenschritt zwischen „einfacher Begriff“ und „technischer Postfix-Regex“ würde die Funktion deutlich zugänglicher machen.
Viele Grüße
und danke für die großartige Arbeit an ISPConfig
mir ist bei der Nutzung der E-Mail Inhaltsfilter in ISPConfig etwas aufgefallen, das vermutlich auch andere Admins betrifft – insbesondere diejenigen, die keine tiefen Postfix/Regex-Kenntnisse haben.
Es geht nicht um einen Fehler, sondern eher um eine Benutzerfreundlichkeits-Falle, in die man leicht hineingerät.
Ausgangssituation
In ISPConfig kann man unter
E-Mail - Inhalt filtern (Header / Body Checks)
einfach Begriffe eintragen, z. B.: Casino, Lidl Aktion, Musterstraße etc.. Als Anwender geht man ganz natürlich davon aus, dass diese Wörter dann im Mailinhalt gesucht und bei einem Treffer die gewählte Aktion (REJECT, DISCARD usw.) ausgeführt wird.
Technischer Hintergrund
ISPConfig schreibt diese Einträge in:
/etc/postfix/header_checks
/etc/postfix/body_checks
Diese sind in Postfix als
regexp:/etc/postfix/header_checks
regexp:/etc/postfix/body_checks
eingebunden.
Das bedeutet: Postfix erwartet gültige Regex-Patterns, keine reinen Textwörter.
Ein Eintrag wie, Casino REJECT Casino, ist für Postfix kein gültiger Request und wird still ignoriert.
Im Log seiht man dann nur: regexp map ... ignoring unrecongnized request
Für den Anwender sieht es aber so aus, als würde der Filter einfach "nicht richtig greifen".
Weiteres Problem: Umlaute & Mail-Kodierung
zusätzlich werden Mailtexte oft quoted-printable kodiert.
Beispiel: Musterstraße taucht im Body dann als "Musterstra=C3=9Fe" auf. Ein Filter auf /Musterstraße/ greift daher nicht zuverlässig, selbst wenn das Regex korrekt wäre.
Warum das für Anwender schwierig ist
Die aktuelle Eingabe suggeriert: "Trage hier Wörter ein, die blockiert werden sollen."
Tatsächlich ist es aber nötig, das der Anwender über ausreichendes Wissen über:
- Regex-Kenntnisse (/Begriff/)
- Wissen über Mail-Kodierungen
- Umgang mit Leerzeichen in Regex ([[:space:]]+) verfügt.
Das ist für viele Administratoren, die ISPConfig bewusst wegen der GUI nutzen, nicht offensichtlich.
Mögliche Verbesserungsideen
Das ist nur als UX-Vorschlag gemeint - nicht als Kritik am aktuellen System.
Automatische Regex-Erzeugung
Wen ein Benutzer Casino einträgt, könnte ISPConfig intern speichern: /Casino/,
bei Lidl Aktion automatisch /Lidl[[:space:]]+Aktion/
der Benutzer arbeitet weiter mit Klartext, ISPConfig erzeugt die Regex.
Hinweistext bei Body-Filtern
Ein kurzer Hinweis würde schon helfen:„Body-Filter arbeiten auf technisch kodierten E-Mail-Inhalten. Umlaute und Sonderzeichen können anders dargestellt sein. Für zuverlässige Filterung sind einfache Wortstämme empfehlenswert.“
Option: „Einfacher Textfilter“ vs. „Regex-Modus“
Ein Umschalter in der Maske:☑ Einfacher Text (empfohlen)
☐ Erweiterter Regex-Modus
So bleiben Experten flexibel, Einsteiger werden aber nicht ins Regex-Land geworfen.
Langfristig: Alternative über Rspamd
Da viele Systeme inzwischen Rspamd nutzen, wäre es ggf. auch denkbar, Inhaltsbegriffe optional dort als Textfilter-Regeln abzulegen. Rspamd kommt mit Encodings und Textmustern oft robuster klar als Postfix body_checks.
Fazit
Die Funktion an sich ist absolut sinnvoll und leistungsfähig – nur die Darstellung in der GUI lässt nicht erkennen, dass hier Regex-Syntax erwartet wird.
Ein kleiner Zwischenschritt zwischen „einfacher Begriff“ und „technischer Postfix-Regex“ würde die Funktion deutlich zugänglicher machen.
Viele Grüße
und danke für die großartige Arbeit an ISPConfig
