Plugin-Idee: Bad-Recipient-Filter

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

Moderator: Forum-Team

Re: Subject filtern?

Beitragvon Quellcore » 12. Sep 2006, 15:05

Hallo Burkart,
Burkart hat geschrieben:Zum Einen ist das legitimerweise meine eigene, z.B. "Newsletter xy an foo@bar" oder "web.de Spam-Report für dingsbums@web.de"

Dafür gibt es ja eigentlich den Newsletter-Filter, der in der Filterreihenfolge sowieso weit nach vorne an die Spamfront gehört.
Der Hauptgrund für den Einsatz dieses Newsletter-Filters besteht für mich darin, daß man bestimmte Mails mit wierkehrenden Subject-Zeilen/Mailinglist-Adressen durchlassen kann, OHNE von diesen zu lernen zu lassen.
Das Lernen von Newslettern halte ich persönlich für nicht sinnvoll, eigentlich sogar für kontraproduktiv.
Michel hat aus diesem Grunde ja die Option eingebaut, von diesen Mails nicht zu lernen.
Burkart hat geschrieben:Außerdem ist das manchmal bei Spam-Mails der Fall, z.B. enthält das Subject dann ausschließlich meine korrekte Adresse.

So eine Spammail habe ich 'leider' bis jetzt noch nicht erhalten. ;-)

Meine (sehr theoretischen) Überlegungen dazu sehen folgendermaßen aus:
Es handelt sich dann um eine personalisierte Spam-Mail. Ich kann mir nicht vorstellen, daß so eine Nachricht dann aber an andere Mailadressen als der Deinen (=die, die im Betreff steht) gerichtet ist. Falls dem so sein sollte, kann Dein Filter diese Mail sowieso nicht als Spam klassifizieren, da ja nur Deine eigene Adresse vorkommt.
Falls dem nicht so sein sollte, müßte ich ich noch einmal drüber nachdenken.
Burkart hat geschrieben:Die Frage ist jetzt, ob das Subject genau wie alle anderen Header-Felder in die Suche nach bekannten Adressen einbezogen werden sollte oder nicht. Ich selbst bin mir da sehr unschlüssig.

Aus den o.g. Gründen macht es imho keinen Sinn, die Suche auf die Betreffzeile auszuweiten.
Evtl. kannst Du Dir so eine Mail noch einmal genauer anschauen, ob dann der Empfänger auch immer nur die Adresse aus der Betreffzeile ist.

Grüße,
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: Subject filtern?

Beitragvon Burkart » 14. Sep 2006, 19:49

Hallo, Quellcore!

Du hast natürlich recht, was das Newsletter-Plugin angeht und auch mit Deinen theoretischen Überlegungen zu meiner Adresse im Subject. In der Tat kam übrigens im Header dieser Mail (außer dem Absender) keine weitere Adresse vor, der Bad Recipient Filter hätte also nichts ausrichten können.

Ich bin jetzt soweit, daß ich alle Felder filtern werde. Du hattest ja schon gesagt, daß "böse" Adressen auch in Feldern vorkommen können, wo man sie auf den ersten Blick nicht vermutet. Trotzdem ist es dann Spam. Warum also das Subject nicht auch mit filtern? Erstmal für alle Fälle und wenn dort doch nichts gefunden wird, ist's auch nicht weiter schlimm.

Sollten wir doch noch dazu übergehen wollen, gewisse Felder von der Filterung auszuschließen, ließe sich das leicht einbauen. Seitens des Programmieraufwandes sind beide Möglichkeiten pipifax. Und beim Lernen bleibt es dabei, daß nicht alle Felder berücksichtigt werden. Ob dabei entweder nur einige Felder (To, CC, BCC) zum Lernen herangezogen werden oder alle bis auf ausgewählte Felder (Message-ID, From, Sender) berücksichtigt werden, muß sich dann noch zeigen. Programmiertechnisch hält sich wieder beides die Waage und der erste Ansatz war Richtung Nur-To-CC-BCC-Lernen.

Es geht übrigens weiterhin gemächlich voran. Als Nächstes mache ich mich ans Lernen. Kann allerdings sein, daß ich nochmal für ne Woche nicht zum Programmieren komme.

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

Re: Subject filtern?

