Ist Regula noch nutzbar?

  • Ich bin quasi ein Spätberufener... Ich habe die Tage von einer Bayes-Lösung auf Regula umgestellt. Ich finde, es ist an sich ein tolles Programm. Nachdem ich die Hälfte der Beispielregeln geprüft und teilweise optimiert hatte, musste ich jetzt zu meinem Entsetzen feststellen, dass Regula offensichtlich eine Reihe gravierender Fehler besitzt – die eine sinnvolle Nutzung zunichte machen. Siehe exemplarisch den beiliegenden Log-Auszug... Die (dekodierten) Strings sind fehlerhaft bzw. stimmen nicht (mehr), sodass Regula "Muster" nicht erkennt und eine effektive Spam-Filterung mehr oder weniger unmöglich wird.

    Meine Frage: Ist (das betagte) Regula heutzutage überhaupt noch nutzbar? Ich frage insbesondere vor dem Hintergrund, dass mit The Bat v8 ja etwas an der Kodierung geändert wurde und beispielsweise Gaijns Extended Macro Plugin (XMP) aufgrund der geänderten Kodierung in Teilen nicht mehr (richtig) funktioniert. Ist dieses bei Regula möglicherweise auch der Fall? Ich vermute, auch Regula wird kein UTF-8 können, obwohl der Text-String richtig dekodiert ist.

    Hat jemand irgendwelche Erfahrungen? Für einen Hinweis wäre ich dankbar!


    Meine Testmail:
    Betreff: "Schöne Väter (es stehen fünf Leerzeichen vor der Klammer)"
    Text: "Lieber Jörg, dieses ist ein Test mit Sonderzeichen (äöü_%€)!"


    === BEGIN MESSAGE at 23.07.2019 13:36:40 ===
    Subject: Schöne Väter (es stehen fünf Leerzeichen vor der Kl ammer)
    Sender: "xy.de" <xy@xy.de>
    Date: Tue, 23 Jul 2019 13:36:34 +0200
    Msg-Id: <xy@xy.de>

    Debug output for header "Subject":
    BEGIN>Schöne Väter (es stehen fünf Leerzeichen vor der Kl ammer)<END.

    Debug output for header "RawSubject":
    BEGIN>=?utf-8?Q?Sch=C3=B6ne_V=C3=A4ter_____=28es_stehen_f=C3=BCnf_Leerzeichen_vor_der_Kl?= =?utf-8?Q?ammer=29?=<END.

    Debug output for header "SpamSubj":
    BEGIN> scha¶ne va¤ier es siehen fa¼nf ierzeichen vor der ki amer <END.

    Debug output for header "SpamSubjText":
    BEGIN> scha¶ne va¤ier es siehen fa¼nf ierzeichen vor der ki amer iieber jorg dieses isi ein iesi mii sonderzeichen aou¬i <END.

    Debug output for header "Text":
    BEGIN>Lieber Jörg, dieses ist ein Test mit Sonderzeichen (äöü_%¬)!

    <END.
    Match: Intern rule "SubjCrippled" (SUBJECT_SUBJ_SPECIAL_CHARACTERS: Special characters between letters), score: 5.
    Bayes result: 36% spam probability.
    Match: Intern rule "BayesScore" (RULES_BAYES), score: -28.
    Final score is: xy (xy), 3 rules matched >>> HAM.
    Message processed in 30 mSec.

  • Regula funktioniert nur bis 7.x, weil später Ritlabs The Bat! von Windows-Kodierung auf Mehrbyte-Unicode umgestellt wurde.

    Solange keine Umlaute drin sind, geht es aber auch noch.
    Kommt eben auf deine Regeln an.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Regula funktioniert nur bis 7.x, weil später Ritlabs The Bat! von Windows-Kodierung auf Mehrbyte-Unicode umgestellt wurde.

    Solange keine Umlaute drin sind, geht es aber auch noch.
    Kommt eben auf deine Regeln an.

    Besten Dank für den Hinweis. Ist das ägerlich... Ich habe bereits die Häfte der Regeln geprüft und optimiert und somit Stunden - um nicht zu sagen: Tage - investiert.

    Das mit den Umlauten ist wahrscheinlich keine Lösung, denn Spammer werden darauf keine Rücksicht nehmen. Beispielsweise braucht nur ein "zusätzliches" Sonderzeichen im Subject eingebaut werden, und schon ist Regula nutzlos.

    Gwen, ich sehe gerade, du nutzt noch Regula. Wie machst du das denn mit dem Filtern?

  • Warum muss du in Regula denn nach Umlauten filtern?

    Ich filtere mit Regula nur nach Mailadressen und bestimmten Worten, die haben aber keine Umlaute.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Zwischenfazit... Ein Erfahrungsbericht für alle, die mit dem Gedanken spielen, Regula im Jahr 2019 zu nutzen... Vorab: Regula ist ein wirklich tolles Programm, wenn man mit Regulären Ausdrücken umgehen kann und bereit ist, sich mit Spam-Filterung zu beschäftigen. Allerdings ist Regula im Jahr 2019 nur noch bedingt nutzbar, weil einiges einfach nicht (mehr) funktioniert.

    Hintergrund: Ich habe die letzte Version von Regula mit allen Muster-Rule-Sets installiert. Anschließend habe ich die (neueren) Muster-Rule-Sets aus Phalanx genommen, diese mit denen von Regula abgeglichen und ggf. für Regula angepasst. Dann bin ich die Regeln einzeln durchgegangen und beim Prüfen ist mir einiges aufgefallen.

    Zum einen gibt vier, fünf Dinge, bei denen Regula einfach einen Fehler hat (beispielsweise funktioniert "SubjMultiSpace" und "RawSubject" nicht, da der Header-String nicht korrekt ist). Zum anderen gibt es Muster-Regeln, die nicht oder fehlerhaft funktionieren. Und dann gibt es das große Problem mit der von The Bat eingeführten UTF-8-Kodierung, die Regula nicht beherrscht.

    Der Hinweis von Gwen, sich bei der Filterung ggf. auf Mailadressen und Worte ohne Umlaute zu beschränken ist wertvoll und wichtig. Allerdings beraubt man sich dann der ganzen Funktionen und tollen Möglichkeiten von Regula. Das Problem ist unter anderem, dass man natürlich nur nach Wörtern ohne Umlaute suchen/filtern kann. Sollte aber im zu durchsuchenden Text/String ein Umlaut vorkommen, so werden mitunter die eigenen Regeln ausgehebelt. Im nachfolgenden Beispiel würde bei UTF-8 zwar "VaterMutterKind", aber nicht "VäterMütterKinder" gefunden:
    Subject 25 R "(?-i)\b([A-Z]{1,2}[a-zäü]+){3}\b" [Subject contains 3 words without a space]
    Das Problem kann man natürlich abmildern, indem man für "ä" und "ü" die UTF-8-Kodierungszeichen" in die Regel integriert:
    Subject 25 R "(?-i)\b([A-Z]{1,2}[a-zäüä¼]+){3}\b" [Subject contains 3 words without a space]
    Der Nachteil der Sache ist offensichtlich: Man müsste (immer) alle einschlägigen Regeln anpassen.

    Und was mir im Zusammenhang mit UTF-8-Kodierung auch noch aufgefallen ist, etwas ganz Unschönes: "SpamXY" (wie SpamSubj, SpamSubjText, SpamText) ist nicht nutzbar, da defekt. Im Debug-Modus sieht man, dass der String fehlerhaft ist. Ob "SpamXY" möglicherweise bei anderen Kodierungen richtig arbeitet, habe ich nicht getestet. Es ist auch egal, denn ich kann von Spammern nicht verlangen, dass sie mir Mails in mir genehmer Form schicken.

    Mittlerweile habe ich gut die Hälfte der Muster-Regeln durchgearbeitet. Ich werde sicherlich weiterhin fehlerhafte Regeln und Programmfehlerchen finden. Wer Regula heutzutage nutzen will, muss Zeit mitbringen bzw. sollte alle verwendeten Regeln einmal ausprobieren. Manche Probleme lassen sich mit Regulären Ausdrücken gut umschiffen. Inwieweit sich der ganze Aufwand lohnt und ob ein aktuelles Filterprogramm nicht die bessere Lösung ist, muss natürlich jeder für sich entscheiden.

  • Als reine b/w-Liste mit DNSBL-/URIBL-Abfragen, die wohl immer noch funktionieren, ist das Plugin immer noch ideal. Auf das ganze Bayes-Zeugs etc. kann man auch verzichten. Das ist auch der Hauptvorteil von Regula, dass man die Filtertechniken selbst bestimmen kann.

    Der Hauptnachteil ist IMO hingegen nicht etwa, dass bestimmte Techniken nicht (mehr) unterstützt werden, sondern dass x64 nicht unterstützt wird. Da immer mehr Nutzer auf die 64-Bit Umgebung inklusive Programmen wechseln, wird es höchstwahrscheinlich bald gar keine 32-Bit TB!-Version mehr geben. Jedenfalls können solche Nutzer das Plugin bereits jetzt nicht einsetzen. Daher hat es vor allem aus diesem Grund an Bedeutung verloren.

  • @sanyok

    Da hast du absolut recht. Ich denke, die Möglichkeiten, die einem Regula bietet, sind klasse. DNSBL-/URIBL-Abfragen oder Bayes brauche ich auch nicht. Die Verknüpfung von Regeln, das ist das Interessante für mich. Ein Spammer will bzw. muss mir ja irgendeine Botschaft/Textpassage schicken. Und wenn er nicht in meinem Adressbuch steht, wird er es schwer haben, an meinen Regeln vorbeizukommen...

    Und was die Zukunft von Regula und der 32-Bit-TB-Version oder The Bat im Allgemeinen betrifft, sieht die Zukunft düster aus. Ich habe mir letztens noch mal die alten Beiträge zu "Die Zukunft des Forums" durchgelesen, worin ja u.a. auch die Entwicklung von The Bat thematisiert wird. Und wenn man ehrlich ist, ist es nur eine Frage der Zeit, bis man auf der Ritlabs-Webseite den Hinweis finden wird, dass die Entwicklung (mangels Nachfrage) eingestellt wurde. Ich glaube nicht, dass noch großartig Neukunden gewonnen werden. Und die Altkunden/-nutzer springen nach und nach, peu à peu ab (Stichwort: Webmailer bzw. Apps). Wenn ich mir die letzten gut 20 Jahre anschaue, glaube ich auch irgendwie nicht, dass unsere postsozialistischen Freunde in Moldawien wissen, wie man wirklich professionell arbeitet und zudem ein Produkt erfolgreich vermarktet, nämlich nutzen- und kundenorientiert. Beispielsweise so etwas wie die von L.Willms wiederholt und absolut zu Recht beanstandeten Blockquote-Probleme dürfen einfach nicht sein... Aber in der neuen v9 wieder am GUI herumspielen, das ist wichtig.

    Wie gesagt, die Zukunft sieht düster aus und es ist nur eine Frage der Zeit... Ich selbst weiß auch nicht, wie lange ich noch dabei bin. Windows 10 werde ich mir definitiv nicht antun. Aber irgendwie hoffe ich, dass The Bat auf Linux so gut läuft, wie einem Sotels Erfahrungsberichte glauben machen.

  • Aber irgendwie hoffe ich, dass The Bat auf Linux so gut läuft, wie einem Sotels Erfahrungsberichte glauben machen.

    Es gibt einen neuen Bericht von ihm hier mit dem Fazit:

    Zitat von sotel

    Also, wer plant, von Windows weg zu migrieren, sollte das beruhigt tun - die Fledermaus ist ein treuer Wegbegleiter!

  • Bei mir läuft mit The Bat! 10.x Regula immer noch für meine POP3-Konten.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.