Plugin-Idee: Bad-Recipient-Filter

Haben Sie eine tolle Idee für eine neue Plugin-Funktion oder ein neues Plugin?

Moderator: Forum-Team

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 17. Okt 2006, 16:46

Hallo, Quellcore!

Danke für die Ideen.

Quellcore hat geschrieben:Benutzung eines Unterordners

Hatte ich mir auch schon überlegt. Andererseits muß man bedenken, daß nicht alle momentan verwendeten Dateien auch Eingang in die finale Version finden werden. badrcpt_log.txt und badrcpt_addresses.txt sind definitiv nur in der Testversion enthalten. Die Ausschlußliste badrcpt_ignore.txt ist eigentlich nur ein schneller Hack gewesen. Für die Zukunft besteht die Möglichkeit, diese Informationen entweder in der spamihilator.ini oder in der Datenbank unterzubringen. "In der Datenbank" meint hier nicht als regulären Datensatz, vielmehr ist das Datenbankformat so ausgelegt, daß auch zusätzliche Daten eingefügt werden können, ohne die bisherige Datenbankfunktionalität zu beeinträchtigen (sorry, aber hier muß ich mir in einer Welt voller Kurzsichtigkeit mal kurz selbst auf die Schulter klopfen ;-)). Außerdem besteht auch hier natürlich prinzipiell die Möglichkeit, daß sich das Format bei einer endgültigen Version nochmal ändert. Soweit dies noch eingebaut wird, kann auch eine "force-list" in bestehende Dateien integriert werden. Am Ende dürften also nur noch die notwendigen Dateien badrcpt.dll und badrcpt.dat im Plugin-Verzeichnis liegen. Und ob dann dort eine Datei badrcpt.dat oder ein Verzeichnis mit nur einer Datei auftaucht, macht ja keinen Unterschied.

Übrigens, die badrcpt.csv gibt's natürlich noch. Die soll in Zukunft aber auch nicht mehr beim Betätigen von "OK" in den Einstellungen sondern über einen separaten Knopfdruck erzeugt werden. Und dann nach Möglickeit an einem benutzerdefinierten Ort.

Quellcore hat geschrieben:Adressen in der Bad-Recipient-Liste, die noch nie in Non-Spam gefunden worden sind, haben trotzdem ein Datum bei 'last good'.

Das ist korrekt. Auch die Annahme, daß es sowohl für weiße wie für schwarze Adressen gilt, stimmt.

Es ist so, daß für jeden Eintrag in der Datenbank, also für jede Adresse, alle vier Felder count good, count bad, last good, last bad existieren. Wurde eine Adresse noch nie als Spam gelernt, muß also trotzdem irgendein Datum unter last bad stehen. Prinzipiell möglich sind hier Werte von 1970 bis 2040 oder so, momentan ist es das Datum des ersten Lernvorgangs für diese Adresse. Dies liegt an der dadurch einfachsten Implementierung, denn was hier steht, ist einfach belanglos. Wenn count good/bad Null ist, interessiert last good/bad nicht.

Hihi, und was ist jetzt der Verbesserungsvorschlag hinsichtlich des "Problems"? :-)
Möglich wäre es natürlich, in der CSV-Datei einfach die Tabellenzelle leer zu lassen.

Quellcore hat geschrieben:Einführung einer badrcpt_force.txt

Hm... Hatte ich auch schonmal überlegt, dann aber wieder verworfen. Was den "Import" von alten Adressen angeht, habe ich mir überlegt, daß man den nicht braucht. Schließlich werden diese Adressen ja entweder gar nicht mehr verwendet und belegen dann unnötigerweise Platz in der Datenbank, oder aber sie werden früher oder später sowieso gelernt. Ich habe ja denselben Hintergrund und habe deshalb einfach den Substring-Filter mit den altbekannten Adressen weiterhin aktiviert und in der Filterreihenfolge hinter den Bad Recipient Filter gesetzt. Für diesen Fall betrachte ich eine "force-list" also nicht als notwendig. Welche anderen Ausnahmesituationen hattest Du denn im Sinn?

Quellcore hat geschrieben:Es macht u.U. Sinn, für die verschiedenen Listen die Priorisierung separat einstellen zu können.