Beitragvon Quellcore » 15. Sep 2006, 00:24

Moinsen Burkart,
Burkart hat geschrieben:Warum also das Subject nicht auch mit filtern? Erstmal für alle Fälle und wenn dort doch nichts gefunden wird, ist's auch nicht weiter schlimm.

Es sollte die Funktion des Filters wohl nicht beeinträchtigen, meinen Segen hast Du :!:
Burkart hat geschrieben:Ob dabei entweder nur einige Felder (To, CC, BCC) zum Lernen herangezogen werden oder alle bis auf ausgewählte Felder (Message-ID, From, Sender) berücksichtigt werden, muß sich dann noch zeigen. Programmiertechnisch hält sich wieder beides die Waage und der erste Ansatz war Richtung Nur-To-CC-BCC-Lernen.

Ich wäre auf jeden Fall auch nur für die Empfängerfelder (To, CC, BCC) beim Lernen. Mails, die die schlechten Adressen (auch noch) woanders im Header haben, sind prozentual gesehen ja wohl eher die Exoten.
Es macht den Filter auch ein Stück sicherer, nur von schlechten Empfängeradressen zu lernen:
Eine schlechte Adresse muß erst einmal in den Empfängerfeldern (To, CC, BCC) auftauchen, um überhaupt als schlechte Adresse gewertet zu werden. Das klingt doch eigentlich perfekt! Ansonsten müßten wir uns ja auch noch einen anderen Namen für den Filter ausdenken, wenn er vom gesamten Header lernt. ;-)
Burkart hat geschrieben:Es geht übrigens weiterhin gemächlich voran. Als Nächstes mache ich mich ans Lernen. Kann allerdings sein, daß ich nochmal für ne Woche nicht zum Programmieren komme.

Nur die Ruhe, ich gönne Dir Deine Programmierpause von ganzem Herzen.
Du hast ja schon einiges bewegt. Bis bald!

Greetings
Qullcore
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 Chactory » 15. Sep 2006, 11:52

(Interessanter Thread! Bin schon sehr neugierig! C.)
HilfeChactorys TippsAnbuvas FAQBob Loefflers FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLS
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: 9266
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 3. Okt 2006, 03:13

Hallo, Leute!

Nachdem mal wieder ein paar Probleme aus dem Weg geräumt sind und das Licht am Ende des Tunnels immer größer wird, will ich kurz den aktuellen Stand bekanntgeben. Die zwei zentralen Funktionen sind fertig: Es wird sowohl der Header auf bekannte Adressen hin untersucht und daraus eine Entscheidung Spam oder nicht zuzuordnen abgeleitet als auch beim Lernprozeß im Trainingsbereich nach Adressen in den drei Feldern To:, CC: und BCC: gesucht. Diese Adressen werden bisher nur in eine Logdatei geschrieben, während die Suche nach guten und bösen Adressen auf ein paar wenigen fest einprogrammierten Adressen beruht. Als Bindeglied fehlt somit noch die Datenbank selbst. Außerdem gibt es einen Konfigurations-Dialog, in dem zur Wahl steht, ob man lieber sicherheitsorientiert (eine gute Adresse reicht aus, um die Mail mit unbekannter Einschätzung weiterzureichen) oder normal (eine böse Adresse reicht aus, um die Mail als Spam zu klassifizieren) filtern will. Wahrscheinlich reicht das an Einstellmöglichkeiten, andernfalls müßte ich das später nochmal erweitern. Eine weitere Schludrigkeit habe ich mir bei der Suche nach Adressen während des Lernvorgangs erlaubt. Normale Adressen werden problemlos gefunden, auf alle Spezialfälle aus der RFC2822 bin ich nicht eingegangen. Hier muß die Erprobungsphase zeigen, ob sich der Aufwand für Mails wie z.B. in Kapitel A.5 lohnt. Ohne hier jetzt ein konkretes Datum zu nennen, hoffe ich, die offizielle Testphase bald einläuten zu können.

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 » 3. Okt 2006, 15:20

Hallo Burkart und alle!

Vielen Dank für Deinen Zwischenbericht!

