Antispam Expression bzw. Ausdruck Filter funktioniert nicht

Update:

Ich habe testweise ein paar Mails heruntergeladen, um den kompletten Inhalt incl. Header zu analysieren und konnte z.B. in DKIM-Signaturen fündig werden:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; s=mailing; d=newsletterversand.zeit.de;
h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:X-ulpe:
List-Id:X-CSA-Complaints:List-Unsubscribe:List-Unsubscribe-Post:Feedback-ID;
i=ZEIT-Brief@newsletsterversand.zeit.de;
bh=z3psExyOVCcuOxOEPb0VSWbZG8IDPKe+ZNa+DaDk49w=;
b=Sihjd2TEQcUmGDcbR1CCMEMMm55Um167Xfbqxow26tEbdwrEb66rRX/XDS5jtke+hw0Db7w+r4Ld
goT/CHXQe90eZ3h0Db43N094ISdgj5E91OTRsJu30dcGpugLek4EJNF9Qa5aE2ipDLIqizVj2VjO
DTsK0+nDDtZUL8o0kuc=

Auch in Base64-encoded Inhalten hat er zugeschlagen. Das würde ein paar der Funde erklären.

Bei einer weiteren Stichprobe habe ich auch den Ausdruck in einer URLs festgestellt:

r.newsletter.chateaugrezan-famillecrospujol.com/.../KLKTRR8ccvjr=
aI3VDCbKRyGIY-Rc0vsCFTuPkCg2TWykZsEXrDYUXOmLA4DxjF8ZzSbh1TKw5syK6lrKYlW52PxS=
je7waztnySqw-EV3HaO33ghoB1jfUVGK597YToaBYbteKWHTucW_aSIs0-trd-ad7Bkvh2X4JmM=
0lDubc0jcbt-_v88crWJ3VppbsiOfQS4IzJtHR75a7q2fU0OHIR94eA8BPZZ0DFFk84qqewPafx=
wb1vBStbLf0_m_9Dm3rCwQ7W62xuvPHGHpE_z7E5CslxWWOeNVcIz35wNGq

Wie arbeitet der Expression-Filter genau? Geht er über den kompletten Nachrichtenquelltext und sucht primitiv nach den angegebenen Expressions oder ist er intelligenter und untersucht nur den Nachrichteninhalt (ohne Header, Base64-encoded Bilder, URLs, etc.).

Sofern er den kompletten Quelltext (und nicht wie im Admin-Panel angegeben) den Nachrichteninhalt untersucht, macht es den Filter für kurze Wörter (wie in meinem Falle "Sex") irgendwie unbrauchbar für einfache Ausdrücke - Nach nur 3 Tagen hat er über 20 korrekte Mails rausgefischt.

Kann hier jemand "Licht ins Dunkel" bringen? Gibt es einen eleganten Weg, um den Ausdruck besser zu formulieren (z.B. \bSex) um das Verhalten zu verbessern?

Freue mich auf euer Feedback.
Grüße Thomas

Hallo Thomas,

offensichtlich wird auch der Header geprüft.

Wäre ja auch ungünstig, wenn der im Header befindliche Subject nicht einbezogen würde.

Wenn der Body mit einem "Stichwort" beginnt, könnte u.U. "Stichwort.*sex" dafür sorgen, dass erst ab dem Stichwort gesucht wird ... müsste man testen.

Sonst würde ich in den Suchstring das/die Leerzeichen einbeziehen. " sex "   bzw "\x20sex\x20"  (\x20 müsste ein Leerzeichen darstellen) 

Hallo Dirk,

danke für dein Feedback. 

dirkkotte said:

Wäre ja auch ungünstig, wenn der im Header befindliche Subject nicht einbezogen würde.

..beim Subject bin ich bei dir, aber der komplette Quelltext incl. Signaturen, Server-Header, etc. hätte ich jetzt nicht erwartet. Aber gut, scheint so zu sein, muss man im Konzept beachten.

dirkkotte said:

Wenn der Body mit einem "Stichwort" beginnt, könnte u.U. "Stichwort.*sex" dafür sorgen, dass erst ab dem Stichwort gesucht wird ... müsste man testen.

Mit asterisk (*) hatte ich es noch nicht probiert, aber ich habe mir die regex nochmal durchgeschaut und denke die Lösung müsste sein, über Anchors zu arbeiten.

"\bsex" müsste dann zumindest zur Lösung führen, dass der String "sex" in Signaturen, URLs, usw. nicht mehr matched.

Das macht das ganze zwar etwas umständlicher, da ich gehofft hatte, damit auch "Bi-Sexual", "Homosexual", etc. zu erwischen, aber das scheint dann über einen einfachen Ausdruck nicht zu klappen.

Ich gehe heute nochmal neu ins Rennen mit der folgenden Liste der Ausdrücke:

\bsex
\bbisex
\bbi-sex
\bhomosex
\bhomo-sex

Somit müsste der Ausdrucksfilter einen match haben, wenn die Ausdrücke am Wortanfang vorkommen (das müsste nach meinem Verständnis auch einen Satzanfang einbeziehen).

Exemplarisch müsste "\bsex" nach meinem Verständnis die folgenden Beispiele beinhalten:

Sex
sex
Sexe
sexual content
sexuelle Machenschaften

Aber nicht:

z3psExyO (wie aus dem DKIM oben) und
ykZsEXrD (wie in der URL oben)

Ich probiere das mal aus. Falls jemand eine bereits erarbeitete Liste von "bösen" Ausdrücken hat, nehme ich diese auch gerne als Vorlage 

Grüße Thomas

Halt uns bitte über das Ergebnis auf dem Laufenden ...

Hier mal ein erstes Ergebnis nach knapp 1 Tag.

Die ersten beiden sind mein Test und die oberste ein wirklicher Spam, bei dem der Ausdruck geklappt hatte. Sieht auf den ersten Blick gut aus.

Zum Vergleich - mit dem Ausdruck ohne \b hatte ich innerhalb von 2,5 Tagen bereits über 20 false-positives gehabt.

Das einzige was mich an der Lösung noch stört ist, dass er immer alle Ausdrücke anwendet und dann mehrere matchen (siehe erste Mail von 11:14). Ich schaue mal, ob ich hier noch die Zeit finde, um den Ausdruck in einer großen regex zu formulieren. Das müsste ja relativ einfach klappen.

Update: 

1. Wurf für eine regex:

\b(bi|homo|metro)?-?sex

Laut regex-Tester passt das und hat einen match bei:

SeX
sexual
bi-sexual
homosexual
metro-Sexual
sexual content

..Diese regex werde ich am WE mal einspielen und intensiv testen. Wenn sie passt, werde ich das Pattern als Vorlage für weitere Ausdrücke verwenden.

Update:

Nachdem ich jetzt knapp 2 Wochen mit diesen Ausdrücken im live-Betrieb das Verhalten beobachtet habe, muss ich sagen - ich schalte den Ausdrucksfilter wieder komplett ab.

Das Verhalten, dass er den kompletten Header incl. der Base64-Inhalte der Mail vergleicht, hat das bei unserem Szenario zu vielen false-positives geführt, sodass wichtige Mails ebenfalls in Quarantäne gelandet sind und die Benutzer sich schon beschweren.

Evtl. ist der Filter für längere Ausdrücke geeignet (die Wahrscheinlichkeit einen Treffer zu landen wird ja immer geringer, umso länger der Ausdruck ist), aber gerade im Falle von "Sex" klappt das leider nicht.

So long..

kleiner Nachtrag:

Ich habe heute die false-positives nochmals angeschaut und habe festgestellt, dass das Problem in den regulären Ausdrücken zu finden ist. Hier scheint die UTM die Ausdrücke nicht korrekt auszuwerten. Der Ausdruck:

\bsex

schlägt leider auch zu, wenn das Wort "sex" nicht am Wortanfang steht. Alle Stichproben von heute der false-positives hatten den String "sex" lediglich in base64-Objekten und NICHT am Wortanfang wie in der Doku beschrieben.

Konnte jemand ein ähnliches Verhalten feststellen? Ist das ein Bug in der aktuellen Firmware?

Naja, falls jemand trotzdem nochmal einen Versuch starten möchte, dann kann er mit diesem Ausdruck (Zusammenfassung von oben) ins Rennen gehen:

\b(bi|homo|metro)?-?sex

Freue mich auf Feedback, falls jemand die Zeit/Lust hat, den Ausdrucksfilter zu testen.

kleiner Nachtrag:

Ich habe heute die false-positives nochmals angeschaut und habe festgestellt, dass das Problem in den regulären Ausdrücken zu finden ist. Hier scheint die UTM die Ausdrücke nicht korrekt auszuwerten. Der Ausdruck:

\bsex

schlägt leider auch zu, wenn das Wort "sex" nicht am Wortanfang steht. Alle Stichproben von heute der false-positives hatten den String "sex" lediglich in base64-Objekten und NICHT am Wortanfang wie in der Doku beschrieben.

Konnte jemand ein ähnliches Verhalten feststellen? Ist das ein Bug in der aktuellen Firmware?

Naja, falls jemand trotzdem nochmal einen Versuch starten möchte, dann kann er mit diesem Ausdruck (Zusammenfassung von oben) ins Rennen gehen:

\b(bi|homo|metro)?-?sex

Freue mich auf Feedback, falls jemand die Zeit/Lust hat, den Ausdrucksfilter zu testen.