Ja. Ich hatte schonmal die Idee, eine Prioritätenliste à la Spami-Filterreihenfolge zu erstellen, was sicher auch für den Endnutzer am Einfachsten verständlich ist. Hier heißt es meinerseits einfach nochmal nachdenken. Denn auch wenn ich prinzipiell für Einstellmöglichkeiten bin, halte ich wenig davon, Konfigurationen für alles und jedes anzubieten, was a) völlig praxisferne Möglichkeiten bietet und niemals ernsthaft genutzt wird und b) den Nutzer, der nicht unsere komplette Diskussion nachgelesen hat, nur unnötig verwirrt. Sozusagen: So viele Einstellungen wie nötig, aber so wenige Einstellungen wie möglich.


Für mich ist übrigens die momentan dringendste Baustelle die Erkennung von unbekannten, also noch nicht gelernten und nicht in der Ausschlußliste eingetragenen Adressen. Diese sollen dann - per Konfiguration ;-) - als schwarze (Standardeinstellung) oder weiße Adressen angesehen werden. Durch die Standardeinstellung ließe sich so die Wirksamkeit des Filters am Anfang des Einsatzes, also bevor schon eine Datenbank aufgebaut ist, erhöhen. Auch die ganzen schlechten Adressen, die nur ein einziges Mal auftreten, fallen dann nicht mehr durch's Raster. Wer andersherum lieber wieder auf Nummer sicher gehen will, läßt unbekannte Adressen als weiße interpretieren. Und prompt fällt mir auf, daß es dann wohl auch noch eine dritte Möglichkeit geben sollte: Diese Adresse nämlich zu ignorieren, also so wie es momentan Stand der Technik ist. Oder anstatt als weiße wird's als graue Adresse interpretiert, und ob das Ignorieren oder Sicherheitsdenken bedeutet, darüber entscheidet dann die "prioritize ..."-Einstellung. Aiaiai... Sagen wir einfach, der Einstellungs-Dialog wird noch überarbeitet :-)

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 17. Okt 2006, 17:47

Hallo!

Ich habe die Gelegenheit genutzt und mal eine Liste von Verbesserungsideen zusammengestellt. Die Reihenfolge ist nicht in Stein gemeißelt, entspricht aber ungefähr den Prioritäten wie ich sie sehe. Am Ende stehen dann Dinge, die noch sehr unklar sind. In erster Linie ist die Liste für mich gedacht, daher fehlen auch weitere Erklärungen. Vielleicht fühlt sich ja trotzdem jemand davon inspiriert und kann eigene Ideen anfügen.
  • Erkennung unbekannter Adressen in den Empfängerfeldern.
    • Je nach Einstellung Interpretation als schwarze, graue oder weiße Adresse.
  • Ausschlußliste im Konfigurationsdialog komfortabel editieren.
  • Ausschlußliste nicht in badrcpt_ignore.txt sondern entweder in spamihilator.ini oder in badrcpt.dat speichern.
  • CSV-Datei nicht bei "OK" im Einstellungsdialog erzeugen sondern per dediziertem Button.
  • Beim Überprüfen neuer Mails RFC2822-konform Adressen suchen/vergleichen, nicht bloß Substring mit "dot-atext"-Präfix und -Suffix.
  • In Spamis hostlist.xml gucken, ob eines der Felder "user" eine gültige E-Mail-Adresse enthält. Wenn ja, vorschlagen, diese auf die Ausschlußliste zu setzen.
  • Einstellung der Priorisierung verbessern. Bloß wie?
    Ideen: http://www.spamihilator.com/forum/viewt ... 3384#33384
  • Bei CSV-Export Bnutzer Pfad angeben lassen.
  • Datenbank-Editor. Über Konfigurationsdialog oder als separates Programm.
  • Beim Lernen von Mails 100% RFC2822-konform Adressen suchen.
  • Installationsroutine einbauen?
  • Nachsehen, ob überhaupt alle atext-Zeichen aus RFC2822 in einer gültigen E-Mail-Adresse enthalten sein dürfen.
    Hierbei evtl. nicht übermäßig streng vorgehen, falls für lokale Adressen weniger strenge Regeln beachtet werden.
  • Lernen von Adressen auf weitere Header-Fields ausdehen? Bisher werden To, CC, BCC gelernt. Denkbar wäre z.B. noch Received ... for x@y.z. Oder aber es könnten auch Adressen in allen Feldern außer z.B. Message-ID, From, Sender gelernt werden. Siehe dazu http://www.spamihilator.com/forum/viewt ... 2831#32831
  • Bei Adressen nicht zwischen unterschiedlicher Groß-/Kleinschreibung unterscheiden? Per Konfiguration steuerbar?
  • In der Datenbank statt Zeitpunkt des Lernens das Datum der Mail verwenden? Problem 1: Mail-Datum könnte gefälscht sein. Problem 2: Jemand könnte nur alle paar Wochen lernen.
  • Einordung schwarze/graue/weiße Adresse komplizierter (und konfigurierbarer) z.B. nach dem Motto "schwarz, wenn doppelt so oft in Spam wie in Non-Spam und wenn letzter Fund in Non-Spam 3 Monate länger her als letzter Fund in Spam"?
    Ideen: http://www.spamihilator.com/forum/viewt ... 3200#33200
  • Bei mehreren Dateien im Plugin-Verzeichnis Unterordner für Bad Recipient Filter anlegen?
  • Bei CSV-Export last good/bad frei lassen, wenn count good/bad Null ist?
  • "Force-list" einführen?
  • Bei CSV-Export Daten sortieren?

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 18. Okt 2006, 01:52