Burkart hat geschrieben:Es wird sowohl der Header auf bekannte Adressen hin untersucht und daraus eine Entscheidung Spam oder nicht zuzuordnen abgeleitet als auch beim Lernprozeß im Trainingsbereich nach Adressen in den drei Feldern To:, CC: und BCC: gesucht.
Das finde ich ein hervorragendes Vorgehen. Würde ich es sich lohnen, auch den Papierkorb mitzudurchsuchen (bei mir enthält der Trainingsbereich immer nur wenige aktuelle Mails)?
Burkart hat geschrieben:Ohne hier jetzt ein konkretes Datum zu nennen, hoffe ich, die offizielle Testphase bald einläuten zu können.
:-D

Gruß, Chactory
HilfeChactorys TippsAnbuvas FAQBob Loefflers FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLS
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: 9266
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 3. Okt 2006, 23:47

Hallo, Chactory!

Chactory hat geschrieben:Würde ich es sich lohnen, auch den Papierkorb mitzudurchsuchen (bei mir enthält der Trainingsbereich immer nur wenige aktuelle Mails)?


Ich verstehe noch nicht genau, was Du meinst. Vorgesehen ist, den Bad Recipient Filter lernen zu lassen, wenn im Trainingsbereich auf Lernen geklickt wird. Betroffen sind somit alle im Trainingsbereich markierten Mails. Was im Papierkorb ist, interessiert dabei nicht. Letztendlich sind es aber doch die gleichen Mails, die auch schon im Trainingsbereich als Spam stehen. Würde man die Mails aus dem Papierkorb mitlernen, würden diese schlechten Mails also doppelt gelernt werden. Solange der Papierkorb nicht geleert wird, werden sie sogar immer und immer wieder gelernt. Dies dürfte die Datenbank also deutlich verfälschen. Falsche Zuordnungen (gute Mails im Papierkorb) wären außerdem ein Problem.

Davon abgesehen ist es technisch sicher machbar, auch Nachrichten aus dem Papierkorb (dann als Spam) zu lernen. Die einzelnen dort gespeicherten Mails liegen ja im Spami-Unterverzeichnis recycle. Diese Dateien müßten lediglich eingelesen und an die Lernfunktion übergeben werden.

Wenn es jetzt nur darum geht, die Datenbank schnell (und einmalig) mit ein paar Adressen zu füttern, die aus alten Mails kommen, hilft sicher der Virtual POP3 Server weiter.

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 » 4. Okt 2006, 00:31

Hi Burkart,

Burkart hat geschrieben:Vorgesehen ist, den Bad Recipient Filter lernen zu lassen, wenn im Trainingsbereich auf Lernen geklickt wird
vielen Dank für Deinen Hinweis! Du hast natürlich völlig Recht! Sorry, da hatte sich bei mir ein Denkfehler eingeschlichen. :oops:

Gruß, Chactory
HilfeChactorys TippsAnbuvas FAQBob Loefflers FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLS
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: 9266
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 5. Okt 2006, 21:25

Burkart hat geschrieben:Ohne hier jetzt ein konkretes Datum zu nennen, hoffe ich, die offizielle Testphase bald einläuten zu können.

Ja, ist denn heut schon Weihnachten :!: :?: :D

'Daumen Hoch' für deine bis jetzt gezeiften Pogrammierleistungen.
bis bald
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

Feddisch!

Beitragvon Burkart » 6. Okt 2006, 01:20

Moinsen!

Es ist soweit, die Testphase kann beginnen!

Interessierte laden sich bitte unter http://www.bollchen.de/media/badrcpt.dll das Plugin in der Version 0.1.0.246 herunter und speichern die DLL-Datei im Plugin-Unterverzeichnis von Spami, also z.B. C:\Programme\Spamihilator\plugins\ <- badrcpt.dll. Anschließend bei Spami die Einstellungen aufrufen und dort bei Filter-Eigenschaften -> Plugins gegebenenfalls auf Neu Laden klicken, wenn der Bad Recipient Filter noch nicht angezeigt wird. Jetzt ein Häkchen vor den Namen machen und Übernehmen wählen. Jetzt kann das Plugin noch unter Filter-Eigeschaften -> Reihenfolge möglichst weit nach vorne gesetzt werden. Oder auch nicht, jeder wie's ihm gefällt. Wenn der Filter eine Spam-Mail findet, sollte der Filter-Prozess beendet werden. Die entsprechende Einstellung für Non-Spam-Mails ist irrelevant, da dieses Plugin ausschließlich Spam-Mails entdeckt. Findet es nichts, werden die Mails mit unbekannter Einstufung durchgelassen. Zur Sicherheit würde ich jetzt nochmal Spami beenden und neustarten.

Ist das Plugin eingebunden, erzeugt es nach und nach im Plugin-Verzeichnis einige Dateien:

  • badrcpt.dat - Die Datenbank mit allen gelernten Adressen
  • badrcpt.csv - Die Datenbank im CSV-Format zum Betrachten per Tabellenkalkulation
  • badrcpt_addresses.txt - Eine Liste aller gelernten Adressen
  • badrcpt_log.txt - Alle Zeilen überprüfter Mails, die ein @ enthalten

Bevor es in's Detail geht noch ein paar Worte zur grundsätzlichen Funktionsweise des Plugins. Es geht darum, "falsche" Empfängeradressen, also solche in den Feldern "To:", "CC:" und "BCC:" zu finden. Diese Adressen sind erfahrungsgemäß ein sicheres Kriterium dafür, daß eine Mail Spam ist. Gleichzeitig ist es möglich, Mails mit einer guten (i.d.R. der eigenen) Adresse nicht als Spam zu behandeln, selbst wenn zusätzlich schlechte Adressen enthalten sind. Um überhaupt eine Entscheidung fällen zu können, ob eine Adresse gut oder schlecht ist, baut das Plugin nach und nach eine Datenbank auf. Immer wenn im Trainingsbereich gelernt wird, klinkt sich der Bad Recipient Filter in den Lernvorgang ein und sucht in den drei genannten Feldern der Mail nach Adressen. Je nachdem ob eine Mail als Spam oder Non-Spam gelernt wird, wird in der Datenbank vermerkt, ob die gefundenen Adressen gut oder schlecht sind. Einige Adressen werden ausschließlich in Spam-Mails vorkommen, die eigene Adresse wird normalerweise sowohl in Spam- als auch in Non-Spam-Mails auftauchen. Ganz Glückliche haben vielleicht eine Adresse, die ausschließlich in guten Mails enthalten ist. Zusätzlich wird in der Datenbank übrigens gespeichert, wann eine Adresse das letzte mal in einer Spam- und wann in einer Non-Spam-Mail aufgetaucht ist. Diese Information wird allerdings noch nicht ausgewertet.

Wenn jetzt eine neue Mail eintrifft und dem Filter zur Beurteilung vorgelegt wird, kann dieser hoffentlich bereits auf eine Datenbank mit etlichen Einträgen zurückgreifen. Sämtliche Einträge werden nun der Reihe nach durchgegangen und es wird geprüft, ob sie in der neuen Mail enthalten sind. Hierbei werden übrigens nicht nur die drei Empfängerfelder durchsucht sondern der gesamte Mail-Header. Die Fünde werden dahingehend einsortiert, ob es sich gemäß Datenbank um eine gute oder eine schlechte Adresse handelt. Adressen, die sowohl in guten als auch in schlechten Mails gefunden wurden, werden hierbei nicht mitgezählt. Werden nun eine oder mehrere schlechter Adressen gefunden, jedoch keine einzige gute, handelt es sich gemäß Bad Recipient Filter eindeutig um eine Spam-Mail. Werden ausschließlich gute Adressen gefunden, ist von einer guten Mail auszugehen; sie wird trotzdem zur weiteren Überprüfung ans nächste Plugin weitergereicht. Knifflig wird es, wenn sowohl gute als auch schlechte Adressen auftreten. Ob diese Mail als Spam aussortiert oder an den nächsten Filter weitergereicht werden soll, ist konfigurierbar.

