|
Bartels SMTPFILTER
Sorry, the following information is currently only available in German.
Die Grundidee von SMTPFILTER besteht darin, nicht eine Mail aufgrund von einzelnen Schlüsselwörtern oder Phrasen zu kategorisieren sondern für bestimmte Eigenschaften der Mail Punkte zu vergeben. Diese Punkte können mit beliebiger Mathematik zu einem Endergebnis kombiniert werden und lösen dann eine oder mehrere Aktionen aus.
Um als zentraler Server zur Verfügung zu stehen, werden mehrere unterschiedliche Konfigurationen gleichzeitig verwaltet, die automatisch auf Basis der Domain des Empfängers selektiert werden.
Da auch die Versender von SPAM Mails um die Schlüsselwortsuchmaschinen wissen, werden Schlüsselwörter häufig verstümmelt, absichtlich falsch geschrieben oder kunstvoll auseinandergezerrt. Dagegen wird durch zwei unabhängige Methoden vorgegangen: zum einen können verschiedene Wortschreibweisen in Listen zusammengefasst werden, innerhalb der Regeln wird nur noch die Liste erwähnt. Zum anderen wird eine spezielle Worterkennungs- und Vergleichsengine verwendet, die speziell auf Wildcards und auf verstümmelte Worte optimiert ist.
Da Massenemails typischerweise an viele Anwender gesendet werden, wird aus jeder Mail eine Kette von Kennzahlen errechnet und diese in einer Liste vorgehalten. Jede Mail wird nun mit jeder Mail aus dieser Liste über die Kennzahlen verglichen und bei hoher Ähnlichkeit eine Ähnlichkeits- und Wiederholungszahl errechnet und in einer Variablen zur Verfügung gestellt, die innerhalb der Regeldatei ausgewertet werden kann. Auf diese Weise kann eine immer gleiche Mailflut mit geringen Abweichungen (SPAM Versender setzen z.B. den Namen des Mailaccounts in den Betreff oder die Anrede ein) erkannt und blockiert werden.
Da SPAM Versender meist den gleichen Internetprovider nutzen, wird eine Statistik geführt, wie viel SPAM aus dem gleichen Providernetz stammt und daraus eine Kennzahl errechnet. Je höher die Kennzahl, desto wahrscheinlicher, dass weiterer E-Mail Verkehr vom gleichen Provider wieder SPAM ist. Diese Kennzahl steht dem Regelsystem zur Verfügung und kann dort ausgewertet werden.
Weitere Features:
- Decodierung von base64 Nachrichten
- HTML Syntaxinterpreter. Der Filter lässt sich nicht durch HTML Kommentare o.ä. überlisten
- Wortstatistik zur Vermeidung von falschen Löschungen.
Der Filter arbeitet rein als SMTP Filter und gibt den Eingangsdatenstrom transparent an den einzustellenden Empfänger durch. Dabei kann zusätzlich ein Frontend eingesetzt werden, wenn spezielle Features am Frontend benötigt werden, die SMTPFILTER nicht bietet. SMTPFilter kann nur SMTP Protokoll ausgeben, so dass das Backend zwingend ist.
Sendmail ist dabei nicht in irgend einer Art bevorzugt, da nur das SMTP Protokoll gefiltert wird, es kann auch ein beliebiger anderer SMTP Handler als Front- oder Backend eingesetzt werden.
Hier wird beschrieben, welche Aktionen zur Verfügung stehen. Die Aktionen können beliebig kombiniert werden. Welche Kombination für welche Punktestände definiert werden, wird in der Sektion für die Regeldatei beschrieben
Aktion |
Beschreibung |
TNOTHING |
Diese Aktion führt zu nichts. Ist keine weitere Aktion angegeben, wird die Mail nicht an den Benutzer weitergeleitet |
TREJECT |
Es wird eine Ablehnungsmail an den Sender gesendet, in dem der Betreff, das Datum und der Empfänger eingesetzt werden |
TWARN |
Im Header der Mail wird das Attribut X-SPAMWARNING eingesetzt. Der Benutzer kann selbst nach diesem Attribut suchen und die Mails automatisch in einen anderen Ordner umleiten |
TREPORT |
Alle Aktionen werden geloggt und der Benutzer erhält zum nächsten Reportingzeitpunkt eine gesammelte Mitteilung, was mit den gefilterten Mails passiert ist. |
TTRASH |
Die Nachricht wird mit dem Spamprefix (siehe Konfiguration) versehen an den entsprechenden Benutzeraccount weitergeleitet |
TTRANSFER |
Die Nachricht wird mit dem Mailprefix versehen an den Benutzer weitergeleitet |
Zusätzlich wird in jedem Mailheader das Attribut X-SPAMPOINTS: <Punkte> eingeführt. Es besteht also die Möglichkeit, alle Mails mit TTRANSFER zu versehen und im Mailclient entsprechend zu filtern.
Weitere Aktionen werden durch die Goodbadlist direkt ausgeführt, bevor die Mail überhaupt gescannt wird und die Aktion wird entsprechend dem Befehl TTRANSFER oder TTRASH ausgeführt.
Die Worterkennung teilt die Zeichen in folgende Bereiche auf:
- Tatsächliches Zeichen
- Eventueller Worttrenner
- Sicherer Worttrenner
- Wildcard
Die tatsächlichen Zeichen werden so zusammengefasst, dass Groß/Kleinschreibung ignoriert wird und dass nicht durch besondere Zeichen, die visuelle zusammengehörig sind, Wörter nicht erkannt werden (z.b. á und a).
Solange Wörter nur durch eventuelle Worttrenner (z.b. Leerzeichen oder -) getrennt werden, werden alle Kombinationen, die sich aus dem Wort ergeben können getestet, soweit die einzelnen Segmente nicht mehr als 2 zusammenhängende Zeichen haben. Es wird also bei
t e s t
sowohl te als auch test als auch es und die restlichen möglichen Kombinationen erkannt. Trifft der Scanner auf ein Wildcard (z.b. ? oder $), so wird dieses durch jeden möglichen Buchstaben erkannt: t$st wird dabei also zu test tost trst tmst t1st usw. Der Wortscanner liefert die Eingabe für den Satzscanner, wie er bei der Regeldatei beschrieben ist. Außerdem werden spezielle Zeichenverwandtschaften erkannt. (z.b. 0 zu o oder i zu e) Dabei wird die Trefferwahrscheinlichkeit für das Wort reduziert, was zu einer Minderung des Regelwertes führt.
Das Programm kann mit folgenden Parametern gestartet werden:
Parameter |
Beschreibung |
-v<level> |
Verbose: in die Logdatei werden Meldungen mit entsprechendem Level <= <level>eingetragen (Standard ist 0). Wird –v0 angegeben, so wird der log explizit abgeschaltet. |
-t |
Test config only and exit after test |
-d<dir> |
Standardverzeichnis für config/regel Dateien (Standard: /etc/smtpfilter) |
-c<file> |
Config datei (Standard: config) |
-l logfile |
Ausgabedatei/Logdatei (Standard: /var/log/smtpfilter) |
In der Konfigurationsdatei werden zunächst einige generelle Angaben gemacht, anschließend können in mehreren Sektionen verschiedene Maildomains konfiguriert werden. Schlüsselworte, die mit einem $ versehen sind (bitte nicht mit $ eingeben), sind nur in der globalen Sektion zugelassen. Schlüsselworte, die mit & versehen sind, sind innerhalb einer Sektion oder im globalen Abschnitt zugelassen, alle anderen sind nur innerhalb einer Sektion zugelassen. Sektionen werden mit
[sektion1]
eingeleitet, Kommentare mit einem # (Leerzeichen und Tabulatoren sind erlaubt). Alle anderen Zeilen müssen als <Schlüsselwort> ’=’ <Wert> angegeben werden. Schlüsselworte, die von einem * gefolgt werden, können mehrfach angegeben werden.
Wird die Konfiguration geändert, so kann man den smtpfilter Stammprozess ein SIGHUP senden, damit dieser die neue Konfiguration einliest, der Prozess muss nicht neu gestartet werden.
Schlüsselwort |
Beschreibung |
INPUTIP $ |
Ip-Adresse, auf der der Filterprozess auf neue SMTP Verbindungen wartet |
INPUTPORT $ |
Die zugehörige Portnummer, ist der Filter das erste Glied in der Kette, so sollte die Nummer 25 vergeben werden. (Standard: 1025) |
IPRELAY $ |
Wenn eine SMTP Verbindung über diesen Server aufgebaut wird, so wird der Mailheader nach einer Received Zeile durchsucht und die dort angegebene IP-Adresse als Sender verwendet. Da abhängig von der IP Adresse des Senders entschieden wird, ob dieser Mails in das Internet versenden darf, muss die korrekte Absenderadresse ermittelt werden, wenn z.B. ein Sendmail am Eingang vorgeschaltet ist. |
Abhängig von der Domain des Empfängers wird die entsprechende Sektion ausgewählt, die sowohl die Regeln als auch die Goodbadlist bestimmt
Schlüsselwort |
Beschreibung |
DOMAIN * |
Domain des Empfängers, für den diese Sektion ausgewählt wird, es kann mit file: auch eine Datei mit einer Liste von Domains angegeben werden. (Beispiel: domain=file:/etc/mail/relay) |
RULEFILE * |
Regeldateien, die in dieser Sektion ausgewertet werden |
OUTPUTSERVER & |
Der SMTP Server, an den die gescannte Mail weitergeleitet wird |
OUTPUTPORT & |
Der Port am outputserver |
RANGE * |
IP Adressen, die diesen Server als Relay benutzen dürfen. Diese werden mit 10.10.0.0/24 angegeben, die Zahl hinter dem Slash gibt die Anzahl der Bits an, die von der Senderadresse und der Rangeadresse übereinstimmen müssen. Stammt eine Mailadresse aus diesem Bereich, so wird die Mail auf unabhängig vom Scanergebnis jeden Fall versendet. |
ADMIN * |
Absenderadresse von Emails, die globale Goodbadlist Einträge vornehmen dürfen |
popauthfile * |
DB Datei, in die über log2db die letzten authentifizierten POP oder IMAP Abfragen eingetragen sind. Mails von IP Adressen, die in dieser Datei auftreten, werden wie auch die Adressen in RANGE auf jeden Fall übertragen und dürfen den Server als Relay nutzen. Es können mehrere Dateien angegeben werden. |
DENYANSWERMSG |
Wird die Aktion TREJECT in der Regeldatei angegeben, so wird diese Mail an den Absender versandt. In der Datei werden folgende Schlüsseltexte ersetzt:
$SUBJECT$: die Betreffzeile der Originalmail
$DATE$: das Datum des Empfangs der Originalmail
$RCPT$: der Empfänger der Originalmail |
EMAILPREFIX & |
Wird die Aktion TTRANSFER in der Regeldatei angegeben, so wird die Empfängeradresse, die dem Ausgangsserver mitgeteilt wird, mit diesem Prefix versehen. Dabei sind folgende Möglichkeiten gegeben, die von der Position den @ abhängen:
@<domain>: aus recp@yahoo.com wird recp@<domain>
usr@mydomain.com: alle Mails werden an diesen Account geleitet
usr-: aus recp@yahoo.com wird usr-recp@yahoo.com |
SPAMPREFIX & |
Wird die Aktion TTRASH angegeben, so wird der Empfänger der Mail nach den gleichen Regeln wie bei EMAILPREFIX verändert. Wenn die Aktion TTRASH verwendet wird, so sollte auf jeden Fall ein SPAMPREFIX angegeben werden |
GOODBADLIST |
Dateiname mit der Liste von Absenderadressen, die vorverurteilt werden |
SYNCHAR* |
Klassifiziert ähnliche Zeichen. Die Zeile
SYNCHAR=$ TKS 0.9
bedeutet, dass immer dann, wenn ein $ Zeichen auftritt, dieses durch jeden der Buchstaben TKS ersetzt wird und dabei die Wahrscheinlichkeit des Wortes auf 90 Prozent reduziert wird. Die Zeichengruppen müssen mit einem Leerzeichen abgeschlossen werden, die Wahrscheinlichkeit muss nicht angegeben werden, dann wird 85 Prozent als default benutzt. |
TEMPDIR $ |
Verzeichnis, in dem eingegangene Mails als Dateien abgelegt werden, damit sie bei fehlerhaftem Versenden später erneut versendet werden können. Default: /var/spool/sfqueue |
duplicatefile & |
Nach den Einträgen in dieser Datei werden E-Mails dupliziert. Jede Zeile ist wie folgt aufgebaut:
<Prüfadresse> <Duplizieradresse> (in)? (out) ?
Die Prüfadresse kann user@domain oder einfach @domain sein.
Die Duplizieradresse muss ein Account in einer gültigen Konfiguration sein, ansonsten wird nicht dupliziert
Zu jeder Zeile kann das Schlüsselwort in und out angegeben werden, wobei beliebige Kombinationen erlaubt sind. Wird kein einziges Wort angegeben, so wird dies als „in out“ gewertet.
Wenn „in“ gesetzt ist, so wird der Absender der Mail mit der Prüfadresse dieser Zeile verglichen. Ist „out“ gesetzt, so wird jeder Empfänger der Mail mit der Prüfadresse verglichen. Der duplizierte Account erhält die Nachricht nicht direkt dem Absender sondern von bounceback@<letzte domain in seiner Config>. |
Das Reporting besteht darin, dass jeder Mailuser einmal pro Tag einen Report zugesandt bekommt, der ihn darüber Informiert, welche Mails gefiltert wurden. Wird in der Regeldatei die Aktion TREPORT mit angegeben, so wird die entsprechende Mail in den Report mit aufgenommen. Wurden keine Mails mit TREPORT angetroffen, so wird auch kein Report versendet.
Das Schlüsselwort REPORTTIME gibt die Tageszeit in Sekunden an, zu der der Report versandt werden soll. Dies könnte z.B. 1 Stunde vor Arbeitsende passieren, damit der Benutzer noch auf falsch gescannte Mails reagieren kann.
AUTOLEARNHASH & |
Dieser Wert kann Zahlen von 0 bis 2 annehmen und gibt an, welche Mails automatisch in die Statistik mit aufgenommen werden.
0: keine
1: Mails, die auf Basis der Good/Bad List klassifiziert wurden
2: Ausgehende Mails als gut, eingehende Mails, deren ASN Statistik über 90 liegt als schlecht. |
HASHFILE & |
Dateipräfix, ür die beiden Hashdateien. Es wird je eine Datei mit <HASHFILE>_good und <HASHFILE>_bad angelegt. |
HASHSIZE & |
Die Größe, die für die Hashdatei benutzt wird. Standardwert ist 1 MB |
Dieses Feature ist nicht zwingend, wird kein BGP Server angegeben, so wird auch keine BGP Verbindung aufgebaut. Da viele Spammails von den immer gleichen ISP’s versendet werden, wird mittels der IP Adresse der ISP identifiziert und eine Statistik geführt, wie viel SPAM von diesem Provider ausging. Über das BGP Protokoll werden einzelne Netznummern IP Adressbereichen zugeordnet. Um die notwendige Verbindung aufbauen zu können, sind folgende Parameter nötig:
Schlüsselwort |
Beschreibung |
BGPSOURCE $ |
IP Adresse des Servers, zu dem eine BGP Verbindung aufgebaut werden soll. Wird hier file:<Pfad> eingetragen, so wird kein TCP/IP Verbindung zum Server aufgebaut, sondern alle Nachrichten über die BGP Tabelle dieser Datei entnommen. Die Datei wird regelmäßig auf Änderungen überprüft und ggf. die Tabelle aktualisiert. |
BGPPORT $ |
Die Portnummer, auf dem die BGP Verbindung aufgebaut werden soll (sollte 179 sein). |
BGPASN $ |
Die AS Nummer, in dem der Mailserver steht. Diese muss mit der vom BGP Server erwarteten AS Nummer übereinstimmen. |
BGPFILE $ |
Die Datei, in die täglich die aktuelle Statistik geschrieben wird. |
Wenn der Filter als Frontend eingesetzt wird, kann es wünschenswert sein, dass sich die Benutzer authentifizieren, bevor sie Mails versenden können. Dazu werden von SMTPFILTER die Authentifzierungsmechanismen PLAIN und LOGIN unterstützt. Folgende Konfigurationsparameter sind möglich:
Schlüsselwort |
Beschreibung |
authserver $ |
Der Benutzer muss sich mit einem auf dem Server gültigen Benutzernamen einloggen. Ist dieses Flag gesetzt, so kann ein nicht eingeloggter Benutzer den Server nicht als Relay benutzen. |
AUTHUSER $ |
Der Benutzer muss sich mit seinem Namen einloggen. Wenn die Absenderadresse foo@bar.com ist, so muss sich der Benutzer mit foo einloggen. Ist in der bei virtusers angegebenen Datei ein Mapping von foo@bar.com auf foo_2 vorhanden, so kann sich der Benutzer auf mit foo_2 anmelden. |
AUTHCOMMAND $ |
Ist dieses Flag gesetzt, so ist für Good/Bad List Kommandos zwingend eine Authentifizierung notwendig. |
AUTHADMIN $ |
Ist dieses Flag gesetzt, so ist für Admin Good/Bad List Kommandos zwingend eine Authentifizierung notwendig. |
Virtuserfile $ |
Datei, in der mit log2db Mappings von Email Namen auf Benutzernamen oder Substitutionen von Email Namen eingetragen sind. Es können mehrere Dateien angegeben werden. |
Wenn sich SPAM Versender eindeutig identifizieren lassen, so können Gegenmaßnahmen ergriffen werden, die es dem Versender erschweren, seinen Maildurchsatz zu erreichen. Dabei werden nach Zufallsprinzip 2 unterschiedliche Maßnahmen ergriffen:
- Durchsatzsenden: Dabei wird eine große Textdatei als Protokollantwort versendet. Dies blockiert den Sender, soweit dieser nur einen schmalbandigen Zugang hat. Diese Methode ist nur sinnvoll, wenn der SMTPFILTER eine größere Bandbreite ohne Probleme nutzen kann.
- Als Antwort im Protokoll wird langsam eine sehr lange Zeichenkette ausgegeben, deren Versenden bis zu 2 Stunden dauert. Dabei werden Prozessressourcen beim SPAM Versender belegt.
Schlüsselwort |
Beschreibung |
counter_asn $ |
ASN des Versenders. Wird eine Verbindung aus diesem AS aufgebaut, so wird der Sender als Spammer erkannt. Bevor die Maßnahmen eingeleitet werden, wird noch geprüft, ob über die good/bad List eine explizite Freischaltung vorliegt. Dieser Befehlt kann mehrfach auftreten, um verschiedene ASN’s als Spamquelle zu listen. |
counter_file $ |
Die Datei, die bei Methode 1 versendet wird. Wird keine Datei angegeben, so wird auf Methode 1 verzichtet. |
counter_likely $ |
Die Wahrscheinlichkeit, dass eine Gegenmaßnahme getroffen wird. Gegenmaßnahmen werden generell deaktiviert, wenn bereits mehr als 10 Prozesse laufen. Die Zahl, die bei diesem Schlüsselwort eingetragen wird, gibt an, wie viele Pausen nach einer Gegenmaßnahme eingelegt werden. Wird eine 0 angegeben, so wird nie eine Gegenmaßnahme getroffen. |
Da mit Sicherheit jeder Benutzer auch Mails bekommt, die zwar verdächtigen Inhalt haben, aber durchaus erwünscht sind, können über die Goodbadlist einzelne Sender gezielt freigeschalten oder gesperrt werden. Damit hierzu nicht der Administrator bemüht werden muss, wird eine Mail unter folgenden Umständen als Goodbadlist Kommando betrachtet:
- Die E-Mail Adresse von Empfänger und Sender stimmen exakt überein.
- Die Mail wird nur an den Sender adressiert.
- Der Sender ist durch seine IP Adresse authentifiziert
- Das Subject beginnt mit einem : und wird gefolgt von einem Zeichen aus :+-#
Es sind folgende Kommandos möglich:
Kommando |
Beschreibung |
:++ yahoo.com |
Akzeptiert alle Mails von Yahoo.com |
:-- yahoo.com |
Lehnt alle Mails von yahoo.com ab |
:## yahoo.com |
Entfernt den Eintrag yahoo.com aus der Liste, der Filter wird für yahoo.com wieder aktiv |
:++ user@mail.com |
Schaltet nur Benutzer ‚user’ auf der Domain mail.com frei |
::RR<ASN> |
Setzt die Statistik für das angegebene ASN zurück. |
::?? |
Fragt alle Admineinträge in der Good-Bad List ab |
:?? |
Fragt alle Einträge des Absenders der Email ab |
:??<Domain> |
Fragt alle Einträge ab, die die Domain betreffen, dabei werden globale und benutzerspezifische Einträge berücksichtigt. Für die Domain kann eine komplette Emailadresse angegeben werden. |
Dabei kann auch die Domain mail.com komplett abgelehnt werden, der Benutzer user@mail.com jedoch freigeschaltet werden.
Ist die Absenderadresse in der Sektion des Benutzers auch als Admin eingetragen, so kann der Sender auch globale Einträge hinzufügen, die für alle Benutzer dieser Liste gelten. Auf diese Weise kann die Chefsekretärein die wichtigsten Geschäftskontakte generell von der Filterung ausnehmen. Globale Einträge werden dadurch identifiziert, dass die Betreffzeile mit zwei Doppelpunkten beginnt. Aus :-- yahoo.com wird dann ::-- yahoo.com
Wenn die Nachricht erfolgreich verarbeitet wurde, erhält der Sender nicht die Originalnachricht wieder, sondern eine Nachricht mit dem gesendeten Befehl und der Meldung „message command accepted“ oder „message command rejected“.
Der Reset für eine ASN Statistik kann nur als Admin ausgeführt werden.
Jede Mail wird Wort- und Phrasenweise einer statistischen Bewertung unterzogen. Dabei wird ein Hash Algorithmus verwendet, was den Datenbestand einerseits anonymisiert und andererseits eine hohe Geschwindigkeit sicherstellt. Dabei wird die Anzahl gezählt, wie häufig der, aus dem Wort / der Phrase berechnete Wert, in guten und in schlechten Mails vorkommt und daraus eine Wahrscheinlichkeit errechnet. Damit die Statistik sinnvolle Ergebnisse erzielen kann, müssen entsprechend gute und schlechte Mails gelernt werden. Dies kann einerseits über das AUTOLEARNHASH Schlüsselwort erfolgen oder direkt vom User durchgeführt werden.
Damit eine Mail als gut / schlecht gelernt wird muss sie von einem authentifzierten Benutzer an einen der Pseudoaccounts mit dem Namen good oder bad gesendet werden. Alternativ kann auch im Header der Email das Attribut X-LEARNGOOD oder X-LEARNBAD spezifiziert werden. Der Benutzer muss aber in jedem Fall authentifizert sein.
Als Ausgabe können die Variablen statisticquality und statisticresult ausgewertet werden. Solange nicht in jeder Hashtabelle mindestens 100 Mails gelernt wurden, wird die Qualität immer mit 0 ausgegeben.
Das Gerüst von Regeldateien sieht wie folgt aus:
%%ACTIONS
…
%%CONSTVARS
…
%%VARS
…
%%RULES
…
%%
Die einzelnen Sektionen sind in den Unterpunkten beschrieben. Jede dieser Sektionen muss angegeben werden, auch wenn sie leer bleibt. Alle Schlüsselwörter sind nicht von Groß/Kleinschreibung abhängig.
Unter diesem Punkt werden einzelnen Punktebereichen die auszuführenden Aktionen zugewiesen. Der Bereich, der als erster eingelesen wird, ist der Standardbereich, wenn sonst kein passender Bereich gefunden wird. Jede Zeile hat folgendes Format:
<unterer Punktestand> - <oberer Punktestand> Aktion1 .. Aktion n
Beispiel:
0 – 150 TTRANSFER
150 – 200 TTRANSFER TWARN
200 – 400 TTRASH TREPORT
400 – 100000 TNOTHING
Wenn sich mehrere Bereich überlappen, so wird der erste passende genutzt. Da mehrere Regeldateien in einer Konfiguration angegeben werden können, muss nur in einer dieser Dateien die Sektion ACTIONS gefüllt sein.
In dieser Sektion können Variablen deklariert und initialisiert werden. Es stehen dazu folgende Datentypen zur Verfügung:
Datentyp |
Beschreibung |
INT |
Ein Integer |
STRING |
Ein Textstring |
LIST |
Eine Liste an Textstrings |
MAP |
Eine Map, die zwei Listen miteinander verbindet. z.B. die Attributliste des Mailheaders ist eine solche Liste, in der die Attributnamen und in der zweiten Liste die zugehörigen Attributwerte aufgeführt sind. Bei der Initialisierung werden abwechselnd der Listenwert und der dazu gemappte Wert angegeben. |
Jede Zeile besteht aus dem Datentyp, dem Variablennamen und einer Initialisierung (die Initialisierung ist in dieser Sektion Pflicht).
Die einzelnen Listenelemente werden einfach in Anführungszeichen hintereinander geschrieben und können dabei noch durch Komma getrennt werden. Werden mehrere Wörter von Leerzeichen getrennt in Anführungszeichen geschrieben, so gilt das als eine Wortphrase. Dazu später mehr unter der Sektion RULES
In dieser Sektion können wie auch die Sektion CONSTVARS Variablen deklariert und initialisiert werden. Wenn die Variablen nicht initialisiert werden, sind sie im wesentlichen Wertlos. Des Sektion ist für Erweiterungen gedacht, wenn Funktionen Referenzparameter übergeben werden.
Folgende Variablen sind implizit deklariert und vor dem Scan passend initialisiert:
Variable |
Beschreibung |
STRING h |
Header (Subject) der Mail |
STRING b |
Body (Haupttext) der Mail |
STRING hb |
Gefilterter HTML Text ohne Tags. |
STRING sender |
Die Absenderadresse der Mail, wie sie im SMTP Protokoll angegeben wurde. |
STRING fromsender |
Der Absender der als FROM Attribut angegeben wurde und auch von den meisten Mailclients angezeigt wird. |
STRING replysender |
Die Adresse, die im REPLY-TO Attribut angegeben wird und benutzt werden soll, wenn eine Antwortmail geschrieben wird. |
LIST attachments |
Eine Liste mit allen Dateinamen von Anhängen. |
LIST torcpt |
Eine Liste aller Empfänger, an die die Mail laut TO: Attribut gesendet wurde. |
LIST ccrcpt |
Eine Liste aller Empfänger, die unter der Sektion CC aufgeführt sind. |
LIST realrcpt |
Eine Liste aller Empfänger, wie sie beim SMTP Protokoll angegeben wurde. |
LIST senderhost |
Hostname des Senders oder unknown, wenn dieser nicht auflösbar ist. |
INT chachevalue |
Ein Wert dafür, wie häufig und mit welcher Genauigkeit diese Mail bereits früher einmal empfangen wurde. Ein Wert von ca. 15 Zeigt an, dass die Mail das dritte Mal exakt übereinstimmt. |
INT asnspamcount |
Prozentzahl von 0 – 100, wie viele bisherige Mails des Sender Providers bereits SPAM waren. Nur gefüllt, wenn eine BGP Session vorhanden ist. |
MAP headerlist |
Eine Map mit allen Attributen, die im Mailheader angegeben waren und welcher Wert ihnen zugewiesen wurde. |
INT sendernomx |
Steht auf 1, wenn für die sendende Domain kein MaileXchange Eintrag gefunden wurde, also der Sender vermutlich nicht per Mail erreichbar ist. |
INT nonalphapercent |
Prozentzahl von 0 – 100, wie viele Zeichen im Mailtext keine ASCII druckbaren Zeichen sind. Hohe Zahlen deuten auf asiatische Absender hin |
INT htmlfontcolorcount |
Anzahl der HTML Tags, mit denen eine Fontfarbe angegeben wurde. Hierüber werden sehr bunte Seiten identifiziert, > 3 ist sehr wahrscheinlich SPAM. |
INT wordcuts |
Zählt die Wörter die trotz Verstümmelung durch Leerzeichen oder Punkte etc. erkannt wurden. |
INT statisticquality |
Liefert einen Wert von 0 – 100, wie gut die statistische Auswertung war. |
INT statisticresult |
Liefert einen Wert von 0 – 100, 0 ist richtig schlecht, 50 ist neutral und 100 ist richtig gut. |
Jeder Regelkopf besteht mindestens aus dem Schlüsselwort rule, dem Namen der Regel und einem Doppelpunkt. Jede Regel ist implizit mit ihrem Namen als ein Integer deklariert und kann daher in mathematischen Ausdrücken verwendet werden. Hier ein paar Beispiele für die Einleitung einer Regel:
RULE einfach: <regel> |
Das einfachste Konstrukt, wenn die Regel zutrifft, wird der Variablen einfach der Wert 30 zugewiesen. |
RULE bestimmt 70: |
Die Regel erhält 70 Punkte wenn sie zutrifft. |
RULE mehrfach 70 * 3: |
Die Regel erhält beim ersten mal zutreffen 70 Punkte, beim zweiten mal etwas weniger usw. die Regel wird aber niemals mehr als 210 Punkte erreichen. |
RULE EMIT Regelname 110: |
Die Regel liefert 110 Punkte, wenn sie zutrifft. Diese Punkte werden zu dem Endergebnis hinzugezählt, weil das Schlüsselwort EMIT angegeben wurde. |
RULE negativ –40: |
Die Regel erhält –40 Punkte, wenn sie zutrifft. Auf diese Weise können z.B. bestimmte Accounts toleranter sein und mehr Punkte akzeptieren. |
Es gibt mehrere Arten von Regeln: CONTAINS, MATCH, IN und mathematische Regeln, die im Folgenden genauer erläutert sind.
Für mathematische Regeln stehen folgende Operatoren zur Verfügung:
Operator |
Typ |
Beschreibung |
+ |
Int / String |
Addiert die beiden Zahlen oder berknüpft die beiden Strings |
- |
Int |
Subtrahiert die Zahlen |
* |
Int |
Multipliziert die Zahlen |
/ |
Int |
Dividiert die Zahlen |
< |
Int |
Vergleicht Zahl1 mit Zahl2 |
> |
Int |
Vergleicht Zahl1 mit Zahl2 |
== |
Int / String |
Vergleicht die beiden Zahlen oder die beiden Strings. Der Stringvergleich ist Groß/Kleinschreibungsabhängig |
!= |
Int / String |
Vergleicht die beiden Zahlen oder die beiden Strings. Der Stringvergleich ist Groß/Kleinschreibungsabhängig |
= |
Int / String |
Vergleicht die beiden Zahlen oder die beiden Strings. Der Stringvergleich ist nicht Groß/Kleinschreibungsabhängig |
<> |
Int / String |
Vergleicht die beiden Zahlen oder die beiden Strings. Der Stringvergleich ist nicht Groß/Kleinschreibungsabhängig |
Für mathematische Regeln gilt die Punktzahl der Regel als Obergrenze, ansonsten entspricht das Ergebnis der Operation. Übersteigt die Punktzahl die Obergrenze, so wird diese Obergrenze zugewiesen. Die Ergebnisse von Vergleichen sind immer 0 oder 32000, was anschließend auf das Maximum der Regel reduziert wird. Ist der Regel eine negative Punktzahl zugeordnet und der Absolutbetrag des Ergebnisses liegt darüber, so wird der negative Betrag zugeordnet.
CONTAINS Regeln bestehen aus einer Variablenliste, die zu durchsuchen ist, dem Schlüsselwort CONTAINS und anschließend einer Wortphrase.
Es gelten folgende Regeln:
- Es können vor dem CONTAINS mehrere Variablen stehen, die mit Komma getrennt werden.
- Jeder Text wird in Anführungszeichen angegeben, wobei auch einfache Hochkomma genutzt werden können.
- Nach dem CONTAINS können mehrere Worte stehen. Mit eckigen Klammern oder mit Tilden kann angegeben werden, wie viele Worte zwischen den gesuchten Schlüsselwörtern auftreten dürfen.
- Wenn innerhalb der Anführungszeichen mehrere Worte stehen, so entsteht daraus eine feste Wortphrase, die ohne Abstand definiert ist.
- Statt einzelner Wörter können auch Listen benutzt werden, wobei ein beliebiges Wort aus Liste1 mit einem beliebigen Word aus Liste2 verknüpft mit dem definierten Abstand einen Treffer ergibt.
- Es können spontane Listen genutzt werden, indem die zu suchenden Wörter in Klammern mit Kommata getrennt geschrieben werden. Auch in Listen können mehrere Wörter hintereinander innerhalb eines Strings stehen.
- In einem String kann ein Fragezeichen auftauchen, dann können die beiden Wörter, die durch das Fragezeichen getrennt sind, wahlweise zusammen oder getrennt stehen. Die Trennung kann ein beliebiges „nicht Text Zeichen“ sein.
- Die Variablen, die vor dem CONTAINS stehen, können auch Listen sein, wobei jeder einzelne Wert der Liste gescannt wird.
- Alle Werte, die rechts von CONTAINS verwendet werden, müssen konstante Werte sein.
- Jedes Wort, nach dem gescannt wird, kann durch ein * beendet werden.
Das Schlüsselwort CONTAINS ist in den folgenden Beispielen mit CT abgekürzt ist. Es wird angenommen, dass in der CONSTVAR Sektion folgende Variablen deklariert wurden:
STRING var1 = “Fisch“
LIST var2 = “Fahrrad” “Auto”
LIST var3 = “Fahrrad” “Lenkrad” “rotes Auto”
Beispiele:
Beispiel |
Erklärung |
h CT „Auto“ |
Die Variable h enthält das Wort „Auto“ |
h, b, hb CT „Auto“ |
Eine der Variablen h, b, hb enthält das Wort „Auto“ |
h CT var1 |
Die Variable h enthält das Wort „Fisch“, welches in der Variablen var1 zugewiesen ist. |
Rule r1: b CT var2 |
Die Variable b enthält das Wort „Fahrrad“ oder „Auto“, also eines der Wörter, die der Variablen var2 zugewiesen wurden |
h CT „hallo“ [1, 3] „da“ |
Die Variable h enthält das Wort „hallo“ und 1 bis 3 Worte später das Wort „da“ |
h CT „hallo“ ~ „da“ |
Kurzform für “hallo” [0,2] “da”. Bei 2 Tilden sind es [0,4] und bei 3 Tilden sind es [0,10] |
h CT „hallo“ [5] „da“ |
Kurzform für „hallo“ [0,5] „da“ |
h CT „hallo“ ‚da’ |
Die Variable enthält das Wort „hallo“ und anschließend das Wort „da“ |
h CT „hallo“ („Auto“, „Fisch“) |
h enthält das Wort “hallo“ gefolgt entweder von „Auto“ oder von „Fisch“ |
h CT “hallo” (“fliegendes Auto”, var1) |
h enthält entweder „hallo“ gefolgt von „fliegendes“ gefolgt von „Auto“ oder „hallo“ gefolgt von „Fisch“ |
h CT „hallo“ ~ var3 ~ “da” |
h enthält „hallo“ gefolgt von einem der Wörter in var3 mit einem Abstand von höchstens 2 Worten dazwischen, gefolgt von dem Wort „da“. Dies entspricht der Kombination aus den Regeln
„hallo“ ~ „Fahrrad“ ~ „da“
„hallo“ ~ „Lenkrad“ ~ „da“
„hallo“ ~ „rotes“ „Auto“ ~ „da“ |
b CT „opt?in” “now” |
Trifft zu auf “optin now”, “opt in now” “opt – in now” |
Bei IN Regeln wird ein String in einer Liste gesucht, es können aber beliebige Kombinationen aus Strings und Listen verwendet werden. Die Regel trifft zu, sobald ein Element aus der ersten Variable in der zweiten Variable auftritt. Der Vergleich ist dabei nicht Groß/Kleinschreibungsabhängig.
Die Syntax lautet:
<var1> IN <var2>
Beispiel:
realrcpt IN torcpt
Prüft, ob mindestens ein Empfänger in der TO Liste auftaucht.
Mittels MATCH können reguläre Ausdrücke verarbeitet werden. Die Syntax lautet:
<var> MATCH <regulärer Ausdruck>
Der reguläre Ausdruck muss dabei in Anführungszeichen oder Hochkommata stehen.
Beispiel:
sender MATCH ".*[0-9]{2,}.*@"
Erkennt, ob mindestens 2 Ziffern hintereinander im Namen des Senders enthalten sind.
Für jede Variable kann auch ein Funktionsaufruf stehen, der auf Basis anderer Variablen einen Wert ermittelt.
Beispiel:
stringinmap(„X-MSMail-Priority“, headerlist) CONTAINS „high“
Ruft die Funktion stringinmap auf, welche nach dem Text „X-MSMail-Priority“ in der headerlist sucht und den zugewiesenen Wert ermittelt. Enthält dieser Wert das Wort high, so wurde die E-Mail mit hoher Priorität versendet. Folgende Funktionen stehen zur Verfügung:
Funktion |
Beschreibung |
string stringinlist(string1, list1) |
Sucht in list1 nach string1 und liefert string1 oder einen Leerstring zurück. |
List listinmap(string, map) |
Liefert eine Liste aller gemappten Werte in map, die string entsprechen. |
string stringinmap(string, map) |
Liefert den ersten gemappten Wert in map, dessen Listenelement string entspricht. |
string senderof(string) |
Liefert den Absendernamen einer Emailadresse (test für test@yahoo.com) |
string domainof(string) |
Liefert die Domain der Adresse (yahoo.com für test@yahoo.com) |
string primarydomain(string) |
Liefert nur die erste Domain einer Adresse (www.yahoo.rd.tv) liefert rd.tv |
string resolveaddress(string) |
Liefert die Rückwärtsauflösung der IP Adresses der übergebenen Adresse. |
Ziel: Mailaccounts, die auf einer offiziellen Webseite stehen, werden häufig in Spam mit einbezogen. Da dort möglichst keine Mail verloren gehen sollen, soll die Toleranzschwelle aber erweitert sein. Hier wird gezeigt, wie man bestimmte Regeln für spezielle Accounts umgewichten kann.
# Diese Regel erhält 50 Punkte, wenn ein officieller Account der Empfänger ist
rule officialaccount 50 : realrcpt contains („info“, „pr“, „sales“)
# Diese Regel erhält 1 Punkt, wenn besonders unerwünschte Regeln getroffen wurden.
rule officialdenyrules 1 : sexwords + unsubcribe
# diese Regel emmitiert –50 Punkte für offizielle Accounts oder +50, wenn auf dem
# offiziellen Account spezielle Regeln getroffen wurden
rule EMIT officialemit 200: officialdenyrules * 100 * officialaccount / 50 – officialaccount
Ziel: Sobald eine Mail das dritte mal eintrifft, sollen schnell wachsend viele Strafpunkte vergeben werden, ansonsten soll die Ähnlichkeit ignoriert werden.
# Diese Regel erhält 1 Punkt, wenn der Cachewert auf 15 oder mehr steht
rule repetitivehelper 1: cachevalue > 14
# Diese Regel wird erst aktiv, wenn repetitivehelper gesetzt ist, und liefert für die
# ersten 2 übereinstimmungen keine Strafpunkte, ab der dritten werden ca. 40 Punkte
# pro Regel übergeben
rule EMIT repetitive 300: repetitivehelper * (cachevalue - 8) * 10
Ziel: einige Regeln sollen zusammen nicht über eine bestimmte Punktzahl aufsummieren können, da sie zu wenig aussagekräftig sind.
# Diese Regel prüft, ob aus dem ASN früher viel Spam kam
rule asnspam 110: asnspamcount * 2
# Diese Regel prüft, ob viele HTML Farben vorhanden sind
rule htmlcolored 100: htmlfontcolorcount * 20
# Diese Regel stellt sicher, dass asnspam und htmlcolored
# zusammen nicht alleine die Mail als spam qualifizieren
rule emit non_content_rules 140: asnspamcount + htmlcolored
Bartels SMTPFILTER © 2024 Bartels System GmbH • Updated: 11 October 2010, 10:54 [UTC]
|