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
