Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) als Spam- und Virenabwehr für Postfix? Diese Frage habe ich mir des öfteren gestellt. Ich sehe hier sehr klare Vorteile genauso wie Nachteile.

Der wirklich große Vorteil ist, dass wenn ein Client auf einer Blacklist steht, dieser sofort abgewiesen wird. Der Mailserver muss also erst überhaupt keine E-Mail annehmen, sich lange mit dem Client unterhalten, irgendwas filtern, auf das Beenden der Verbindung vom Client aus warten usw. usw…
Als Admin großer Mailserver wünscht man sich so etwas.

  • Denn hält ein Client die Verbindung bis zum Timeout offen, ist dieser Prozess für andere eingehende Verbindungen nicht zu gebrauchen. Einem läuft also die Tabelle voll.
  • Jede Spam- oder Virenemail die eingeliefert wird, verschwendet Traffic und Serverzeit.
  • Jede Spam- oder Virenemail im System beschäftigt dieses auch. Die E-Mail wird zwischengelagert, verschoben, gefiltert, überprüft, verglichen usw.. Sie nimmt echten E-Mails den Platz weg, diese müssen auf die Verarbeitung von Müll warten, alles verschleppt sich. Es entstehen Mailstaus, die Zustellung gewünschter E-Mails wird bis auf ungewisse Zeit verzögert!

Der für mich große Nachteil ist, dass man sich auf andere ~blind~ verlässt.

  • Ich kann die Blacklisten nicht wirklich überprüfen, es ist für mich zudem nicht wirklich transparent.
  • Hin und wieder landet auch mal ein System „versehentlich“ auf einer solchen Liste.
  • Ob und wie dieses System wieder von einer solchen Blackliste herunter kommt, kann ich nicht wirklich beeinflussen.

Es gibt zwar Wege, sich selbst eine solche Liste anzufertigen!
Einer ist, eine E-Mail Adresse überall dort zu veröffentlichen, wo sie vermeintliche Spammer einsammeln können. Jeder der dann an diese Adresse eine E-Mail sendet landet auf der Blackliste. So würde sich diese Liste selbst pflegen lassen. Es wird aber lange dauern bis sie wirklich effektiv arbeitet und der Spammer muss natürlich zuerst die „Sammeladresse“ anschreiben. Hier sind die großen Listen von spamhaus.org oder die Listen mit den dynamischen IP-Netzten schon viel viel viel weiter, wenn man sich auf diese verlassen möchte!

Ich habe es erst an einem Testsystem probiert und später Stück für Stück auf die echten Systeme ausgebreitet. Dieses mit überwältigendem Erfolg! ca. 80 – 90 Prozent aller Viren- und Spammails werden schon beim Einlieferungsversuch abgewiesen. Die Belastung der Server ist stark zurück gegangen. Bisher hat sich noch kein Kunde beschwert und mir ist kein Problem aufgefallen, wie Mailverlust, Falschabweisung oder ähnliches…. Diese Lösung ersetzt ganz klar keine nachgeschalteten Filter und man sollte alles im Auge behalten, hält einem denn noch extrem viel Müll vom Hals!

Die erste grobe Konfiguration ist schnell und einfach gemacht….

Die zu befragenden Server trägt man in die passenden Sektionen der Konfigurationsdatei /etc/postfix/main.cf ein.

Unter smtpd_recipient_restrictions

        reject_rhsbl_sender rhsbl.ahbl.org,
        reject_rhsbl_sender cart00ney.surriel.com,
        reject_rhsbl_sender in.dnsbl.org,
        reject_rhsbl_sender rhsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rhsbl_client abuse.rhsbl.kernel-error.de,
        reject_rhsbl_client postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_client spam.rhsbl.kernel-error.de,
        reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
        reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_sender spam.rhsbl.kernel-error.de,
        reject_rbl_client spam.rbl.kernel-error.de,
        reject_rbl_client socks.dnsbl.sorbs.net,
        reject_rbl_client http.dnsbl.sorbs.net,
        reject_rbl_client misc.dnsbl.sorbs.net,
        reject_rbl_client web.dnsbl.sorbs.net,
        reject_rbl_client new.spam.dnsbl.sorbs.net,

Wichtig:

Die Liste *.kernel-error.de ist meine ganz eigene private. Die nur für mich und meine eigenen Zwecke angedacht ist. Als einfachen Test könnt ihr sie natürlich gerne abfragen aber sie sollte niemals produktiv eingesetzt werden. Das wird bestimmt mal Probleme geben. Am besten einfach weg lassen!

