Regula Plugin 1.5

  • Version 1.5:
    [+] Empfängeradressen ausgehender Nachrichten können in eine Datei eingetragen werden, die vom Plugin verwaltet wird und bei der Prüfung berücksichtig werden kann. Dazu wurde die interne Regel "SenderInAutoWL" hinzugefügt.
    [+] Im Regeleditor können Zeilen nun verschoben werden.
    [+] Im 2 neue Statistik-Makros (für die Anzahl reklassifizierter Nachrichten) wurden hinzugefügt.
    [*] Die Einstellungen werden jetzt in einer INI-Datei gespeichert. Die bisherigen Einstellungen werden automatisch übernommen.
    [-] Ein Fehler im Regeleditor (Regelverknüpfung mit UND/ODER) wurde behoben.
    [-] Ein Fehler im Regula-Manager (Übersicht / Regel-Statistik) wurde behoben.
    [-] Die Protokolleinfärbung im Regula-Manager wurde nach dem Neuladen des Protokolls nicht richtig dargestellt.
    [-] Einige Fehler in der englischen Sprachdatei wurden behoben.
    [-] Ein Fehler in der Spam-Text-Konvertierung wurde behoben, der zum Versagen der davon abhängigen Regeln (mit einem Fehlereintrag im Protokoll) führte.

    Direktdownload
    Homepage / Beschreibung

  • Zitat

    Ups, man kann den Regelmanager ja garnicht mehr aus den Plugineinstellungen heraus aufrufen :( Warum das denn?


    Hauptsächlich darum, weil man den Regula-Manager nur dann aufrufen sollte, wenn TB! beendet ist. Wenn man einen Eintrag im Startmenü erstellt, kommt man schneller an den Regula-Manager heran, ohne sich mühsam durch die Fenster von TB! zu quälen.

  • Geht gut die neue Version. Danke!

    Man möchte manchmal Kannibale sein, nicht um den oder jenen aufzufressen, sondern um ihn auszukotzen. Johann Nestroy.

  • So, ich bin nun auch auf die aktuelle Version umgestiegen - in der Hoffnung, dass ich K9 irgendwann trotz 99,88% richtiger Entscheidungen in die Tonne werfen kann ...

    Ich kann das Regula noch nicht wirklich beurteilen, aber ich meine ich habe einen "Fehler" entdeckt:

    VariousRules.dat Zeile 113:
    SubjCrippled 80 I "" [SUBJECT_CRIPPLED: Verstümmelter Betreff]

    Die Regel trifft bei mir zu, wenn der Betreff Übersetzung lautet. Kann es sein, dass Umlaute als Sonderzeichen gewertet werden? Ist dies nicht ein Fehler?

    TIA und danke fürs PlugIn!

    Einmal editiert, zuletzt von Teal_One (11. Juli 2005 um 14:43)

  • Zitat

    SubjCrippled 80 I "" [SUBJECT_CRIPPLED: Verstümmelter Betreff]

    Die Regel trifft bei mir zu, wenn der Betreff Übersetzung lautet. Kann es sein, dass Umlaute als Sonderzeichen gewertet werden? Ist dies nicht ein Fehler?


    Ein Fehler? Naja:

    1. Wenn ein Sonderzeichen am Beginn steht, arbeitet die Funktion nicht so, wie sie in der Anleitung beschrieben ist und eigentlich funktionieren sollte. Das ist ein Fehler, der in der nächsten Version behoben sein wird.

    2. Umlaute wurden absichtlich weggelassen, aber da das Plugin vermutlich vermehrt im deutschsprachigen Bereich verwendet wird, könnten die Umlaute auch ignoriert werden. Auch das kommt in der nächsten Version.

    3. Wird keine "Regel" (=Argument) angegeben, reicht ein Wort zur Erfüllung der Regel aus. Du kannst vorerst die Regel auf
    SubjCrippled 80 I "3" [SUBJECT_CRIPPLED: Verstümmelter Betreff]
    umändern, dann ist sie nicht ganz so streng, oder du deaktivierts sie bis die Version 1.6 kommt.

  • Ich habe mir heute mal angesehen was Bayes so alles lernt und dabei gesehen, daß Microsoft Outlook 10 ziemlich viel Müll mit verschickt, was Bayes teilweise lernt.

    Ich habe hier mal eine Liste mit Wörtern, die da so alles drin vorkommen. Werde ich bei mir die Ausnahmeliste mit erweitern, sofern nicht schon vorhanden.

    Gruß,
    Zocko

  • Hallo, ich habe mal probeweise das Regula-Plugin installiert. Macht einen guten Eindruck, obgleich die Regeln in der Voreinstellung derart agressiv sind (hohen Score haben), daß ja beinahe alles, was nicht auf der Whiteliste steht, als SPAM markiert wird. Aber das lässt sich ja nach den persönlichen Wünschen anpassen... :thumbup:

    Die Regel zu den Yahoo-Servern in "Senders.dat" habe ich erweitert, da bei yahoo.fr wohl noch andere Server genutzt werden:

    Code
    & FromAddr 0 R "@yahoo\.(de|com|fr)>" []
    Received 20 RN "\.(mail|scd)\.(ukl|sc5|mud|scd)\.yahoo\.com" [RECEIVED_SENDER_SERVER: Yahoo-Absender ohne Yahoo-Server]

    Dann bleiben bei mir die Häkchen zu "Erweiterte Protokollierung" bei Bayes und bei DNSBL/URLBL nicht drin, so daß keine Details zum Bayes-Part um Protokol steht.

    Zusätzlich suche ich eine Möglichkeit, daß der Dateiname von Anhängen als Kriterium genutzt werden kann. Folgendes habe ich probiert, geht aber anscheinend nicht:

    Code
    ContentType: 50 R "name=.{1,100}\.(exe|pif|com|scr)" [Ausführbarer Anhang]
    
    
    ContentType: 30 R "name=.{1,100}\.\w{2,4}\." [Doppelte Dateiendung]
    
    
    ContentType: 10 R "name=.{1,100}\.(zip)" [ZIP Anhang]

    auch das geht wohl nicht:

    Code
    Content-Disposition: 10 R "name=.{1,100}\.(zip)" [ZIP Anhang]

    Ich habe TB! 3.51 und Win2kSP4
    Danke für Tips!
    Gruß Hendrik

  • Zitat

    Macht einen guten Eindruck, obgleich die Regeln in der Voreinstellung derart agressiv sind (hohen Score haben), daß ja beinahe alles, was nicht auf der Whiteliste steht, als SPAM markiert wird.


    Da jeder andere Spams bekommt ist es nur logisch, dass auch jeder andere Regeln braucht. Die Standard-Regeln dienen vorwiegend als Beispiel.

    Zitat

    Die Regel zu den Yahoo-Servern in "Senders.dat" habe ich erweitert, da bei yahoo.fr wohl noch andere Server genutzt werden:


    Danke, werde ich mir gleich mal ansehen und ggf. ändern.

    Zitat

    Dann bleiben bei mir die Häkchen zu "Erweiterte Protokollierung" bei Bayes und bei DNSBL/URLBL nicht drin, so daß keine Details zum Bayes-Part um Protokol steht.


    Edit: Ich habe den Fehler gefunden. In der nächsten Version funktioniert es wieder korrekt.

    Zitat

    Zusätzlich suche ich eine Möglichkeit, daß der Dateiname von Anhängen als Kriterium genutzt werden kann.


    PartFile 50 R "\.(exe|pif|com|scr)"" [Ausführbarer Anhang]
    geht nicht?

  • Danke, Gaijin, für die rasche Antwort!

    PartFile 50 R "\.(exe|pif|com|scr)"" [Ausführbarer Anhang]

    bringt keinen Treffer, selbst wenn ich sie als allererstes in die Rules.dat schreibe. Die Nachricht, mit der ich getestet habe sieht wie folgt aus (den Anfang vom Header und den Rest vom "encodeten" habe ich weggelassen):


    Wenn Du möchtest, so kann ich Dir gerne mal ein Yahoo.fr-Mail schicken. Dann kannst Du sehen, was denen im Kopf steht... ;)

    Wann gibt es denn die Version mit Logging?

  • Eben habe ich nochmal was komisches bemerkt: in einer Plaintextmail wird beanstandet:
    HTML-Text und Plain-Text-Part unterscheiden sich
    Wie soll was unterschiedlich sein, wenn es garkeinen HTML-Teil gibt...?
    Anbei die eMail, das Log und die Regel

  • Zitat

    Ich habe hier mal eine Liste mit Wörtern, die da so alles drin vorkommen. Werde ich bei mir die Ausnahmeliste mit erweitern, sofern nicht schon vorhanden.


    Du hast Recht. Danke fuer die Muehe.

    Man möchte manchmal Kannibale sein, nicht um den oder jenen aufzufressen, sondern um ihn auszukotzen. Johann Nestroy.

  • Zitat

    PartFile 50 R "\.(exe|pif|com|scr)"" [Ausführbarer Anhang]

    bringt keinen Treffer, selbst wenn ich sie als allererstes in die Rules.dat schreibe.


    Ich habe einen Fehler bei der Verarbeitung der Headerzeilen der einzelnen Message-Parts gefunden. Ich werde demnächst eine Testversion veröffentlichen, in der dieses Problem behoben sein wird.

    Zitat

    Wenn Du möchtest, so kann ich Dir gerne mal ein Yahoo.fr-Mail schicken. Dann kannst Du sehen, was denen im Kopf steht...


    Ja bitte, das wäre nett.

    Zitat

    HTML-Text und Plain-Text-Part unterscheiden sich
    Wie soll was unterschiedlich sein, wenn es garkeinen HTML-Teil gibt...?
    Anbei die eMail, das Log und die Regel


    Die Prüfung sieht so aus, dass vom Plugin der Plain-Text Part ausgelesen wird und dieser mit den Daten von TB! verglichen wird, die auch im Plain-Text-Viewer angezeigt werden. Also bei HTML nur der Text, allerdings bei Nur-Text Nachrichten eben nur der Plaintext. Dabei schein TB! bei der Dekodierung aus der QuotedPrintable-Codierung ab und zu ein Zeichen abzuschneiden. Das kann man auch mit DebugOut oder einfach in TB! und der Quelltextansicht überprüfen (nach "vec la poste" suchen, es sollte eigentlich "avec la poste" angezeigt werden)...
    Den offensichtlichen Fehler in TB! kann ich nicht beheben ;)
    Das Einzige was mir einfällt wäre den Vergleich nur dann durchzuführen, wenn sowohl ein Plain- als auch ein HTML-Part existiert, das wird aber noch etwas dauern.

  • Hallo Gaijin!

    das ist mir noch nie aufgefallen, daß TB da Buchstaben versiebt... wenn ich ein bisschen Zeit finde, mache ich einen Report in der Betaliste...

    Bezüglich exe|com|pif und Protokollierung mache ich einen Test und melde zurück

    eMail schicke ich raus an Dir, von yahoo.de und Yahoo.fr Beide werden als Text "31415926535" enthalten, damit Du sie im Spamordner wiederfindest.... :ja:

  • Die Regel in BadTLDs.dat indet nicht nur .jp-Domains, sondern auch jpg-Bilder. Ich habe dann mal die Regel abgeändert auf:

    UrlList 10 R ".jp\W" [TEXT_SPAM_LNK: ".JP"-Domain in Link]

    eigentlich sollte dann ja jpg nichtmehr gefunden werden. Nach einer Domain kann ja nicht direkt ein Buchstabe oder Unterstrich stehen.