Hallo, Quellcore!
Danke für die Ideen.
enutzung eines Unterordners
Plugin-Idee: Bad-Recipient-Filter
Moderator: Forum-Team
Re: Plugin-Idee: Bad-Recipient-Filter
von Burkart » 17. Okt 2006, 15:46
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.
dressen 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.
infü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?
s 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
!