Hallo Burkart!
Burkart hat geschrieben:Und ob dann dort eine Datei badrcpt.dat oder ein Verzeichnis mit nur einer Datei auftaucht, macht ja keinen Unterschied.

Yep, dann ist alles okay! ;-)
Burkart hat geschrieben:Es ist so, daß für jeden Eintrag in der Datenbank, also für jede Adresse, alle vier Felder count good, count bad, last good, last bad existieren. Wurde eine Adresse noch nie als Spam gelernt, muß also trotzdem irgendein Datum unter last bad stehen. Prinzipiell möglich sind hier Werte von 1970 bis 2040 oder so, momentan ist es das Datum des ersten Lernvorgangs für diese Adresse. Dies liegt an der dadurch einfachsten Implementierung, denn was hier steht, ist einfach belanglos. Wenn count good/bad Null ist, interessiert last good/bad nicht.

Ich hatte bei meinem Einwand an die optionale Bereinigung der Liste gedacht.
Meine Befürchtung war/ist, daß die Bereinung durch dieses Datum nicht mehr so einfach zu lösen ist.
Wahrscheinlich läßt es sich dann aber doch lösen, wenn menn mit UND verknüpfte Abfragen benutzt.
Burkart hat geschrieben:Hihi, und was ist jetzt der Verbesserungsvorschlag hinsichtlich des "Problems"? :-)
Möglich wäre es natürlich, in der CSV-Datei einfach die Tabellenzelle leer zu lassen.

Spontan wäre ich dafür, das Datum einzutragen, daß so weit wie möglich in der Vergangenheit liegt! So ließen sich die Einträge auch sehr einfach identifizieren.
Burkart hat geschrieben:Was den "Import" von alten Adressen angeht, habe ich mir überlegt, daß man den nicht braucht. Schließlich werden diese Adressen ja entweder gar nicht mehr verwendet und belegen dann unnötigerweise Platz in der Datenbank, oder aber sie werden früher oder später sowieso gelernt. Ich habe ja denselben Hintergrund und habe deshalb einfach den Substring-Filter mit den altbekannten Adressen weiterhin aktiviert und in der Filterreihenfolge hinter den Bad Recipient Filter gesetzt. Für diesen Fall betrachte ich eine "force-list" also nicht als notwendig.

Die Benutzung des Substring-Filters für diese Funktion empfinde ich schon als sehr unsauber und ist nur aus der Not heraus entstanden, daß es zum damaligen Zeitpunkt eigentlich nur mit diesem funktionierte. Wahrscheinlich kann Sebastian seit Monaten kaum schlafen, weil wir seinen Filter so mißbrauchen. Die von uns gefundenen Adressen gehören einfach in den Bad-Recipient-Filter und nicht in den Substring-Filter. Natürlich handhabe ich es aber z.Zt. genauso wie Du: Substring-Filter mit den schlechten Adressen direkt nach dem Bad-Recipient-Filter.
Burkart hat geschrieben: Welche anderen Ausnahmesituationen hattest Du denn im Sinn?

Ich habe leider vergessen, meinen Hauptgrund für diese Liste zu erwähnen. Und zwar dachte ich daran, in ferner Zukunft mit 'Regular Expressions' nach schlechten Adressen zu suchen. Diese müssen natürlich manuell eingetragen werden. Nach dem Studium der von Deinem Plugin geschriebenen CSV-Datei könnte man sich ziemlich schnell so eine Regel zusammenstricken.
Burkart hat geschrieben:Ja. Ich hatte schonmal die Idee, eine Prioritätenliste à la Spami-Filterreihenfolge zu erstellen, was sicher auch für den Endnutzer am Einfachsten verständlich ist. Hier heißt es meinerseits einfach nochmal nachdenken... Sozusagen: So viele Einstellungen wie nötig, aber so wenige Einstellungen wie möglich.

