Postfix und header_checks mit regexp - Invalid regexp

A

Athesis

New Member
Hallo, ich habe folgendes Problem;
Ich möchte mithilfe eines regexp Header Filters E-Mails welche nicht von einer bestimmten domain, an eine bestimmte E-Mail gehen Herausfiltern. Dafür habe ich folgende regexp regel geschrieben:

Code: 
/^(.*)From: (?!.*@domain\.de)(.*)To: (.*)kunden(.*)@ziel\.de(.*)$/  DISCARD

Mithilfe eines Testheaders und einem Regexp Testers funktioniert dies, jedoch nicht mit Postfix. Postfix sagt:

Code: 
May 27 09:54:18 mail1 postfix/cleanup[14723]: warning: regexp map /etc/postfix/header_checks.regexp, line 1: Invalid preceding regular expression

Es ist sicher nur ein dummer Logikfehler welchen ich einfach nicht sehe. Ich hoffe ihr könnt mir Helfen

Gruß Athesis
 
Ich kann dort kein Fehler erkennen? Aber kann es sein das die Prüfung mmer nur für eine Zeile funktioniert? wenn ich die Prüfngen zu einzelnd mach schlägt er an. Könnte man also eventuell diese prüfungen Stapeln?
 
Was soll "(?![...])" denn für einen Zweck haben? Und wie kommst du darauf, dass das gültige Syntax für einen POSIX-kompatiblen regulären Ausdruck ist?
 
(?!Ausdruck) negative look-ahead assertion, Ausdruck darf nicht auf vorgenannten Ausdruck folgen Ausdruck(?!Ausdruck) (aus Regulärer Ausdruck ? Wikipedia und diverse andere Fachseiten und Fachliteratur)

Ziel ist:
Ausschließlich eine E-Mail von einem bestimmten Absender (*@domain.de) darf an das Ziel (kunden*@ziel.de) weitergegeben werden. Deswegen hatt ich dieses (?![...]) verwandt.
 
Im PCRE Modus von Postfix funktioniert das ganze jedoch auch nicht. Wie ich drauf komme? Ich hab es beim lesen etlicher Seiten immer nur die gleiche Syntax bei beiden gesehen.

