Hallo, Quellcore und Co!
Auch ich benutze seit längerer Zeit den Substring-Filter zum Aussortieren von Mails an mir fremde Adressen. Der Erfolg insbesondere bei Mails, die sonst kein anderer Filter erkennt, ermutigt, die ständige Arbeit hingegen ist lästig. Deshalb war auch mir schon die Idee nach einem selbständig lernenden Filter gekommen, allerdings mit einem etwas anderen Ansatz.
Folgende Mail-Grundtypen habe ich festgestellt:
a) Mails an eine meiner Adressen, die ich auch haben will. Diese Adressen beinhalten auch Mailinglists.
b) Spam an eine meiner Adressen, den ich nicht haben will.
c) Spam an fremde Adressen, den ich nicht haben will.
d) Mails an eine meiner alten Adressen, die weitergeleitet werden, über die in letzter Zeit jedoch gefühlt 100% Spam kommt, den ich nicht will.
e) Bei einer Catch-all-Mailbox Mails an eine fixe Domain mit variablem Benutzer. Ob Spam oder Gutmensch läßt sich schlecht sagen.
f) Massen-Mails von Freunden, die außer an mich noch an andere mir meist bekannte Adressen gehen und die ich haben will.
g) Massen-Mails von Freunden, die ich als BCC erhalten will. Meist steht unter "To:" der Absender selbst.
h) Kombinationen, insbesondere solche aus b), c) und d). In der Regel bedeutet das, daß ich die Mail nicht haben will.
Die (Massen-) Mails von Freunden lassen sich natürlich auch erkennen, indem ich deren Adressen in die globale Freundesliste eintrage. Wie in einem
anderen Thread beschrieben, gefällt mir die aktuelle Implementation der Spami-Freundesliste jedoch nicht hundertprozentig, weshalb sich ein Ausbau des Plugins auf Senderadressen in meinen Augen anbietet.
Bleiben wir der Einfachheit halber jetzt aber erstmal bei den zu filternden Empfängeradressen. Entgegen Quellcores Vorschlag würde ich eine Whitelist einführen, die somit automatisch meine Adressen lernt; in jedem Fall spart man sich so die manuelle Eingabe à la Adressee. Andere "gute" Adressen (Fälle e, f, g) würden so natürlich ebenfalls gelernt. Ebenso einfach würden unerwünschte Adressen in der Blacklist landen. Schwierig wird es erst, wenn Kobinationen auftreten oder wenn eine Blacklist-Adresse plötzlich für gut bzw. eine Whitelist-Adresse für schlecht befunden wird.
Mails an meine Whitelist- sowie eine fremde Blacklist-Adresse (Kombination aus a/b und c) sind schwer zu sortieren, wir sind in einer Grauzone. Die Frage ist jetzt, ob man auf Sicherheit gehen will, d.h. die Mail mit unbekannter Einstufung durchläßt, oder ob man davon ausgeht, daß es sich um Spam handelt. Ich sage dazu aus über einem Jahr Erfahrung mit dem Substring-Filter, daß es bei einer fremden Adresse bisher immer Spam war. Von daher würde ich in diesem Fall der Blacklist Priorität über die Whitelist geben. Dies übrigens im Unterschied zu Quellcore, wo die Greylist Priorität hat.
Es kommt also vor, daß Spam sowohl an eine fremde als auch an eine eigene Adresse geschickt wird. Beim Lernprozeß ergibt sich also die Situation, daß eine (meine) Whitelist-Adresse plötzlich als Spam-Adresse gelernt wird. Meine Idee diesbezüglich war es, neben der reinen Adresse auch den Zeitpunkt des letzten Vorfindens sowie die Anzahl der Fünde sowohl in der Black- als auch in der Whitelist zu vermerken. Über eine noch nicht näher bestimmte Rechnung hätte ich dann eine Einschätzung als gute, böse oder nicht zuzuordnende Adresse ermittelt. Hierzu muß ich sagen, daß Quellcores Greylist für all jene Adressen, die mindestens einmal in jeweils einer Spam- und einer Non-Spam-Mail aufgetaucht sind, durch ihre Einfachheit brilliert.
Nun haben ja "gute" Adressen erst einmal nichts in der Greylist zu suchen. Wenn dann kommt eine Whitelist infrage. Für die Implementierung macht Quellcores Vorschlag hingegen wieder Sinn - denn wenn die Adresse mangels Whitelist gar nicht gespeichert würde, würde sie ja beim ersten Fund in einer Spam-Mail fälschlicherweise in die Blacklist eingetragen werden.
Nun aber nochmal zurück zu dem Fall, daß eine Blacklist-Adresse in einer Non-Spam-Mail auftaucht. Erst einmal ist mir das wie gesagt in über einem Jahr noch nicht untergekommen. Sollte das aber tatsächlich mal vorkommen, wird es kompliziert. Die Adresse - wie von Quellcore vorgeschlagen - von der Black- in die Greylist zu übernehmen, würde dem Filter ein stückweit seine Effizienz rauben. Andererseits wäre es natürlich sehr ärgerlich, wenn eine früher in die Blacklist geratene Adresse plötzlich Verwendung findet, sie enthaltende Mails vom Filter jedoch weiterhin als Spam zurückgehalten würden. Über meine Idee der errechneten Einstufung aufgrund von Spam- und Non-Spam-Funden ließe sich dieses Problem ohne Mehraufwand umgehen, bei dem Greylist-Modell will mir hierzu keine einfache Lösung einfallen. Daher würde ich hier dafür plädieren, die Adressen im (bestimmt sehr seltenen) Fall des Falles in die Greylist zu übernehmen.
Alles in Allem würde ich somit Quellcores Vorschlag mit leichten Abänderungen zustimmen.
Scan-Process
************
scan Header data for recipient
check if one of the recipients is in the greylist >>> proceed with next filter process >>> unsure
...fällt weg.
check if one of the recipients is in the blacklist >>> filter process gets cancelled >>> classifiy mail as spam
Learning-Process
****************
learned as Non-Spam >>> check if recipient is in blacklist >>> if TRUE, move entry from blacklist to greylist
...dürfte in der Praxis fast nie auftreten.
learned as Non-Spam (cont'd) >>> check if recipient is in greylist >>> if FALSE, add recipient to greylist
learned as Spam >>> check if recipient is in greylist >>> if FALSE >>> check if recipient is in blacklist >>> if FALSE, add recipient to blacklist
Gehe ich recht in der Annahme, daß "cancel learning process" nur meinte, nicht auf Blacklist hin zu prüfen? In dem Fall finde ich die leicht modifizierte Beschreibung eindeutiger. War etwas anderes gemeint, bitte ich um Korrektur.
Diese leicht überarbeitete Fassung, im Grunde ein automatischer Substringfilter, ließe sich sicher vergleichsweise leicht implementieren und dabei trotzdem viel Spam ausfiltern. Mag sein, daß die von mir angedachte Variante mit Black- und Whitelist inclusive Timestamp und Zähler für Sender und Empfänger mehr Möglichkeiten bietet, dafür kriegt Quellcores Lösung eindeutig den Effizienz-Preis und ist damit einfach mal näher an einer Realisierung dran. Ich müßte mich nochmal mit der Spami-API und meinen eingerosteten C-Kenntnissen beschäftigen. Gerade weil mir eben diese Problematik auch schon länger unter den Nägeln brennt, könnte ich mir dann vorstellen, mich an einem Plugin zu versuchen - nehmt das aber bitte nicht gleich als Versprechen für eine schnelle Lösung.
Gibt es denn soweit erstmal weitere Ideen zu dem Filter?
Bye, Burkart
, denn dessen Filteridee ist prinzipiell schon hervorragend. Alle E-Mails, die nicht an mich adressiert sind, sind nicht für mich. Bingo! 
