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.
Regula Plugin 1.5
-
Gaijin -
8. Juli 2005 um 15:49 -
Erledigt
-
-
Ups, man kann den Regelmanager ja garnicht mehr aus den Plugineinstellungen heraus aufrufen Warum das denn?
-
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. -
Ahh, jetzt bin auch schlauer, hatte auch beim geöffneten TB den Manager vermißt.
-
Geht gut die neue Version. Danke!
-
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!
-
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ß,
ZockoCode
Alles anzeigenBreakWrappedTables BrowserLevel Compatibility DocumentKind DoNotRelyOnCSS EmailFormatvorlage endif EnvelopeVis font-family font-size GrammarState HyphenationZone margin margin-bottom mso-ansi-font-size mso-ascii-font-family mso-bidi-font-size mso-fareast-font-family mso-footer-margin mso-header-margin MsoHyperlink MsoHyperlinkFollowed MsoNormal MsoNormalTable mso-padding-alt mso-pagination mso-para-margin mso-para-margin-bottom mso-style-name mso-style-noshow mso-style-parent mso-style-type mso-tstyle-colband-size mso-tstyle-rowband-size OfficeDocumentSettings personal-compose REC-html40 schemas-microsoft-com SnapToGridInCell SpellE SpellingState text-decoration text-underline UseAsianBreakRules visited widow-orphan windowtext WordDocument WrapTextWithPunct xmlns
-
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...
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:
CodeContentType: 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:
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.ZitatDie 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.ZitatDann 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.ZitatZusä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):
Code
Alles anzeigenSubject: Komm 1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------8A164182268E32B1" ------------8A164182268E32B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Komm ------------8A164182268E32B1 Content-Type: application/octet-stream; name="Copie de Addi.com" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="Copie de Addi.com" TmV1a2FsZWRvbmllbiBUZWwvRmF4IDAwNjg3IDQxIDEyIDEyDQpIYW5keSBVbGkgICAgICAg ICAgICAgMDA2ODcgODcgMzUgMDUNCkhhbmR5IEhlbmsgICAgICAgICAgICAwMDY4NyA4NSA0 NSA1Ng0KV0VCLkRFIEZyZWVQaG9uZTogICAgIDAyMjIyIDk0OCAxMjM4Njggb2RlciBhdWNo
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. -
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.ZitatWenn 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.ZitatHTML-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. -
Ich habe eine TESTVERSION des Regula-Plugins hochgeladen. Darin wurden unter anderem die oben beschriebenen Fehler korrigiert.
Weiters habe ich die von Zocko geposteten Ausnahmen für die Bayes-Filterung aufgenommen. Vielen Dank dafür, Zocko!
-
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:
-
Besten Dank, Hendrik. :ja:
-
BayesLogging
exe|com|pif
geht denn bei Dir die Regel, die Du vorgeschlagen hast? :denk:
-
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.
-