Das ganze geht jeoch nun weit von der findung einer möglichen lösung nun weg :(
 
Ich Teste folgendermaßen die Regel:

Code: 
postmap -q - pcre:/etc/postfix/header_checks.cf < true.txt

in true.txt liegt ein Testheader worin unter Anderem

Code: 
From: Test Send <test@domain.de>
To: Test Mail <kundeneins@ziel.de>

drin steht. Den Header hab ich auch nochmal als einen der nicht durchkommen soll.

Das Suchmuster hab ich inzwischen etwas umgeschrieben:

Code: 
/From:.*<(?!.*@domain\.de>).*To:.*<kunden.*@ziel\.de>/ WARN wegfall

Nun, bei beiden arten passiert nichts, weder bei regexp noch bei pcre. Zur Hilfestellung habe ich inzwischen Regex Tester &ndash; RegexPal gefunden, bei welchem dieses Suchmuster einwandfrei funktioniert, in Postfix leider jedoch noch immer nicht :(
 
postfix mag regex nicht...

Ich habe das gleiche Problem, wie der OP for knapp 8 Jahren.

SPAM wird - bisher erfolgreich - per regexp und body_checks abgewehrt.

Ein User bekommt nun ständig dubiose Versicherungs-Spams wie folgenden (anonymisiert):

Liebe Leserinnen und Leser,

Die Private Krankenversicherung steht immer wieder in der Kritik der
Medien. Für eine PKV sprechen jedoch viele Gründe: garantierte
Leistungen, optimale medizinische Versorgung und herausragender Service.

Nutzen Sie Ihre Chance auf einen kostenlosen Vergleich
der wichtigsten Anbieter und Tarife:

http://tarif-verlaengert.spam/info/55/66565-6565-6565-6565-6565

Tipp:

Einen Tarifwechsel sollten Sie in der PKV unbedingt nur innerhalb
des Unternehmens vornehmen. Sonst geht Ihre gesamte, bis dahin
angesparte Alterungsrückstellung verloren, die eigentlich dafür
sorgen soll, dass Ihre Beiträge im Alter nicht davongaloppieren.
Sind Sie allerdings noch jung und gesund und erst seit wenigen
Jahren in der privaten Krankenversicherung, können Sie durchaus
ohne große Verluste einen Unternehmenswechsel in Erwägung ziehen.



Freundliche Grüße von

Janine Spam
Spam Straße 66
58455 Spammerheim



Falls Sie das Abonnement beenden wollen,
können Sie den Versand hier beenden:
http://tarif-verlaengert.spam/unsubscribe/6565/6565-665-6565-6565-6565
Click to expand...

/etc/postfix/body_checks wurde nun um folgende regexp ergänzt:

Code: 
/.*ersicherung[\s\S]*unsubscribe/       REJECT
Zu Deutsch: Wenn eine Mail irgendwo den Wortteil "ersicherung", z.B. "Versicherung" oder "Krankenversicherung" enthält und irgendwann danach ein "unsubscribe" kommt, soll die Mail abgelehnt werden.

Regel-Konflikte existieren nicht, deshalb die Frage:

Wieso mag/respektiert Postfix diese Regel nicht?
...obwohl diverse regex-checker sie als korrekt bestätigen?
...weder mit regexp noch mit pcre.
Hat Postfix ein anderes/beschränktes Repertoire an Ausdrücken und Bedingungen, eine andere regex-Syntax?

Danke vorab für Eure Hilfe!
 
Da regex ist unlogisch.
Code: 
[\s\S]*
Was soll die Klasse denn machen? Mindestens kein Whitespace oder kein Nicht-Whitespace?
Dann kannste gleich
Code: 
.*
nehmen

Code: 
/.*ersicherung.*unsubscribe/       REJECT
 
Hallo Gwen,
danke für Deine Antwort.
Ich bin ein absoluter Regenechsen-Noob und verlasse mich desh. auf die diversen online tools um die Ausdrücke zu checken.
Durch die kam ich auch auf "/.*ersicherung[\s\S]*unsubscribe/".

"/.*ersicherung.*unsubscribe/" findet beim Beispieltext leider keine Treffer, weder mit postmap -q noch mit den online-Tools, vermutlich weil ".*" keine Zeilenumbrüche "\n" frisst?

lg,
Mac
 
wenig hilfreich

Dein Vorschlag einfach ein "s" quasi hintendran zu hängen...
GwenDragon said:
Code: 
/.*ersicherung.*unsubscribe/s
Click to expand...
führt zu:

Code: 
postmap: warning: regexp map /etc/postfix/body_checks, line 474: unknown regexp option "s": skipping this rule

Danke auch für die Links und das implizite RTFM.
Da ich seit meiner Apple ][ Zeit insges. und einschliesslich diesem, 2x "regex-Probleme" hatte, werde ich mir das wohl alles nochmal durchlesen müssen. :p

Aber wenn Du auch nicht weisst, wie man das Problem löst, können wir uns unbesorgt und gemeinsam dem Großteil der Menschheit und vermutlich einem Gutteil der IT-ler anschliessen :)

Peace,
M.
 
Wieso? als pcre map sollte der Modifier s doch erlaubt sein: http://www.postfix.org/pcre_table.5.html

@Mr. Macintosh
Ich schrieb PCRE und nicht regexp. Da gibt es Unterschiede, die auch im postfix man drin stehen.
Ich halte mich raus, du kannst das auch allein lösen mit deinem Apple-Fachwissen. Und raus bin ich weil ich niemals zu jemandem der Hilfe sucht, RTFM sagen würde, was du unterstellst, für mich wäre das respektlos. Und meine Hinweise sind keine implizite Rüge.
 
Last edited by a moderator:
PCRE gibt in der Tat keinen Fehler aus, findet aber auch nicht den Treffer.
Das Problem sind definitiv die Zeilenumbrüche in den (SPAM-)Mails, schau:
Code: 
root@debian:/tmp# postmap -q - regexp:/etc/postfix/body_checks < /tmp/true5.txt
postmap: warning: regexp map /etc/postfix/body_checks, line 473: unknown regexp option "s": skipping this rule
root@debian:/tmp# postmap -q - pcre:/etc/postfix/body_checks < /tmp/true5.txt
root@debian:/tmp#
root@debian:/tmp#
root@debian:/tmp# cat true5.txt
kaufe meine Krankenversicherung 
neue zeile
bla bla bla /unsubscribe/ lalala
root@debian:/tmp# joe true5.txt
File true5.txt saved
root@debian:/tmp# cat true5.txt
kaufe meine Krankenversicherung alles in einer zeile bla bla bla /unsubscribe/
root@debian:/tmp# postmap -q - regexp:/etc/postfix/body_checks < /tmp/true5.txt
postmap: warning: regexp map /etc/postfix/body_checks, line 473: unknown regexp option "s": skipping this rule
kaufe meine Krankenversicherung alles in einer zeile bla bla bla /unsubscribe/ lalala	REJECT
root@debian:/tmp# postmap -q - pcre:/etc/postfix/body_checks < /tmp/true5.txt
kaufe meine Krankenversicherung alles in einer zeile bla bla bla /unsubscribe/ lalala	REJECT.
root@debian:/tmp#
Wenn im Text Umbrüche vorkommen, findet postfix weder mit REGEXP noch PCRE den Treffer, obwohl die Expressions völlig o.k. sind.

Wieso? :confused:

lg,
M.
 
Gwen,
DAS ist die Erklärung, nach der ich gesucht habe.
Danke Dir dafür. Respekt! :)
Damit hat sich die Fragestellung meinerseits erledigt; werde den Thread über die Lösungsvariante via Apache/Spamassassin verfolgen.

Cheerio!

El Mac
 
Ich habe früher bei meiner Antwort übersehen, dass es gar nicht mehr um den regulären Ausdruck den ich dir gab, im Allgemeinen ging.
Da bei Postfixs Handlung einzelner Zeilen des Mailbodys der Regex nicht matchen kann, war mein Hinweis zwar RegEx-technisch richtig, aber nicht in Bezug auf body_checks. :o


Na, dann passt es ja.
 
You must log in or register to reply here.
Back
Top