Zum jetzigen Zeitpunkt halte ich die Option(en) für Dein Plugin auch für ausreichend.
Als mir dann aber die Idee der force-Liste kam, wollte diese einsame Option dann nicht mehr so richtig zum komplexen Umgang mit 3 verschiedenen Listen passen.

Komme was da wolle, ich werde bestimmt weiterhin die helle Freude mit Deinem Plugin haben!

Gruß
Quellcore
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon anbuva » 18. Okt 2006, 21:10

Quellcore hat geschrieben:Komme was da wolle, ich werde bestimmt weiterhin die helle Freude mit Deinem Plugin haben!



... ich auch :D !

Gruß
anbuva
Benutzeravatar
anbuva
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 8403
Registriert: 1. Sep 2004, 13:58
Wohnort: Zuhause

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 24. Okt 2006, 23:38

Hallo, Quellcore!

Quellcore hat geschrieben:[...] Bereinung der Liste [...]
Wahrscheinlich läßt es sich dann aber doch lösen, wenn man mit UND verknüpfte Abfragen benutzt.


Ja, UND-Verknüpfungen kann so ein Rechner eigentlich ganz gut ;-)

Quellcore hat geschrieben:Spontan wäre ich dafür, das Datum einzutragen, das so weit wie möglich in der Vergangenheit liegt! So ließen sich die Einträge auch sehr einfach identifizieren.


Da bin ich nicht für. Welchen Mehrwert bietet es, wenn dort der 01.01.1970 um Mitternacht steht? Für einzig sinnvoll erachte ich es, beim CSV-Export derartige Daten gar nicht, also in Form eines leeren Tabellenfeldes auszugeben.

Quellcore hat geschrieben:Die von uns gefundenen Adressen gehören einfach in den Bad-Recipient-Filter und nicht in den Substring-Filter.


Stimmt schon. In der Tat findet der umfunktionierte Substring-Filter bei mir in letzter Zeit auch nahezu nichts mehr. Für's Erste bleibt er noch drin, aber bald werde ich ihn entfernen. Hierzu noch ein weiteres Argument: Der Bad Recipient Filter soll ja mittelfristig eine Option zum Bereinigen der Datenbank von alten und wenig vorgekommenen Adressen bieten. Das macht Sinn, weil auch die falschen Adressierungen eine endliche Lebensdauer haben, also vielleicht ein halbes Jahr lang auftreten, danach jedoch nie wieder. Werden sie weiterhin in der Datenbank mitgeschleppt, bringt das also keinen Mehrwert. Analog verhält es sich mit den alten, beim Substring-Filter eingetragenen Adressen. Werden sie in sagen wir den nächsten 3 Monaten nochmal in einer Mail aufgefunden, lernt sie der Bad Recipient Filter. Tauchen sie hingegen nicht mehr auf, brauchen sie auch genausowenig in die Datenbank aufgenommen zu werden. Es mag also Gründe für eine "force-list" geben, die Übernahme der alten Adressen aus dem Substring-Filter ist allerdings kein Grund. Davon abgesehen wäre das doch sehr spezifisch auf unser beider Einzelbedürfnis zugeschnitten.

Quellcore hat geschrieben:Und zwar dachte ich daran, in ferner Zukunft mit 'Regular Expressions' nach schlechten Adressen zu suchen.


Hui! Da müßte ich mich mal nach einer fertigen Bibliothek umsehen. Grundsätzlich sicher eine gute Idee, würde ich sie für's Erste hintanstellen.

Hast Du denn so viele ähnliche schwarze Adressen, daß sich daraus vernünftige reguläre Ausdrücke basteln ließen?

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 25. Okt 2006, 02:18