Und mit dieser Konfiguration geht es gleich weiter. Das bisher gesagte lief alles automatisch ab. Wie im Fall einer schweren Entscheidung verfahren wird, obliegt dem Benutzer. Unter Einstellungen -> Filter-Eigenschaften -> Plugins -> Bad Recipient Filter -> Einstellen verbirgt sich das Feintuning. Die bisher einzige Einstellung ist "Prioritize good over bad addresses" und sie ist standardmäßig deaktiviert. Trifft nun eine Mail sowohl mit guten als auch mit schlechten Adressen ein, entscheidet diese Option über die Einsortierung. Ist das Häkchen bei der Option gesetzt, wird auf Sicherheit gespielt: Eine gute Adresse reicht aus, um Zweifel zu kriegen. Die Mail wird also als gut erachtet und weitergereicht. Ist das Häkchen wie im Auslieferungszustand nicht gesetzt, haben die bösen Adressen die Oberhand: Eine einzige schlechte Adresse reicht, damit die Mail als Spam angesehen wird. Da können auch noch so viele gute Adressen in der gleichen Mail nichts dran ändern. Erfahrungsgemäß funktioniert die Standardeinstellung. Wer auf Nummer Sicher gehen will, setzt ein Häkchen. Gültig wird die Einstellung, wenn der Konfigurationsdialog mit OK beendet wird.

Drückt man das Fenster mittels OK weg, passiert noch etwas. Und zwar wird dann die Datenbank badrcpt.dat als CSV-Datei badrcpt.csv exportiert. Dadurch wird es möglich, die binäre und damit nicht sehr menschenfreundliche Datenbank in der Tabellenkalkulation zu begutachten. Daß die Datenbank ausgerechnet bei einem Klick auf OK exportiert wird, ist hierbei nur eine Interimslösung. Selbiges gilt für die beiden Dateien badrcpt_log.txt sowie badrcpt_addresses.txt. Sie dienten und dienen während der Erprobungsphase etwaigen Diagnosezwecken. Interessant ist hierbei insbesondere die Datei badrcpt_log.txt, die sämtliche Header-Zeilen gelernter Mails vereint, in denen ein @-Zeichen und somit höchstwahrscheinlich eine E-Mail-Adresse enthalten ist. Hiervon ausgenommen sind die header fields "Message-ID" und "Content-ID", die oft ebenfalls ein @, jedoch nie eine E-Mail-Adresse enthalten. Hintergrund des Ganzen ist eine Diskussion zwischen Quellcore und mir, welche Felder alle gelernt und oder überprüft werden sollen. Damals hatten wir beide keine Daten als Entscheidungsgrundlage in der Hand; mit der Log-Datei ändert sich das womöglich.

Kommen wir jetzt noch zu ein paar Einschränkungen, die die aktuelle Version besitzt:
  • Beim Überprüfen neuer Mails wird einfach so nach den bekannten Adressen aus der Datenbank gesucht, quasi so, wie es der Substring-Filter tut. Worauf ich hinauswill: Es wird nicht nach den Grenzen einer Adresse gemäß RFC2822 gesucht. Im Endeffekt bedeutet das, daß eine Adresse bad@example.com auch dann fälschlicherweise "gefunden" wird, wenn die Adresse in der neuen Mail eigentlich not-bad@example.com lautet.
  • Wer die RFC2822 studiert, wird feststellen, daß seeeehr seltsame Möglichkeiten zur Schreibweise einer stinknormalen Mail-Adresse existieren. Interessierten sei das Kapitel A.5 nahegelegt. Diese Sonderfälle werden momentan nicht als gültige Adressen behandelt.
  • In der Datenbank wird festgehalten, wann eine Adresse das letzte mal in einer Spam- oder in einer Non-Spam-Mail gelernt wurde. Hierzu wird momentan der Zeitpunkt des Lernens notiert, nicht der des Mailempfangs. In erster Linie liegt das an der einfacheren Umsetzung, außerdem könnte das Datum einer (insbesondere Spam-) Mail gefälscht sein.
  • Neue E-Mails werden bisher lediglich auf altbekannte Adressen hin durchsucht. Eine sinnvolle Erweiterung wäre es, auch nach unbekannten Adressen zu schauen. In Zusammenhang mit einer Benutzereinstellung ließen sich dann z.B. Mails mit unbekannten Empfängeradressen als Spam aussortieren.
  • Außerdem ein heißer Kandidat für eine konfigurierbare Einstellung wäre die Einschätzung einer gefundenen Adresse in die Kategorien gut oder böse. Momentan werden nur solche Adressen als böse gewertet, die ausschließlich in Spam-Mails auftraten. Denkbare Erweiterungen wären:
    • Dann Spam, wenn mindestens x mal mehr in Spam- als in Non-Spam-Mails gefunden. Also Spam >= Non-Spam + x.
    • Dann Spam, wenn mindestens y mal so oft in Spam- wie in Non-Spam-Mails gefunden. Also Spam >= Non-Spam * y.
    • Dann Spam, wenn maximal z mal in Non-Spam-Mails gefunden.
    • Dann Spam, wenn letztes Lernen als Non-Spam mindestens q Monate länger her ist als letztes Lernen als Spam.
    • Kombinationen hieraus.
    Alles gilt analog auch für gute Adressen.