Beim Eintragen muss auf das Komma geachtet werden und darauf dass die Einträge eingerückt werden. Sonst wertet Postfix diese als eigenständigen Eintrag, welcher zu Fehlern führen wird!

Ist ein Mailserver „versehentlich“ auf einer Blacklist gelandet wird sich der Administrator des Mailserver natürlich irgendwann wundern, warum sein Mailserver kaum noch E-Mails ausliefern kann. Diesem Administrator wollen wir natürlich die Arbeit etwas erleichtern und sorgen für klare Logeinträge in seinem System. Zudem sollten die Absender auch etwas sinniges bekommen. Daher setzten wir eine Standardrückmeldung für alle Systeme, welche aufgrund der Blackliste abgelehnt werden! Es muss in der Konfigurationsdatei /etc/postfix/main.cf etwas in dieser Art ergänzt werden:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@$recipient_domain; So long.....

 

Wird die Annahme der E-Mail nun verweigert, bekommt der Absender eine sinnige E-Mail. In dieser steht nun der Grund und dass er die Nachricht bitte an seinen Administrator weiterleiten soll (dieser sollte in der Lage sein sie auch zu verstehen). Zusätzlich wird noch angegeben unter welcher E-Mail Adresse man den Postmaster des Empfängers erreichen kann.

Nach einem Restart von Postfix sollte RBL schon laufen.

tail -f -n 200 /var/log/mail.log

 

Wie gut zu erkennen ist, baut ein Clientsystem mit der IP: 66.220.155.147 (GeoIP City Edition, Rev 1: CA, ON, Petrolia, (null), 42.883301, -82.150002, 0, 0) eine Verbindung zu unserem Mailserver auf. Dieses System befindet sich nun auf eine Blacklist oder kommt aus einem dynamischen Adressbereich, welche auf einer Blacklist steht. Es wird daher sofort ein 554 gesendet. Alle Fehlercodes aus dem Bereich 5XX sind als dauerhafte/fatale Fehlercodes deklariert. Bei allen Fehlern aus dem Bereich 5XX baut unser Server direkt die Verbindung ab und wartet nicht auf ein Beenden der Verbindung vom Client. Diese Verbindung wird somit sofort freigegeben und steht anderen Prozessen zur Verfügung.

Oct 31 16:19:16 postfix/smtpd[7308]: connect from outmail013.ash2.facebook.com[66.220.155.147]
Oct 31 16:19:18 postfix/smtpd[7308]: NOQUEUE: reject: RCPT from outmail013.ash2.facebook.com[66.220.155.147]: 554 5.7.1 Service unavailable; Client host [66.220.155.147] blocked using ix.dnsbl.manitu.net; Your e-mail service was detected by mx.selfip.biz (NiX Spam) as spamming at Wed, 31 Oct 2012 04:20:15 +0100. Your admin should visit http://www.dnsbl.manitu.net/lookup.php?value=66.220.155.147; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@user.de; So long.....; from=<notification+kr4mss2q24wx@facebookmail.com>; to=<user@user.de>; proto=ESMTP helo=<mx-out.facebook.com>

 

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

 

 

Ein kleines „Problem“ ist mir bei dieser Technik untergekommen. Einer der RBL Server, welchen ich abgefragt habe, hat (für mich) plötzlich seinen Dienst eingestellt. Dieses ist mir aber erst spät aufgefallen.
Im Postfixlogfile unter: /var/log/mail.log werden dazu Warnmeldungen angezeigt. Nach dem Timeout der Abfrage wurde einfach der nächste Server in der Liste abgefragt. Alles kein Problem, sollte man meinen 😀 Leider ist das Mailaufkommen auf diesem Server doch sehr hoch. Die ständigen Anfragen bis in die Timeouts führten leider in seltenen Fällen zu einer unvollständigen Rückmeldung anderer DNS-Abfragen. Einige E-Mails konnten so nicht richtig zugestellt werden. Die Rückmeldung war folgende:

<kernel-error@kernel-error.de>: Host or domain name not found. Name service error for name=mailserver.maildomain.de type=A: Host found but no data record of requested type

 

Nachdem ich den toten Server entfernt hatte und die DNS Abfragen nicht mehr in die Timeouts liefen, war dieses Problem weg! Ich habe nur leider in den ersten Minuten keinen Zusammenhang zwischen dem toten RBL-Server und einer gescheiterten „Weiterleitung“, wegen einer nicht vollständig aufgelösten DNS-Abfrage, gesehen.