Hallo Burkart!
  1. Datum in der dat/CSV-Datei
    Ich hatte ja nur 'Angst', daß die Bereinigung der Liste durch dieses Datum nicht mehr so einfach möglich wäre.
    Das scheint ja aber kein Problem zu sein, ist also alles gut wie es ist! ;-)
    Das Feld beim CSV-Export einfach leer zu lassen finde ich ein gute Gute.
  2. Force-Liste
    Ich habe mich bei der ersten Erwähnung dieses Features wohl bewußt schwammig ausgedrückt, da ich Probleme hatte, dieses mit wasserfesten Argumenten als absolutes Muß einzufordern.
    Es sprachen für mich halt viel kleine Ideen dafür, der Filter wäre ohne Force-Liste aber immer noch uneingeschränkt nutzbar.
    Hinzu kam die Annahme, daß der Programmieraufwand ziemlich gering sein könnte, da es sich ja im Prinzip nur um die umgekehrte Version der Ignore-List handelt.
    Das Einfügen meiner manuell gesammelten Adressen in die Force-Liste würde endlich auch zur Folge haben, daß die durch diese Adrssen als Spam klassifizierten Mails dann dem Konto das Bad-Recipient-Filters in der Filterstatistik angerechnet werden. Im Moment hat sich der Substringfilter ja mit unlauteren Mitteln hier einen Vorteil verschafft. ;.)
  3. Regular Expressions
    Das war nur als Ausblick in die Zukunkt gedacht.
    Es kann sehr gerne ganz nach hinten auf Deine Liste, wird evtl. niemals umgesetzt.
    Vielleicht hat Michel ja eine fertige Bibliothek, da er die RegExps ja mittlerweile auch im Spam-Wort-Filter eingebaut hat.
    Mit meiner jetzigen Sammlung an Bad-Recipients könnte ich mir schon 2-3 RegExpressions erstellen.
    Bsp: bekannte Bad-Recipients: quell01(@)bla.bla, quell21(@)bla.bla, etc ...
    Ich kenne niemanden mit solchen Adressen.
    Code: Alles auswählen
    quell[0-9][0-9]@bla.bla

    Das birgt natürlich auch immer die Gefahr von False-Positives, dem Albtraum eines jeden Spami-Users.

Gruß
Quellcore
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 31. Okt 2006, 23:23

Hallo, Quellcore, hallo miteinander!

Vorab ein kleiner Bugreport. Ich habe vorhin in der exportierten CSV-Datei etwas nachsehen wollen und bin über das Datum 31.09.2006 gestolpert. Wie wir wissen, gibt es dieses nicht, entsprechend hat es in der Tabelle nichts zu suchen. Im ersten Moment hatte ich auf einen Fehler in der C-Standardbibliothek getippt, die für das Rechnen mit Daten verantwortlich ist. Nach näherer Untersuchung hat sich rausgestellt, daß die Felder mit Datum 31.09. eigentlich den 31.10. beinhalten müßten. Auch alle anderen Daten scheinen genau mit einem Monat zu früh in der Datenbank (genauer: Deren CSV-Export) zu stehen. An meinem Code habe ich auf den ersten Blick nichts auszusetzen gefunden, somit habe ich wohl entweder das Ergebnis der Standardbibliothek falsch interpretiert (was ich nochmal nachlesen muß) oder aber der Fehler steckt in der Tat dort, wenn auch in anderer Form. Also: Bei Daten im CSV-Export im Geiste einen Monat draufrechnen.

Quellcore hat geschrieben:Hinzu kam die Annahme, daß der Programmieraufwand [für eine force-list] ziemlich gering sein könnte, da es sich ja im Prinzip nur um die umgekehrte Version der Ignore-List handelt.


In der Tat. Nichtsdestoweniger bin ich auch gegen geringen Aufwand, wenn ich keinen oder nur einen sehr geringen Nutzen sehe. Außerdem denke ich auch an Endnutzer, die unsere Diskussion nicht verfolgt haben und die möglichst nur genau so viele Möglichkeiten angeboten kriegen sollen, wie sie auch wirklich brauchen. Hier gehe ich einfach davon aus, daß der Standardnutzer keine Liste mit schwarzen Adressen in der Hinterhand hat ;-)

Quellcore hat geschrieben:Regular Expressions
[...]
Bsp: bekannte Bad-Recipients: quell01(@)bla.bla, quell21(@)bla.bla, etc ...
Ich kenne niemanden mit solchen Adressen.
[...]


Da dürfte dann doch auch die angedachte Erweiterung helfen, daß unbekannte (= noch nicht gelernte und nicht in der ignore-list aufgeführte) Adressen als schwarze Adressen interpretiert werden. Oder ist Dir das zu allgemein/unsicher?

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 2. Nov 2006, 13:53

Hallo Burkart,
Burkart hat geschrieben:Da dürfte dann doch auch die angedachte Erweiterung helfen, daß unbekannte (= noch nicht gelernte und nicht in der ignore-list aufgeführte) Adressen als schwarze Adressen interpretiert werden. Oder ist Dir das zu allgemein/unsicher?

