sendmail greylisting

wall < "Greylisting"

Broadcast message from spillerm@unixe.de (pts/1) (Fr Mai 22 23:01:52 2009):
4
Diesen Beitrag schrieb ich vor 10 Jahren. Behalte das beim Lesen bitte im Hinterkopf.

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:

Der sendende Mailserver wird informiert, dass die Annahme der eMail 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:

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 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 muss jeder für sich selbst entscheiden, wie weit er gehen will und wie weit nicht. Eine autowhitelisted-Liste lässt sich folgendermassen anlegen:

list "friendly domains" domain { \
        localwurst.de           \
        urban-exploring.eu      \
        geek-equip.net          \
}
racl whitelist list "friendly domains"

Anschliessend 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 äussern 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:

oder aber

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.

geek-equipnet-sendmail_mailstats-year

4
  1. Danke

  2. Super Artikel. Danke. Verwende selbst auch immer noch (und werde dabei bleiben) sendmail, fürs greylisting allerdings den spamd von OpenBSD. Ein Frage habe ich trotzdem. Die Grafik in dem Artikel. Womit machst du die, selbst geschrieben (bashh, perl, awk, gnuplot, …) oder ein tool? Egal was, könnte ich da bitte ein paar Informationen dazu haben? Danke

  3. Dass man die Deferred-Meldung eigentlich nicht rausgeben sollte steht auch in der Standard-Konfig des Tools; gerade wenn man noch nie damit gearbeitet hat und das Setup testet finde ich es sehr viel einfacher, wenn sie wirklich erscheint.

    Alles in allem würde ich sie ggf. deaktivieren, wenn die Annahmequote nach wie vor zu hoch wäre; allerdings habe ich die Annahme von > 500 Mist-Mails pro Tag und User auf ~10 drücken können — insofern bleibt es erstmal so, wie es ist :D

    Bzgl. dnswl.org: werde ich mir in den kommenden Tagen gleich mal zu Gemüte führen, vielen Dank für den Tip!

  4. Ich habe mal gelernt, dass die defer-Meldung keinen Hinweis darauf enthalten soll, dass Greylisting zum Einsatz kommt. Die Begründung war, dass Spam-Bots inzwischen auch korrekt darauf reagieren und wieder kommen würden.

    Fuer fremde Admins ist es allerdings ein Vorteil, zu sehen, warum eine Mail bei einem Zielsystem nicht direkt angenommen wurde.

    Ein weiterer Tip: Greylisting mit Whitelisting (z.B. dnswl.org) verbinden, um Verzögerungen bei relevanten Mails zu vermeiden.

Keine weitere Reaktionen mehr möglich.