Anders kann man es nicht ausdrücken. Desaster bedeutet: ab und an kommen E-Mails meines Mailservers nicht mehr an. Aber der Reihe nach.
Die Zutaten
- Einen eigenen Mailserver
- Einen fremden Mailserver (in diesem Fall T-Online)
- Einen DNSBL-Betreiber (in diesem Fall backscatterer.org)
- Einen Admin, der seine Mailserver toll vor Spam schützen will
Vorbereitungen
Mein Mailserver hat diverse Weiterleitungen eingerichtet. In diesem Fall hatte ich eine Weiterleitung von der Sammeladresse mail@foej-aktiv.de u.a. zu einer T-Online Adresse.
T-Online hat meinen Mailserver kurzfristig als Spam erkannt. Das passiert schon mal, ist aber nicht weiter schlimm, solche fehlerhaften Einordnungen werden in wenigen Minuten wieder zurückgenommen – so auch in diesem Fall. Das ist eben der Fluch von einem so hohen Spamaufkommen im Netz: manchmal gibt es übersensible Spamfilter.
Das Desaster begann in dem Moment, als backscatterer.org genau in dem Moment der Sperrung meinen Server auf Backscattering testete. Auch das ist an sich erst einmal kein großes Problem – irgendwie muss der DNSBL-Anbieter ja an seine Daten kommen.
Einschub: Was ist eine DNSBL?
Eine DNS-Blacklist (auch: DNS-based Blackhole List, oder kurz DNSBL) ist eine große Liste an IP-Adressen, die irgendwie auffällig geworden sind. Auffällig sein kann eine IP aus ganz verschiedenen Gründen.
Zum Beispiel gibt es Listen mit allen IP-Adressen, welche an Rechner zu Hause vergeben werden und sich daher regelmäßig ändern. Dort kann man konzeptionell keinen Mailserver einrichten, weil man für diese Einrichtung eine feste IP-Adresse braucht – also ist eine E-Mail, die von einer solchen IP kommt, sehr wahrscheinlich Spam.
Genauso gibt es Listen an Open Relays – das sind Server, die fehlerhaft konfiguriert sind, so dass sie alle E-Mails weitersenden. Auch das ist sehr wahrscheinlich Spam. Es gibt auch Listen, mit irgendwie ein wenig auffälligen IPs, weil z.B. viele Mails gesendet wurde. Das kann Spam sein, kann aber auch einfach nur ein Newsletter sein.
Einschub: Was ist Backscattering?
Jeder kennt diese schönen Meldungen, dass eine E-Mail nicht angekommen ist. Das ist meist ein längerer englischer Text, wo sich das Mailserver-System ausgiebig dafür entschuldigt, dass es die Mail nicht annehmen kann. Mittendrin steht auch die Begründung, warum die E-Mail nicht angekommen ist (Tip: dies lesen, wenn eine Mail nicht ankommt!).
Spammer dachten sich nun: „Hey, wie wäre es, wenn wir diese Zurück-E-Mail nun fälschen und dort statt dem längeren englischen Text einfach unseren Spam reintun?“. Das funktioniert recht gut, wenn der Mailserver nicht darauf achtet, ob die Zurück-E-Mail denn überhaupt möglich sein kann. Die allermeisten Mail-Server achten darauf heutzutage, aber es gibt ja noch genug alte schlecht betreute Server da draußen, also kommt das vor.
Von außen zu erkennen, ob der Mailserver anfällig für Backscattering-Spam ist, ist allerdings gar nicht so einfach, wie wir gleich sehen werden.
Die Zubereitung
Passiert ist dann folgendes. Wir erinnern uns: Mein Server stand kurzfristig auf der T-Online Blacklist. Dann kam diese E-Mail von gdservices.org, dem Betreiber von backscatterer.org. Die wird erst mal zu AMAVIS (127.0.0.1) weitergeleitet:
Jan 23 08:58:30 v00220100127 postfix/smtpd[29643]: connect from unknown[64.15.156.174]
Jan 23 08:59:18 v00220100127 postfix/smtpd[29643]: 96346121603: client=unknown[64.15.156.174]
Jan 23 09:00:05 v00220100127 postfix/cleanup[29648]: 96346121603: message-id=<7668971148563-SYRCMRTHMTNKEZYSWFMLXX@XXXXXXXXXXX.com>
Jan 23 09:00:05 v00220100127 postfix/qmgr[1678]: 96346121603: from=<crboi@gdservices.org>, size=592, nrcpt=1 (queue active)
Jan 23 09:00:06 v00220100127 postfix/smtp[29649]: 96346121603: to=<mail@foej-aktiv.de>, relay=127.0.0.1[127.0.0.1]:10024, delay=52, delays=52/0/0/0.61, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 0FA641215A3)
Jan 23 09:00:06 v00220100127 postfix/qmgr[1678]: 96346121603: removed
Jan 23 09:00:46 v00220100127 postfix/smtpd[29643]: disconnect from unknown[64.15.156.174]Der Mailserver nimmt die Mail von Amavis wieder an:
Jan 23 09:00:06 v00220100127 postfix/smtpd[29651]: connect from v00220100127[127.0.0.1]
Jan 23 09:00:06 v00220100127 postfix/smtpd[29651]: 0FA641215A3: client=v00220100127[127.0.0.1]
Jan 23 09:00:06 v00220100127 postfix/cleanup[29703]: 0FA641215A3: message-id=<7668971148563-SYRCMRTHMTNKEZYSWFMLXX@XXXXXXXXXXX.com>
Jan 23 09:00:06 v00220100127 postfix/qmgr[1678]: 0FA641215A3: from=<crboi@gdservices.org>, size=1652, nrcpt=6 (queue active)Lokales Zustellen via Dovecot klappt wunderbar:
Jan 23 09:00:06 v00220100127 postfix/pipe[29653]: 0FA641215A3: to=<XXXXXXXXXXX@foej-aktiv.de>, orig_to=<mail@foej-aktiv.de>, relay=dovecot, delay=0.07, delays=0.01/0.01/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot service)T-Online schlägt fehl. Man beachte die sehr förmlich-freundliche Fehlermeldung sowie die Tatsache, dass die Meldung auf auf deutsch vorzufinden ist:
Jan 23 09:00:06 v00220100127 postfix/smtp[29788]: 0FA641215A3: to=<XXXXXXXXXXX@t-online.de>, orig_to=<mail@foej-aktiv.de>, relay=mx03.t-online.de[194.25.134.73]:25, delay=0.41, delays=0.01/0.06/0.24/0.11, dsn=5.7.0, status=bounced (host mx03.t-online.de[194.25.134.73] said: 550-5.7.0 Message considered as spam or virus, rejected 550-5.7.0 Your IP: 31.172.42.91 550-5.7.0 Mailhost: mailin63.aul.t-online.de 550-5.7.0 Timestamp: 2015-01-23T08:00:05Z 550-5.7.0 Expurgate-ID: 149288::1422000005-00001883-11AA0BC7/0-15637747320/0-10 550-5.7.0 Authenticator: 58E308786C50A8CCCA86FB840301734DB2D6E09CC795D1F102C0D2791440A576982345E4 550-5.7.0 550-5.7.0 Your message has been rejected due to spam or virus classification. 550-5.7.0 If you feel this is inapplicable, please report the above error codes 550-5.7.0 back to FPR@RX.T-ONLINE.DE to help us fix possible misclassification. 550-5.7.0 We apologize for any inconvenience and thank you for your assistance! 550-5.7.0 550-5.7.0 Die Annahme Ihrer Nachricht wurde abgelehnt, da sie als Spam oder 550-5.7.0 Virus eingestuft wurde. Sollten Sie dies als unzutreffend ansehen, 550-5.7.0 senden Sie bitte obige Fehlercodes an FPR@RX.T-ONLINE.DE, damit wir 550-5.7.0 die Klassifizierung untersuchen k??nnen. Wir entschuldigen uns f??r 550 5.7.0 etwaige Unannehmlichkeiten und bedanken uns f??r Ihre Unterst??tzung! (in reply to end of DATA command))Auch E-Mails an web.de gehen ganz problemlos:
Jan 23 09:00:06 v00220100127 postfix/smtp[29789]: 0FA641215A3: to=<XXXXXXXXXXX@web.de>, orig_to=<mail@foej-aktiv.de>, relay=mx-ha02.web.de[213.165.67.120]:25, delay=0.79, delays=0.01/0.08/0.33/0.37, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=0MGBn1-1YT56I2ghr-00FCe0)Das Unglück nimmt seinen Lauf; Die Non Delivery Meldung wird erstellt und der Sendeprozess abgeschlossen.
Jan 23 09:00:23 v00220100127 postfix/bounce[29709]: 0FA641215A3: sender non-delivery notification: 4EE8F121606
Jan 23 09:00:23 v00220100127 postfix/qmgr[1678]: 0FA641215A3: removedDie Non Delivery Meldung kommt von meinem Server und hat keinen Absender:
Jan 23 09:00:23 v00220100127 postfix/cleanup[29648]: 4EE8F121606: message-id=<20150123080023.4EE8F121606@mail.sectio-aurea.org>
Jan 23 09:00:23 v00220100127 postfix/qmgr[1678]: 4EE8F121606: from=<>, size=6344, nrcpt=1 (queue active)… und sie wird abgelehnt, weil sie genauso aussieht wie Backsquatter-Spam.
Jan 23 09:00:34 v00220100127 postfix/smtp[29787]: 4EE8F121606: to=<crboi@gdservices.org>, relay=mail.gdservices.org[41.208.68.120]:25, delay=11, delays=0.01/0/0.42/10, dsn=5.0.0, status=bounced (host mail.gdservices.org[41.208.68.120] said: 554 We don't take bounces from systems listed at IPS.BACKSCATTERER.ORG (in reply to DATA command))
Jan 23 09:00:34 v00220100127 postfix/qmgr[1678]: 4EE8F121606: removedGanze 17 Sekunden später folgt an dieselbe Mailadresse noch einmal derselbe Test, der identisch ausgeht. Seitdem ist mein Mailserver auf der Blacklist. Obwohl mein server Backscatter-Spam unterbindet – das kann man testen lassen.
Wir lernen: der Test von backscatterer.org ist nicht so richtig aussagekräftig, weil er False Positives produziert. Man könnte die Test-E-Mails mit mehr zeitlichem Abstand senden – oder besser noch: an verschiedene E-Mail-Accounts.
Richtig unangenehm ist es allerdings, dass man gleich vier Wochen auf der Blacklist drauf bleibt. Alternativ darf man 103 € zahlen. Yepeee! Nur so: das finde ich schon ziemlich heftig für einen so kurzen unvollständigen Test.
Der Schritt zum perfekten Desaster
All die Schritte voran wären nicht so schlimm, wenn da nicht noch eine weitere Komponente dazukäme: Mailserver-Admins mit gutem Willen, aber wenig Verständnis für das Thema. Wie sagt man so schön? Der Weg zur Hölle ist mit guten Vorsätzen gepflastert.
In diesem Fall wurde dann die Blacklist irgendwo aus dem Internet kopiert und in die Mailserver-Konfiguration eingefügt. Man möchte ja seine Nutzer vor Spam schützen. Leider hat man so gar keine Ahnung, was diese backscatterer.org eigentlich ist – aber das steht ja im Copy Paste Tutorial, also wird sie eingesetzt.
Die einfachste Methode, eine DNSBL einzusetzen, ist, alle Mails zu blocken, die von Servern auf der DNSBLs kommen. Intelligenter wäre es, mehrere DNSBLs zu gewichten, so dass Mails nur als Spam abgewiesen werden, wenn sie auf mehreren Blocklisten stehen. Das ist wie bei einem Kriminalfall – ein einziges wenn auch schweres Indiz reicht nicht wirklich, aber wenn viele – schwere und leichte – Indizien zusammenkommen, dann wird ein Beweis draus. Die DNSBL backscatterer.org ist ein schwaches Indiz, was aber zusammen mit weiteren Indizien zusammen eine Aussage geben kann. Aber eben nicht alleine, und so setzen übereifrige (oder unfähige) Admins auch schwache Indizien-Listen wie backscatterer.org als Kill-Listen ein.
Dabei würde es reichen, einfach mal auf die Website von backscatterer.org zu schauen:
ATTENTION: ips.backscatterer.org is NOT a spammerlist. It’s a Backscatterer list !!! If you need a spammerlist we recommend using UCEPROTECT.NET instead Keep this in mind before using ips.backscatterer.org: […]As long as you are not a BOFH nor having the intention to boycott such servers we strongly recommend to use ips.backscatterer.org in SAFE MODE to prevent false positives. SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or postmaster only. Used in safe mode ips.backscatterer.org will protect you against misdirected bounces and misdirected autoresponders and sender callouts while you can not lose any real mail.
Da steht ganz direkt, wie gefährlich das ist. Aber: die Blacklist wird trotzdem als Kill-Liste eingesetzt. Damit ist das Desaster perfekt: Auf E-Mail-Servern mit übereifrigen Admins werden E-Mails von meinem Mailserver nun abgewiesen. Was ein Desaster.
Wer ist der Schuldige? Und was lernen wir daraus?
Schuldig an dem Desaster sind vor allem die Admins, die backscatterer.org entgegen der der deutlichen Warnung als Kill-DNSBL einsetzen. Eine kleine Mitschuld hat backscatterer.org. T-Online und mein Mailserver arbeiten im komplett im normalen Bereich.
Lernen sollten daraus vor allem Mailserver-Admins:
- Setze DNSBLs niemals als Kill-DNSBLs ein, sondern nutze eine Gewichtung.
- Lies dir durch, das die jeweiligen DNSBLs bedeuten, und lasse das in die Gewichtung einfließen.
- Kopiere niemals Konfiguration einfach so aus dem Netz.
- Akzeptiere, dass der Betrieb von Mailservern viel Arbeit bedeutet.
- Wenn du nicht die technischen oder zeitlichen Voraussetzungen mitbringst, dann gib die Administration in kompetente Hände. Überlasse niemals einen Mailserver sich selbst!
Aber auch DNSBL- und andere Anbieter von wie auch immer gearteten Dienstleitungen können etwas daraus lernen:
- Nimm das Schlimmste an und erwarte, dass dein Dienst missbräuchlich eingesetzt wird. Und wenn du das noch so groß fett auf deine Homepage schreibst.
- Versuche, aussagekräfte Tests zu machen, bevor du zu einem Schluss kommst.
- Irgendwas bei 100 € bei einem wenig aussagekräftigen Test sind uncool.
Was kann ich als Nutzer tun, dessen Mail nicht ankommt?
Mir eine Mail senden, dann trete ich dem Betreiber des fehlerhaft konfigurierten Mailservers auf den Füßen herum. 🙂
Hallo!
im obigen Beispielt ist aber die Konfiguration offensichtlich fehlerhaft, weil es zu Backscatter kommt.
Fehlerhaft deswegen, weil es genau dieses Verhalten ist, weswegen überhaupt die BackScatter.org liste gegründet wurde. Mailserver welche Mails annehmen, welche sie gar nicht delivern können.
Deswegen ist es auch legitim, wenn die Adresse auf der RBL auftaucht.
Ob man diese und wie man diese verwendet obliegt ja dem Empfänger-Server betreiber, und dessen Vorstellungen.
lg
Natürlich ist das Backscattering nicht in Ordnung, und es ist ok, wenn es dann Blacklists dafür gibt. Den Post hatte ich damals geschrieben, weil es einfach eine unglaublich suboptimale Idee ist, Backscattering-DNSBLs als Spam-Blacklist zu missbrauchen, und dann auch noch als einzige Quelle zu akzeptieren.
Hallo,
ich stimme Herrn Reitmeir zu. Leider wird ja genau dieses Blackscattering von vielen SPAM Bots ausgenutzt. In der heutigen Zeit, in der ich mir einen VPS für 1 Tag mieten kann und eine Fantasie Domain dazu, tausende SPAM Mail verschicke und dann wieder alles kündige, wird es immer schwehrer einen erfolgreichen SPAM Schutz zu etablieren. Deshalb finde ich schon, dass diese Liste ihre Daseinsberechtigung hat
Eine Daseinsberechtigung: absolut. Aber halt nicht als alleinige Entscheidungsgrundlage einer Entscheidung, eben weil es False Positives geben kann.
Allerdings nimmt die Bedeutung von DNSBLs in Zeiten von IPv6 und IPv4-Knappheit (und damit regelmäßigeren Besitzerwechseln einer IP) eh ab. Daher können DNSBLs eh nur noch einer von vielen Hinweisen sein, so nervig das als Admin auch ist.
Mit den meisten Aussagen in diesem Artikel stimme ich überein.
Copy & Paste, ohne zu verstehen was da passiert, ist immer eine schlechte Idee.
Das perfide an Backscattering ist was völlig anderes und es ist nicht der Spam-Inhalt der Bounce Mail:
Hier das Szenario:
Angreifer A schickt tausende von E-Mails mit gefälschten Absender-Adressen an nicht existierende Empfängeradressen deiner Domain.
Was macht ein Backscatter-Server? Der schickt an die gefälschten Absenderadressen ebensoviele Bounce-Meldungen („Empfänger existiert nicht“) und greift damit die Mailserver von Dritten mit tausenden von E-Mails an (zur Erinnerung: die Absender-Adressen waren gefälscht).
So wird der Empfänger selbst zum Täter und genau gegen dieses Vorgehen gibt es Backscatterer Listen.
Wir haben bei uns in der Firma gewichtete Blacklisten, die Backscatterer Liste führt allerdings richtigerweise sofort zur Ablehnung der E-Mail.
Der Test, ob ein Mailserver ein Backscatterer ist, ist sehr einfach und führt so gut wie zu keinen false positives.
Wenn dein Mailserver Bounce-Mails zurück schickt, dann ist das ein Backscatterer, Punkt.
Richtig wäre, wenn dein Mailserver die Test-E-Mail mit einem Reject Code ablehnen würde ohne selbst eine Bounce-Mail zu generieren.
Wer es im Übrigen schafft mehrere Wochen auf einer Backscatterer Blacklist zu sein, der macht grundlegend was falsch. Das heißt, dass ebensolange das Problem unbehandelt geblieben ist.
Nochmal in aller Deutlichkeit – von Mailadmin zu Mailadmin: Es gibt nicht einen einzigen Grund, warum dein Mailserver E-Mails, die er nicht zustellen kann, zuerst annimmt und dann mit einer Bounce-Mail den Absneder benachrichtigt, dass er damit doch nichts anfangen kann.
Das Angriffsszenario kenne ich durchaus. Allerdings ist es mutig, eine einzige DNSBL als Grund für die Ablehnung für irgendwas zu nehmen. Auf allen großen DNSBLs gab es schon False Positives, auch von großen Mail-Providern a la web.de, weswegen es grundlegend eine gute Idee ist, mehr als eine DNSBL als Grund für eine Ablehnung zu geben. Ansonsten weist du bei einem Fehlerfall sehr, sehr viele E-Mails ab und hast ziemlich fluchende Kunden / Mitarbeiter, weil eben nichts mehr von bestimmten Quellen ankommt.
Und dass man kein Backscannering machen sollte: absolut klar. outlook.com tut es aber zum Beispiel, hab ich gerade n aktuelles Beispiel hier rumfliegen, der auf der Backscatter-Blacklist steht: die 40.107.7.113. Kann dann niemand in dem von dir betreuten Unternehmen Mails von outlook.com / Office 365 empfangen?