Greylisting
Diesen Beitrag schrieb ich 15 Jahre und 5 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
- Wie es dazu kam
- Verwendete Software
- milter-greylist installieren
- Greylisting konfigurieren
- Sendmail konfigurieren
- Ein erster Test
Man sollte meinen, bei einem mit nahezu 1.000.000 Nachrichten trainierten Spamfilter sei die Erkennungsrate angemessen. War sie auch, doch vor einiger Zeit nahm sie rapide ab; obgleich weiterhin alle Nachrichten den Spamfilter durchliefen, wurden sie nicht als „Mist“ eingestuft und folglich regulär zugestellt – sehr zu meinem Ärger und auch dem der User.
Wie es dazu kam
Ich entschied mich also, auf beiden Servern das sogenannte Greylisting einzusetzen; hierbei wird – schon während des SMTP-Dialogs – abgeglichen, ob die zur eingehenden E-Mail gehörende IP-Absenderadresse-Empfängeradresse-Kombination bereits in der Datenbank zu finden ist. Ist das nicht der Fall, wird die Mail mit einem temporären Fehler abgelehnt und der Eintrag in die Datenbank übernommen:
451 4.7.1 Greylisting in action, please come back in 01:00:00
Der sendende Mailserver wird informiert, dass die Annahme der E-Mail deferred, also verzögert, erfolgen wird – und dass er sie hierzu nach einer gewissen (konfigurierbaren) Zeitspanne erneut senden muss. Ein korrekt konfigurierter und implementierter Mailserver wird genau dies auch tun, die überwiegende Zahl der von Spammern verwendeten Mailserver sind jedoch nicht in der Lage, Mails im Spool abzulegen und später erneut zu senden; und wird die Mail nicht erneut versendet, wird sie dem Empfänger auch nicht zugestellt – eigentlich ganz einfach.
Verwendete Software
Der hier eingesetzte MTA ist sendmail-8.13.8-3, der Spamfilter ist spamassassin-3.1.7-2 mit spamass-milter-0.3.1-2, fürs Greylisting kommt nun noch milter-greylist-4.2.2 hinzu. Ich betone das deshalb, weil ich im Netz kein brauchbares Howto zu dieser Konstellation finden konnte – und schon gar kein funktionierendes. Das Howto geht von einer funktionierenden sendmail/ spamassassin-Konfiguration aus, in die milter-greylist nun zusätzlich aufgenommen wird.
milter-greylist installieren
Ich habe mich dazu entschieden, milter-greylist aus dem Source heraus zu kompilieren; das geht ganz schnell und einfach so:
$ apt-get install flex bison libmilter-dev libmilter0 libgeoip1 build-essential
$ wget ftp://ftp.espci.fr/pub/milter-greylist/milter-greylist-4.2.2.tgz
$ cp -r /etc/mail /etc/mail.WEG
$ tar xvfz milter-greylist-4.2.2.tgz
$ cd milter-greylist-4.2.2
$ ./configure && make && make install
Für die hier vorliegenden Belange reicht das aus; wer möchte oder muss, kann sich per ./configure --help wie immer weitere Optionen aufzeigen lassen.
Greylisting konfigurieren
Die Konfiguration des Dienstes erfolgt in /etc/mail/greylist.conf und sieht in meinem Falle in etwa so aus:
## file: "/etc/mail/greylist.conf"
pidfile "/var/run/milter-greylist.pid"
socket "/var/milter-greylist/milter-greylist.sock"
dumpfile "/var/milter-greylist/greylist.db" 600
dumpfreq 1
user "smmsp"
## stat ">>/var/log/milter-greylist.log" \
## "%T{%Y/%m/%d %T} %d [%i] %r -> %f %S (ACL %A) %Xc %Xe %Xm %Xh\n"
verbose
## quiet
racl greylist default delay 5m autowhite 7d
Für den initialen Start reicht diese aus; inwiefern sie ausbaubar ist? Dazu später mehr…
Sendmail konfigurieren
Die /etc/mail/sendmail.cf ist um nachfolgende Einträge zu erweitern:
O InputMailFilters=greylist,spamassassin
O Milter.macros.connect=j,{if_addr}
O Milter.macros.helo={verify},{cert_subject}
O Milter.macros.envfrom=i, {auth_type}, {auth_authen}, {auth_ssf}, {auth_author}, {mail_mailer}, {mail_host}, {mail_addr}
O Milter.macros.envrcpt={rcpt_mailer}, {rcpt_host}, {rcpt_addr}
O Milter.macros.eom={msg_id}
Ein erster Test
Es gibt kein vorgefertigtes init-Script in /etc/init.d; daher wird der Prozess fürs erste durch direkten Aufruf gestartet:
$ /usr/local/sbin/milter-greylist
Aber hier ist nun das Beobachten der Logfiles angesagt: in der vorliegenden Konfiguration ist das eigene Logfile auskommentiert, der Dienst loggt somit ins reguläre Mail-Log – wem das nicht gefällt, der kann die Kommentarzeichen in der Konfig entfernen und dem Dienst einen Tritt geben.
Problematisch zeigte sich in der Vergangenheit die Mail einer jungen Frau, die nie bei mir ankam; die Analyse der Logfiles ergab dann, dass die Mail bei mir eintraf und fürs erste abgewiesen wurde. Als sie nach einer Viertelstunde erneut verschickt werden sollte, kam sie zwar über den selben Hostnamen, jedoch über eine andere IP als zuvor – und wurde somit wieder abgewiesen. Der sendende Mailserver initiierte nach etwa einer Stunde einen erneuten Versand – von einer dritten IP, und wieder wurde die Mail mit der Bitte um erneuten Versand abgewiesen. Der sendende Mailserver verwarf nach dem dritten erfolglosen Zustellversuch die Mail – ohne die Absenderin zu informieren! Das wiederum ist nicht RFC-konform und genau genommen ein Problem auf Senderseite, doch diese eine Mail landete im Nirvana – ich will’s nicht verschweigen, sowas ist kritisch. Daher ist es unbedingt empfehlenswert, die broken mta-Liste, die als Standard in der greylist.conf steht, auch aktiv zu belassen und für alle Fälle eine friendly domains-Liste zu erstellen – Mails von diesen Domains werden ebenfalls autowhitelisted, Kunden, Freunde usw.
Das deckt natürlich nicht wichtige Mails von freundlichen Unbekannten ab – insofern muss jeder für sich selbst entscheiden, wie weit er gehen will und wie weit nicht. Eine autowhitelisted-Liste lässt sich folgendermaßen anlegen:
list "friendly domains" domain {\
localwurst.de \
urban-exploring.eu \
geek-equip.net \
}
racl whitelist list "friendly domains"
Anschließend sollte, ehe man einen Reload des Dienstes veranlasst, das Konfig-File auf Richtigkeit überprüft werden (hat man verbose in der Konfiguration aktiviert, wird der Output etwas umfangreicher):
$ milter-greylist -c
config file "/etc/mail/greylist.conf" is okay
Solcherart in die Whitelist aufgenommene Domains oder Server äußern sich im Logfile wie folgt (am Beispiel der IP 127.0.0.1):
skipping greylist because address 127.0.0.1 is whitelisted
Per default wird jede Mail um einen Header erweitert, aus welchem im Detail hervorgeht, was mit der Mail passiert ist; das kann beispielsweise so aussehen:
X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.2 (geek-equip.net [88.198.155.93]); Tue, 19 May 2009 09:25:40 +0000 (GMT)
Oder aber
X-Greylist: Delayed for 00:15:19 by milter-greylist-4.2.2 (geek-equip.net [88.198.155.93]); Tue, 05 May 2009 09:01:50 +0000 (GMT)
Man hat viele Möglichkeiten: Whitelisting von From- und To-Adressen, von Servern und Domains, Testbetrieb mit einzelnen und klar definierten Usern und so weiter – man 5 greylist.conf und man milter-greylist geben Aufschluss und weitere Ideen.
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten