3. Konfiguration kSpam
Der nächste Schritt ist die Konfiguration von kSpam. Bis zur Version 1.39b2 musste sämtliche Konfiguration über Parameter in der notes.ini erfolgen. Das war nicht wirklich komfortabel und bedeutete, dass Änderungen immer einen Neustart erforderten, damit sie wirksam wurden.
Seit der Version 1.4b kann die Konfiguration über ein Konfigurationsdokument in der Datenbank kSpamCon.nsf erfolgen. Dies ist wesentlich komfortabler und das Konfigurationsdokument kann einfach in eine andere Datenbank kopiert werden, wenn kSpam noch auf anderen Server eingesetzt werden soll.
Das Konfigurationsdokument ist in 2 Teile gegliedert. Den Allgemeinen Teil und den Bayesisch-Spezifischen. Der Allgemeine Teil umfasst 13 Punkte, die recht gut in der Maske erklärt sind. Des Weiteren steht bei jedem Punkt, wie der Name des entsprechenden Parameters in der notes.ini lautet. Im Folgenden werden die einzelnen Parameter des Konfigurationsdokumentes erklärt.
1. „Instance ID“: Die ID sollte für jeden Server in einem Netzwerk gleich sein, da darüber ausgelesen wird, ob eine Mail schon innerhalb dieses Netzes geprüft wurde.
2. „Default action“: Beschreibt die Aktion, die ausgeführt wird, wenn eine der Filterregeln auf die Mail zutrifft.
3. „Default probability increase“: Gibt an, um wie viel Prozent die Spam-Wahrscheinlichkeit hochgesetzt wird. Dieser Parameter wirkt nur, wenn als „Default action“ „Increase Probability“ eingestellt wurde.
4. “Mark messages with a reason field?“: Gibt an, ob in Mails Felder eingefügt werden, die Auskunft über den Grund geben, warum diese Mail gefiltert wurde.
5. „Reload configuration every hour?“: Dieser Parameter erlaubt das Ändern der Konfiguration, ohne das der Server neu gestartet werden muss. Die Konfiguration wird jede Stunde ausgelesen.
6. „Show statistics“: Gibt an, ob kSpam Logs schreiben soll. Eine Auswertung kann z.B. in der Server-Konsole mit „show stat smtp.kspam.*“ gelesen werden.
7. „Minimum "From:" header length?“: Gibt die minimale Anzahl der Zeichen an, die das Feld „From“, also der Absender, haben muss.
8. „Maximum numbers in sender's username?“: Gibt an, wie viele Ziffern in einer Absenderadresse vorkommen dürfen.
9. „First character in "From:" header must not be a number?”: Gibt an, ob das erste Zeichen der Absender-Adresse eine Ziffer sein darf.
10. „Other forms to scan?“: Wenn noch andere Masken-Arten durchsucht werden sollen, dann kann man dies hier spezifizieren. Die Masken „Memo“ und „Reply“ werden standardmäßig durchsucht.
11. „Add recipients list to copied and denied messages?”: Gibt an, ob die Empfängerliste mit in ein Leser-Feld in der Mail-Maske geschrieben werden soll.
12. „Copied mail database“: Hier wird die Datenbank angegeben, in die die gefilterten Mails kopiert werden sollen.
13. „Turn on debugging?“: Hier können Debug-Informationen in eine Textdatei (ks_debug.txt) ausgegeben werden. Wird nur dann benötigt, wenn wirklich ein Problem auftritt und man diese Informationen an openntf.org weiterleiten möchte.
Der zweite Reiter “Bayesian” bietet nun die Einstellungen die nur den Bayesischen Filter betreffen. Teilweise hebeln diese Einstellungen die Einstellung unter „General“ aus.
1. „Bayesian filter enabled“: Der wichtigste Parameter für den Bayesischen Filter – ist er an oder aus? Ist der Filter nicht eingeschaltet, dann gelten alle weiteren Parameter auf dieser Seite nicht!
2. „Token reload period“: Gibt an, in welchen Zeitintervallen die Token neu aus den Datenbanken mailgood.nsf und mailspam.nsf ausgewertet werden.
3. „Probability boundary“: Gibt an, ab welcher Wahrscheinlichkeit eine Mail in die mailspam.nsf umgeleitet wird.
4. „Mark messages with token list and probability?”: Gibt an, ob die Spam-Wahrscheinlichkeit und die in der Mail gefundenen Token noch einmal extra in einem Feld in der Mail abgelegt werden.
5. „Good message ratio“: Gibt an, bis zu welcher Wahrscheinlichkeit eine Mail in die mailgood.nsf umgeleitet wird.
6. „Bayesian action“: Dieser Parameter gibt an, was mit der Mail geschehen soll, wenn sie dem Filter „zum Opfer“ gefallen ist.
7. „Mark with“: Gibt an, wie eine Mail gekennzeichnet wird, wenn sie als Spam erkannt wurde. Wirkt nur, wenn als „Bayesian action“ der Wert 1 (Mark) gesetzt wurde.
8. „Tokens to ignore“: Hier können Token definiert werden, die bei der Berechnung der Spamwahrscheinlichkeit ignoriert werden sollen.
9. „Dump token lists to file“: Hier kann definiert werden, ob die Token und ihre Wahrscheinlichkeit in einer Datei ausgegeben werden soll. Dies kann genutzt werden, um sich selber ein Bild zu machen, wie die Wahrscheinlichkeit berechnet wird und welche Token in die Liste des vorherigen Parameters aufgenommen werden sollten. Die Token werden in die Dateien goodlist.txt und spamlist.txt geschrieben.
Die nun folgenden „Preparation settings“ dienen der Lernphase des Spamfilters. Sie werden nacheinander eingeschaltet und können nie parallel laufen.
10. „Preparation setting 1“: Dieser Parameter dient dazu, die mailgood.nsf zu füllen. Jede Mail die nicht von den Regeln erfasst wird, wird in die mailgood.nsf kopiert.
11. „Preparation setting 2“: Diese Einstellung wird eingeschaltet, nachdem die erste Phase eine Weile gelaufen ist. Mit diesem Parameter werden Mails mit einer kalkulierten Wahrscheinlichkeit von unter 10% in die mailgood.nsf und mit über 90% in die mailspam.nsf gesendet.
12. „Turn on debugging?“: Hier können Debug-Informationen in eine Textdatei (bload.txt) ausgegeben werden. Wird nur dann benötigt, wenn wirklich ein Problem auftritt und man diese Informationen an openntf.org weiterleiten möchte.
Die erste Lernphase sollte so lange laufen, bis ca. 1000 Mails in jeder Datenbank sind. In dieser Phase muss eine stetige Kontrolle des Filters erfolgen, da falsche Mails in den Datenbanken die Erkennung von Spam beeinträchtigen. Die zweite Phase kann dann schon länger mitlaufen, die Mitarbeiter sollten dann schon eine Entlastung von Spam bemerken.
Die Anzahl der Mails in der mailspam.nsf und mailgood.nsf sollte nicht zu hoch sein, da dies eine kräftige CPU-Last beim einlesen der Wort-Wahrscheinlichkeiten zur Folge hat. Daher sollte die „Token reload period“ auch nicht zu klein angesetzt werden, da dies eine hohe Last auf dem Server erzeugen kann.
Ein Parameter der nicht oder nur sehr spärlich im Zusammenhang mit kSpam dokumentiert ist lautet: CONVERTER_LOG_LEVEL=10
Mit diesem Parameter in der notes.ini vermeidet man das zuspammen das Logs mit den "CD to MIME Conversion"-Einträgen.