Diese Option ist mir wirklich zu unsicher.
Dann würden ja wahrscheinlich sogar in Vergessenheit geratene Mailinglisten kategorisch aussortiert werden.
Ich plane nachwievor, den Bad-Recipient-Filter weit vorne in der Filter-Reihenfolge zu betreiben, wahrscheinlich direkt hinter den Filtern, die auch Non-Spam erkennen können (Newsletter, Whitestring)!
Andere User werden diese Option, daß unbekannte Adressen als 'schwarze' Adressen interpretiert werden, sicherlich zu schätzen wissen.
Dafür gibt es ja Optionen in Programmen: Anpassungen an die Bedürfnisse des Benutzers ;-)

In diesem Sinne, bis bald!

Gruß
Quellcore
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon michel » 10. Nov 2006, 18:57

Quellcore hat geschrieben:Vielleicht hat Michel ja eine fertige Bibliothek, da er die RegExps ja mittlerweile auch im Spam-Wort-Filter eingebaut hat.

Schau dir mal http://www.boost.org an. Für das Plugin ist das zwar ein bisschen wie mit Kanonen auf Spatzen geschossen, aber diese Bibliothek wird von Spamihilator auch genutzt.

Gruß
Michel Krämer
Chuck Norris doesn't kill Spam. He uses Spamihilator! ;-)
Benutzeravatar
michel
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
Plugin-Programmierer
 
Beiträge: 4327
Registriert: 22. Mär 2003, 02:16
Wohnort: Buseck

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 15. Nov 2006, 21:19

Hallo, Michel!

Danke für den Tip mit Boost, auf den ersten Blick scheint das aber in der Tat eine Nummer zu groß zu sein. Aber sag mal, wenn Spami sowieso eine RegEx-Bibliothek enthält, kann es dann nicht den Plugins einen Service hierfür zur Verfügung stellen? So würde es schließlich für mehrere Filter, z.B. XHeader, einfach möglich, die Funktionalität zu erweitern. Dadurch, daß es den Plugin-Autoren einfacher gemacht wird, RegExes einzusetzen, steigt sicher auch die Motivation, dies zu tun.

Was übrigens die Weiterentwicklung des Bad Recipient Filters angeht, vollzieht sie sich gerade sehr schleppend. Sobald ich wieder ein paar wesentliche Neuerungen aufzuweisen habe, mache ich's bekannt.

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Chactory » 15. Nov 2006, 21:51

Hallo Burkart!

Gute Idee, Burkart. Was den Bad Recipient Filter betrifft, der ist schon sehr ok.

Gruß, Chactory
HilfeTippsAnbuva's FAQBob's FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLSNeu: 1.5.1
Vostro 3450, Intel Core i5 2410M 2,3 GHz, 4 GB DDR3 SDRAM 1333 MHz, Windows 7 Pro 64 Bit SP1

Bild
Benutzeravatar
Chactory
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 9288
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon anbuva » 18. Nov 2006, 22:41

Hallo Chactory, hallo Burkart!

Kleiner Zwischenbericht von meiner Seite:
Bislang verhält sich der Filter bei mir sehr klasse :D . Alle Spams, die er erkennen konnte und damit auch sollte, wurden auch zu 100% erkannt. So soll es sein und so macht es Spaß! Respekt!

Gruß
anbuva
Benutzeravatar
anbuva
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 8403
Registriert: 1. Sep 2004, 13:58
Wohnort: Zuhause

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon michel » 20. Nov 2006, 12:37

Burkart hat geschrieben:Aber sag mal, wenn Spami sowieso eine RegEx-Bibliothek enthält, kann es dann nicht den Plugins einen Service hierfür zur Verfügung stellen?

Ja, das ist sicherlich eine gute Idee. Jedoch könnte ich diese Änderung erst in der nächsten Spamihilator-Version einführen und bis die erscheint, wird es noch ein bisschen dauern.

Das Schwierigste an boost die Installation. Wenn du es einmal auf der Platte hast (1-2 GB), kannst du alle Funktionen nutzen. Die RegEx-Bibliothek ist nur ein paar Kilobyte groß und wird statisch in dein Plugin gelinkt.

Gruß
Michel
Chuck Norris doesn't kill Spam. He uses Spamihilator! ;-)
Benutzeravatar
michel
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
Plugin-Programmierer
 
Beiträge: 4327
Registriert: 22. Mär 2003, 02:16
Wohnort: Buseck

Vorherige

Zurück zu Plugins: Feature Requests

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

 industrious-southeast