Das wäre soweit das, was mir einfällt. Jetzt wünsche ich frohes Testen und freue mich auf Lob und konstruktive Kritik.

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 » 6. Okt 2006, 01:45

Hallo Burkart!

Erstmal vielen Dank! :D

Die Installation lief fehlerlos, der Filter erscheint nach Spamihilator-Neustart in der Filterreihenfolge an Platz 13 (wie machst Du das? :wink:) und in der Pluginliste entsprechend alphabethisch einsortiert und läßt sich konfigurieren. Ich setze ihn an fünfte Stelle und teste mal ein paar Tage. 8)

Gruß, Chactory
HilfeChactorys TippsAnbuvas FAQBob Loefflers FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLS
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: 9266
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 6. Okt 2006, 13:44

Hallo Burkart!
Installation lief bei mir ebenso problemlos, nur bis jetzt gab es zur Funktionsprüfung immer noch kein Spam-Eingang.

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 » 6. Okt 2006, 16:45

Hallo, Chactory!

Chactory hat geschrieben:der Filter erscheint nach Spamihilator-Neustart in der Filterreihenfolge an Platz 13 (wie machst Du das? :wink:)


Ganz einfach, heute ist Freitag, da sorgt die Aberglaubens-Routine natürlich für Listenplatz 13.

Im Ernst, was meinst Du? Wie ich was mache?

Chactory hat geschrieben:Ich setze ihn an fünfte Stelle und teste mal ein paar Tage.


Achja, bei der Gelegenheit noch eine Anmerkung zur Filter-Reihenfolge: Und zwar wird die badrcpt_log.txt ja immer dann beschrieben, wenn eine neue Mail auf Spam überprüft werden soll. Trifft also bereits ein Filter, der in der Reihenfolge weiter vorne steht, eine Entscheidung auf Spam oder Non-Spam, kommt der Bad Recipient Filter nicht zum Zug und schreibt demzufolge auch nichts in die Log-Datei. Auf die eigentliche Funktionalität des Plugins hat das natürlich keine Auswirkungen.

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 » 7. Okt 2006, 21:06

Hallo Burkart!

Nach der Installation befindet sich der Bad-Recipient-Filter bei mir automatisch an 13. Stelle in meiner Filterreihenfolge. Ist das von Dir beabsichtigt, oder sortiert sich ein neuinstallierter Filter zufällig irgendwohin?

Sind eigentlich die Adressen "hallobeispiel@krümelmonster.du" und "HalloBeispiel@KrümelMonster.Du" für den Filter dieselbe Adresse? In meiner csv-Datei habe ich jede Schreibweise in einer eigenen Zeile.

Gruß, Chactory
HilfeChactorys TippsAnbuvas FAQBob Loefflers FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLS
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: 9266
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 7. Okt 2006, 22:21

Hallo, Chactory!

Die 13. Position kommt zufällig zustande, ein Plugin hat da keinen Einfluß drauf. Ich glaube bei mir wurde es wie andere neuinstallierte Plugins ans Ende der Liste gesetzt.

Zwischen Groß- und Kleinschreibung wird in der Tat unterschieden. Mir ist das wohl deshalb noch nicht aufgefallen, weil bei mir eigentlich alle Adressen kleingeschrieben auftauchen. Für eine verbesserte Version wäre eine Betrachtung unabhängig von Groß- und Kleinbuchstaben sicher wünschenswert, danke für den Tip.

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

VorherigeNächste

Zurück zu Plugins: Feature Requests

Wer ist online?

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

cron

 industrious-southeast