Als Serverbetreiber kommt man früher oder später mit DNSBLS (DNS-based Blackhole List) zur Spam-Abwehr in Berührung. In den meisten Fällen wird man diese auch selbst einsetzen.
Und das kann man gut machen, oder man kann es schlecht machen....
Was sind DNS-based Blackhole List?
DNSLBL sind Listen, auf denen in den Regel Server geführt werden, die SPAM versenden. Man fragt diese Listen per DNS ab, was sehr schnell geht.
Die Abfrage der DNSBL wird also in den Mailserver eingebunden. Mailserver prüfen dann, ob sich eine IP auf einer oder mehreren Blacklisten befindet und weisen dann unter Umständen die Email ab.
Eine sehr schlechte Idee ist es, aufgrund des Listings auf einer Blackliste die Email ab zu weisen, dazu mehr weiter unten.
Man sollte außerdem den Status seines eigenen Mailservers überwachen, indem man die DNSBLs auf Listing der eigenen IP-Adresse überprüft, beispielsweise mit Icinga.
Alternativ stellen zahlreiche Webseiten einen Web-basierten Check zur Verfügung, beispielsweise MXToolBox.
Bekannte DNSBL
DNSBL gibt es wie Sand am Meer. Den meisten Administratoren sind die Projekte Spamhaus, Spamcop oder NIXSPAM ein Begriff. Diese Listen nenne ich stellvertretend für Listen mit einem guten Ruf. Unter anderem bieten Sie eine schnelle und kostenlose Austragungsmöglichkeit.
Gefahren beim Einsatz von DNSBL
Neben den oben genannten DNSBL gibt es auch umstrittene DNSBL, beispielsweise UCEPROTECT, die ich hier absichtlich nicht verlinke. UCEPROTECT möchte 98 Euro für ein Delisting haben, sonst bleibt man 14 Tage auf der Liste, was in meinen Augen sehr fragwürdig ist.
Was auch schon öfter passierte: Manche DNSBL blockierten einfach ganze Netze, die ihnen nicht passten, nach zu lesen hier, oder eine Liste wurde eingestellt und "blockierte dann mal eben das ganze Internet".
Wie gelangt man auf eine DNSBL und was kann man tun, um dort gelöscht zu werden?
Wird der Mailserver für den Spamversand genutzt, dann landet man recht schnell auf einer Blacklist. Selbst wenn man, wie ich, die Befüllung der Mailq überwacht und sich benachrichtigen lässt, kann man den Spamversand nicht ganz verhindern - wenn dieser beispielsweise nachts einsetzt und man dies erst am frühen Morgen bemerkt.
Die Grafik zeigt einen gegen 3 Uhr beginnenden Spam-Versand, gegen 6 Uhr wurde eingegriffen und der Spam-Versand unterbunden.
Spamversand geschieht schnell: Über kompromitierte Webseiten oder per SMTP mit Authentifizierung, wenn die Zugangsdaten zu einem Emailkonto in Umlauf geraten. Man kann sich hier nicht dauerhaft schützen, sondern nur reagieren und den Spam-Versand unterbinden, nachdem er auftritt.
Durch den Einsatz einer Überwachung der DNSBL, zum Beispiel per Nagios oder Icinga, kann man sich schnell informieren lassen, alternativ übernehmen externe Monitorung-Systeme gegen Gebühr dies.
Wie setzt man DNSBL sinnvoll ein?
Das Einsetzen nur einer einzigen DNSBL ist unprofessionell, da eine Blockliste ja auch Unfug melden kann (wie weiter oben mit Beispielen erwähnt).
Sinnvoller ist der Einsatz von Systemen, die verschiedene Parameter und Blocklisten prüfen und gewichten, wie policyd-weight für postfix. Hier werden bei jeder Prüfung Punkte vergeben, die in einer Gesamt-Wertung resultieren. Erst ab einer gewissen Punktzahl werden Emails abgwiesen. Dies verhindert, dass Emails bei Fehlern in nur einer Blockliste abgewiesen werden.
Beispiel für eine abgewiesene Email:
postfix/policyd-weight[16586]: weighted check:
IN_DYN_PBL_SPAMHAUS=3.25
IN_SBL_XBL_SPAMHAUS=4.35
NOT_IN_SPAMCOP=-1.5
CL_IP_EQ_HELO_IP=-2 (check from: .senderdomain1. - helo: .88.41.xx.xx.dynamic.jazztel. - helo-domain: .jazztel.)
FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9
HELO_SEEMS_DIALUP=4.5
CLIENT_NOT_MX/A_FROM_DOMAIN=9.1
CLIENT/24_NOT_MX/A_FROM_DOMAIN=9.1;
<client=88.41.xx.xx.dynamic.jazztel.es[188.78.xx.xx]> <helo=88.41.xx.xx.dynamic.jazztel.es> <from=gespenstsoja(at)senderdomain1.de>
<to=empfaengeremailadresse>;
rate: 29.7
Ergebnis, die Email wird abgewiesen, da eine Punktzahl von 29,7 erreicht wurde, die weit über dem Schwellwert liegt:
postfix/policyd-weight[16586]: decided action=550 Mail appeared to be SPAM or forged.
Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (senderdomain1.de);
Please use DynDNS; <client=88.41.xx.xx.dynamic.jazztel.es[188.78.xx.xx]> <helo=88.41.xx.xx.dynamic.jazztel.es> <from=gespenstsoja(at)senderdomain1.de>
<to=empfaengeremailadresse>; delay: 0s
Geprüft wird:
- Ist der Server auf Blacklisten
- passen DNS-Einträge und HELO des Mailservers zusammen
- ist der Mailserver in der DNS-Domäne der Absender-Adresse oder in der Liste der MX-Server
- Ist die IP in einer IP-Range, die dynamisch vergeben wird (DSL-Anschlüsse usw, hier befinden sich normalerweise keine MailServer)
Beispiel für eine akzeptierte Email:
postfix/policyd-weight[16588]: weighted check:
NOT_IN_SBL_XBL_SPAMHAUS=-1.5
NOT_IN_SPAMCOP=-1.5
CL_IP_EQ_HELO_IP=-2 (check from: .absenderdomain. - helo: .s192.absenderdomain. - helo-domain: .absenderdomain.)
FROM/MX_MATCHES_HELO(DOMAIN)=-2;
<client=s192.absenderdomain.com[213.239.193.24]> <helo=s192.absenderdomain.com> <from=return(at)absenderdomain.com> <to=empfaengeremailadresse>;
rate: -7
Erreicht wurde eine negative (gute) Punktzahl von -7
Wie man es richtig schlecht macht
Indem man einfach nur eine Blacklist abfragt und beim Listing auf dieser Backlist die Email abweist, kann man anderen Mailserver-Administratoren richtig schön Ärger machen. Um den anderen Mailserver-Administratoren das Leben so richtig schwer zu machen, verzichtet man auf eine Austragungsmöglichkeit und belässt den Eintrag möglichst lang auf der Liste.
Sehr einfach geht das zum Beispiel durch den Einsatz von Produkten, wie IRONPORT, die Ciscos Blackliste senderbase.org benutzen.
Cisco selbst proklamiert für sich in den FAQ von senderbase.org, der Spam-Welt-Polizist zu sein, denn "die meisten Blacklisten werden von seltsamen Leuten gepflegt, die ja keine Ahnung oder seltsame Motive haben", schreibt man dort: "SenderBase was created to both reduce the problem of idiosyncratic behavior in DNS-based blacklists...".
Landet man nun mit seinem Mailserver auf der Liste von senderbase.org, dann hat man Pech, weil:
- Austragung nicht möglich: "No. SenderBase is an automated system. All IPs are subject to the same reputation calculation standards. Manually adjusting a score would be contradictory to fair and equal assessment of all IPs"
- Kann mal eben bis zu über einer Woche dauern, mit der Austragung: "In general, once all issues have been addressed (fixed), reputation recovery can take anywhere from a few hours to just over one week"
Allerdings weiß dort die eine Hand nicht, was die andere Hand tut: "If you know what your problem was and have fixed it, your score should improve automatically within 3-5 days"
Ja was denn nun, 3 Tage oder 1 Woche? Und dann geht doch ein Ticket? Nachzulesen hier.
Bei einem meiner Systeme habe ich aktuell schon seit 50 Stunden nach Beheben eines kurzen Spam-Versands (und dem Delisting in anderen DNSBL) bei zahlreichen Zielsystemen diese Meldung:
(host senderbase-benutzender-mailserver] refused to talk to me:
senderbase-benutzender-mailserver 554 Your access to this mail system has been rejected due to the sending MTA's poor reputation.
If you believe that this failure is in error, please contact the intended recipient via alternate means.)
60 Stunden - eine Ewigkeit in Zeiten des Internets. Das Gemeine: Die Emails werden mit dem SMTP-Code 554 nicht abgewiesen (Bounce), sondern bleiben in der Mailqueue liegen, in der Regel versuchen Mailserver dann über mehrere Tage, diese Emails zu zu stellen. Der Absender erfährt in dieser Zeit aber Nichts, da die meisten MailServer keine Benachrichtigungen über verzögerte Zustellung versenden.
Laut Senderbase soll man dann halt die Administratoren der Systeme anschreiben oder "andere Wege benutzen". Ersteres tat ich: Einige Administratoren reagierten schnell, andere wissen nicht einmal, dass man eine IP manuell whitelisten kann - was mich nicht wirklich verwundert, wenn man seine Emails solch einer "Appliance" überlässt.
Recht beruhigend finde ich, dass die Großen, wie UnitedInternet, Google, Microsoft (inkl. deren Hosted Exchange) andere Lösungen einsetzen.