Greylisting

Achtung: dieser Blogeintrag wurde vor 2 Jahren, 8 Monaten und 14 Tagen veröffentlicht!
Beachtet das bitte dringend, vor allem im Falle konkreter Anleitungen.
Für etwaige Schäden kann keine Haftung übernommen werden!

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.

Ich entschied mich also, auf beiden Servern das sogenannte Greylisting einzusetzen; hierbei wird — schon während des SMTP-Dialogs — abgeglichen, ob die zur eingehenden eMail 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, daß die Annahme der eMail deferred, also verzögert, erfolgen wird — und daß er sie hierzu nach einer gewissen (konfigurierbaren) Zeitspanne erneut senden muß.

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, diese 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 muß, 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:

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 Prozeß 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, daß 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 genaugenommen 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 muß jeder für sich selbst entscheiden, wie weit er gehen will und wie weit nicht. Eine autowhitelisted-Liste läßt 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 veranlaßt, 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

X-Greylist

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 Aufschluß und weitere Ideen.