UCEPROTECT, Telekom und Amazon

Ende 2019 wollte ich von meinem Exchange Online Postfach eine Mail an einen Interessenten senden, dessen Domäne bei der Telekom gehostet wird. Die Telekom hat die Mail abgelehnt. Hier ein Bericht der Fehlersuche.

Die Fehlermeldung

Relativ kurz nach dem Versand der Mail kommt die Unzustellbarkeit von meinem ausgehenden SMTP-Relay. So eine Meldung alarmiert mich natürlich, denn eigentlich whrt NoSpamProxy nicht nur eingehende Spam-Nachrichten sehr gut ab sondern filtert auch ausgehende Nachrichten. Es ist daher sehr unwahrscheinlich, dass das System auf einer RBL-Liste landet.

Also habe ich mich auf den Weg gemacht, die Ursache zu finden. Die Gegenseite ist hier wohl ein Mailserver der Telekom, der ein Problem mit der IP-Adresse 18.184.69.25 hat. Der MX-Check zur Domäne zeigt auch, dass der Empfänger anscheinend die Mailserver der Telekom als Eingangssysteme nutzt.

Der Text "(BL)" ist ein Hinweis, dass die einliefernde Adresse auf einer Blocklist steht. Leider verrät die Telekom nicht, welche Liste ursächlich ist. Auch eine Suche im Internet gibt kaum weitere Informationen. Ich habe also den Hinweis genutzt um eine Mail an den Postmaster zu senden. Schon am nächsten Tag kam die Antwort.

Auszug aus der Antwortmail der Telekom

> Bedauerlicherweise sind Teile der diesen IP-Adressen übergeordneten
> Netzbereiche wegen Beschwerden und Unregelmäßigkeiten bei unserem
> System gelistet. Wir werden jedoch veranlassen, dass die Reputation der IP-
> Adressen in unserem System resettet wird. Berücksichtigen Sie bitte, dass es
> bis zu 24 Stunden dauern kann, bis die Änderung wirksam wird,
> erfahrungsgemäß dürfte dies allerdings in ein bis zwei Stunden erledigt sein.
> 
> Ein Zusammenhang mit einem Listing bei UCEPROTECT besteht hier also
> nicht.

Zudem hat die Telekom durchaus eine interessante und umfangreiche Beschreibung zum Betrieb ihres Mailservers.

Das ist eine überraschend ausführliche Beschreibung zu Fehlern und möglichen Analysen aber kommt mit etwas vor, als wenn die Beschreibung seit Jahrzehnten nicht überarbeitet wurde.

RBL-Check mit MXToolbox

Über die Webseite MXTOOLBOX.com kann sehr einfach ein Report erzeugt werden, auf welchen üblichen RBL-Listen eine IP-Adresse steht. Die Ausgabe von https://mxtoolbox.com/SuperTool.aspx?action=Blocklist%3a18.184.69.25&run=toolpage liefert auch schnell die Antwort:

Von 93 abgefragten Blocklisten haben zwei nicht geantwortet und UCEPROTECTL3 liefert den einzigen Treffer. Wie sie aber aus der später eingetroffenen Antwort der Telekom weiter oben sehen können, ist dieser Eintrag nicht Ursächlich für die Sperre. Telekom nutzte als zu dem Zeitpunkt UCEPROTECT nicht.

Man kann so arbeiten aber meine Erfahrung zeigt, dass man immer mehrere Listen befragen sollte und sich nicht einen Einzeltreffer schon als Kriterium nutzt. Zumal die UCEPROTECTL3 in Verbindung mit dem Absender noch eine besondere Eigenschaft hat, auf die ich weiter unten eingehe.

RBL-Check mit uceprotect.net

Über die Detail-Seite von MXTOOLBOX erfahre ich dann mehr über das Verhalten von UCEPROTECT und den Link zur Liste selbst. Da kann ich meine Adresse auch noch mal im Detail prüfen lassen. Auch diese Auswertungen sind sehr ausführlich und helfen bei der Eingrenzung.

http://www.uceprotect.net/de/rblcheck.php?ipr=18.184.69.25

Das System berichtet, dass die IP-Adresse 18.184.69.25 zu Amazon (ASN 16509) gehört und anscheinend hat Amazon wirklich ein Problem mit AWS-Instanzen, die zum Versand von Spams genutzt werden oder aufgrund von Konfigurationsfehlern als "Offene Relays" genutzt werden.

Das System irrt aber hinsichtlich der Warnungen zu falschen DNS-Einträgen. Natürlich stimmen die Einträge, wie ein NSLOOKUP auch liefert.

C:\>nslookup 18.184.69.25
Server:  fritz.box
Address:  fd00::cece:1eff:fe34:3d04

Name:    cloudmx.netatwork.de
Address:  18.184.69.25


C:\>nslookup cloudmx.netatwork.de
Server:  fritz.box
Address:  fd00::cece:1eff:fe34:3d04

Nicht autorisierende Antwort:
Name:    cloudmx.netatwork.de
Addresses:  18.184.69.25
          52.28.162.13

Allerdings kann deren System wohl nicht damit umgehen, dass ein A-Records auch mehrfach vorhanden sein können, um über DNS Round Robin eine Lastverteilung und Verfügbarkeit zu erreichen. Der Reverse-Eintrag einer IP-Adresse kann nur auf einen Namen verweisen. Hier kann ich also nichts korrigieren. Wenn ich den Tests mehrfach mache, dann wird die Konfiguration mal als "Fehler" oder mal als "Korrekt" angezeigt. Anscheinend hängt es von der Antwort auf die DNS-Abfrage zum Namen ab.

UCEPROTECT unterscheidet drei Level, die auf der Webseite auch beschrieben werden.

  • Level1: IP-Adresse
    Hier würde die einzelne IP-Adresse auf Spam bewertet. Hier ist meine Adresse nicht gelistet
  • Level2: IP-Subnetz
    UCEPROTECT gruppiert alle IP-Adressen eines Subnetz und zählt die Spam-Messages. Auch dieses Subnetz ist nicht gelistet, wenngleich 5 IP-Adressen in der Nachbarschaft wohl erwischt wurden.
  • Level 3: Carrier ASN
    Zuletzt bewertet UCEPROTECT noch alle IP-Adressen, die dem BGP-Netzwerk des Providers zugeordnet sind. Das ASN wird gelistet, wenn in 7 Tagen mehr als 100 IP's aber mindestens jedoch 0.2% aller der AS-Nummer enthaltenen Adressen erscheinen. Amazon wird aber gelistet, weil es noch ein hartes Limit bei 10.000 Einträgen in 7 Tagen gibt. UCEPROTECT dürfte dann davon ausgehen, dass der Provider groß genug ist um aktiv gegen Spam zu kämpfen und auch das Know-how dazu haben sollte.

Die Funktion der Level1/2 Filterung kann ich verstehen aber auch die Level 3 Filterung zum Abstrafen des kompletten BGP-Netzwerks kann in vielen Fällen funktionieren. Allerdings ist das harte Limit bei 10.000, welches früher wohl sogar noch niedriger lag, für XXL-Hoster immer noch zu niedrig angesetzt.

Auswirkungen

Der Kampf gegen Spam ist eine wichtige Aufgabe um das E-Mail halbwegs nutzbar zu betreiben. Wir wissen das, da wir mit NoSpamProxy selbst einen Spamfilter entwickeln und damit nahe am Puls sind. Der Einsatz von Block-Listen ist eine wichtige Technik, um mit relativ geringem Aufwand die Zustellung von vielen nicht vertrauenswürdigen Systemen zu unterbinden. Dazu zählen insbesondere private Clients mit dynamischen IP-Adressen.

Selbst die komplette Blockierung eines Providers klingt erst mal nach einem guten Plan, da damit der betroffene Provider gefordert ist gegen die Spammer in seinem Kundenkreis vorzugehen. Das beschreibt UCEPROTECT auch sehr ausführlich auf ihrer Webseite.

Im Grunde stimme ich mit den meisten Aussagen überein und natürlich könnte Amazon den Versand per SMTP generell erst einmal drosseln oder eine explizite Freischaltung einführen und so den Missbrauch verhindern. Azure hat wohl genau daher die Funktionseinschränkung auf SMTP.

Bei Level 3 ist der Provider gefordert, aus der Liste wieder entfernt zu werden. Das kann er aber nicht einfach mit Droh-Mails, auch wenn es speziell kleinere Firmen immer wieder versuchen (Siehe http://www.uceprotect.org/cart00neys/index.html). Wenn man sich die "Top 5" anschaut, dann sieht man die Verteilung

Interessant fände ich in der Liste aber noch eine Angabe, wie groß das ASN ist und wie viel Prozent der Systeme als Spammer klassifiziert sind. Denn auch wenn 10.000 Hosts als harte Grenze Sehr viel erscheint, muss man bedenken, dass Amazon "31.550.208" IP-Adressen hat und die Statistik zeigt, dass Amazon durchaus etwas dagegen tut.

Die Zahl von 18.000 IP-Adressen erscheint hoch aber im Vergleich zu den 31 Mio Adressen im ASN 16509 sind das dann doch wieder nur 5 Promille, und selbst wenn Amazon nicht alle Adressen aktiv haben wird, dürften andere Provider mehr Probleme haben. Der Webhoster 1&1, bei dem die MSXFAQ hinterlegt ist, hat angeblich nur 550400 IP-Adressen im ASN 8560. Allerdings ist da die Schwelle dann doch mit 1101 erlaubten Hosts doch niedriger.

Aber alles lamentieren hilft nicht, denn UCEPROTECT hat sich solche Grenzen definiert und ist schon viele Jahre damit im Markt. Provider müssen endlich lernen, dass sie aktiv gegen Spammer vorgehen müssen und das gilt auch für XXL-Provider. Die haben auch eher die rechtlichen Mittel die Verursacher in Haftung zu nehmen. Und letztlich hat auch der Betreiber des Zielservers die Wahl, ob er UCEPROTECT Level 3 mit in seine Bewertung mit einbezieht.

Als Provider oder Einzelversender kann man die Adresse in einer "Allowlist"-Datenbank von UCEPROTECT hinterlegen.

Diese Service ist allerdings nicht kostenfrei und ist kein Freibrief dann zu Spammen sondern ein einmaliges Entfernen aus der Liste. Für einen Provider, über den viele Kunden nicht mehr senden können, ist der Preis kein Problem, da er mit seinen Kunden auch Geld verdient. Er kann ja den Spammer in seinem Netzwerk dingfest machen.

Einschätzung

Auf den ersten Blick könnte man meinen, dass Amazon AWS als Plattform für den Betrieb von Mailsystemen keine gute Wahl wäre. Auf der anderen Seite senden wir von Net at Work sehr viele Mails über längere Zeit über diese Plattform und diese Analyse war der erste Fall, bei dem ausgehende Mails anhand einer Blockliste nicht zugestellt wurden. Es handelte sich dabei auch nur um bislang eine Zieldomäne, die auch noch bei der Telekom betrieben wird. Da stelle ich mir natürlich schon einige Fragen.

  • Ist die Listung von Amazon AWS nur temporär?
    Kein Provider will als Spammer tituliert werden und Spammer zahlen relativ wenig im Vergleich zur Systembelastung, Bandbreitenbedarf und Supportaufwand durch Abuse-Mails. Also wird jeder Provider von sich aus schon gegen Spammer vorgehen. Vielleicht ist der Fall nur daher aufgetreten, dass wenige Spammer mit Amazon AWS-Instanzen kurzfristig missbraucht haben. Die zurückgehende Anzahl in der Statistik könnte man so interpretieren, dass Amazon etwas tut aber leider geht die Statistik nicht über mehr als 100 Stunden.
  • Wie viele UCEPROTECT-Gegenstellen gibt es?
    Ich gehe mal davon aus, dass alle von UCEPROTECT kommerziell installierten Spam-Appliances auch die UCEPROTECT Datenbank nutzen. Dann scheinen es aber nicht so viele Installationen zu sein, dass es einen merklichen Einfluss auf den Mailübertragungen hat. Oder viele Mailserver nutzen UCEPROTECT nicht, obwohl die Abfrage ja sogar kostenfrei (Privat und kommerziell) ist. Es könnte aber auch einfach sein, dass Level 3 bei vielen doch nicht aktiv ist.
  • Wie viele Kunden sind bei der Telekom
    Da alle Telekom-Kunden per MX-Record die gleichen Systeme nutzen, dürfte zu dem Zeitpunkt keine Mail vielen Amazon AWS-Instanz zu Kunden bei der Telekom erfolgreich zugestellt worden sein. Entweder passiert das sehr selten oder die Anzahl der noch bei T-Online gehosteten Domains ist mittlerweile überschaubar, denn ansonsten dürfte das schon den ein oder anderen Support-Anruf bei der Telekom bedeutet haben
  • Level3 und Groß-Provider
    Früher hat ein Kunde seine IP-Adressen gehabt aber wenn Millionen Firmen z.B. mit Office 365 arbeiten, dann wird es immer passieren, dass durch Phishing einige Postfächer "gekapert" sind. Auch wenn Microsoft z.B. ein "Sendelimit" pro Postfach hat (3600 Mails/h) kann ein Spammer doch ausreichend Mails senden, die auch über unterschiedliche Quell-IP Adressen im Internet ankommen, so dass der Provider irgendwann unweigerlich auf der UCEPROTECT Level-3 Liste landet. Da hilft es auch wenig, wenn der Provider dann gegen Geld den Eintrag schneller entfernen lässt. Hier sind 7 Tage Zeiten aus meiner Sicht zu lange. Das sollte jemand wissen, der IP-Adressen aufgrund von kompletten Netzwerkbereichen blockt.

Zwei Herzen schlagen in meiner Brust denn auf der einen Seite habe ich mich auch dem Kampf gegen Spam verschrieben und stimme in vielen Aussagen mit UCEPROTECT überein. Vielleicht täte der Webseite eine Überarbeitung bezüglich der Sprache gut. Ich kann aber nicht verstehen, dass es keine Abstufung der Grenzwerte nach der Größe der BGP-Netzwerke gibt, denn das Risiko ist aus meiner Sicht schon sehr groß, dass speziell größere Provider zu schnell auf der Blockliste landen. Zumal es auch keinen Gegencheck gegen SPF/DKIM gibt.

Hier verhält sich NoSpamProxy etwas intelligenter, indem neben der IP-Adresse auch Absender und Empfänger und weitere Kriterien einbezogen werden. So kann man dann durchaus noch die guten Mails aus einer Verbindung rausfischen, selbst wenn die IP-Adresse im Grunde schon vorbelastet ist. Denn auch wenn Provider auch gegen Spammer arbeiten, wird es gerade durch gekaperte Konten, Trojaner etc. immer mal wieder passieren, dass über einen Mailserver Spam versendet wird.

Allerdings kann ein Provider natürlich auch ausgehende SMTP-Verbindungen durch einen Spamfilter jagen, indem er seinen Kunden ein SMTP-Relay anbietet, welches die Kunden nutzen müssen. In den meisten Fällen ist das kein Problem. Nur wenn Kunden wirklich eigene SMTP-Dienste z.B. als virtuelle Maschine bei einem Provider betreiben wollen und ausgehend auch noch SMTP/TLS machen, ist der Provider nur noch Plattformanbieter und im Risiko, dass seine IP-Subnetze ein schlechtes Rating bekommen.

UCEPROTECT bietet quasi nur drei Listen an aber der Admin des empfangenden Servers bestimmt letztlich, welchen Listen er wie vertraut.

Temporäre Lösung

Ich habe uns erst mal so geholfen, dass wie Mails an diese Domäne einfach an Amazon vorbei senden, bis Amazon wieder aus dem Rating herausgefallen ist. Auf der anderen Seite zeigt dies aber, dass speziell die Eigenüberwachung der eigenen ausgehende Mailserver gegen häufige Blocklisten durchaus wichtig ist. Denkbar wäre aber auch, dass ein Mailversender eine 554-Meldung der Gegenseite zumindest "mitzählt" und einem Administrator bei einer Zunahme Bescheid gibt. Dann könnte das System die Mails auch erst mal in eine Backlog-Queue legen und trotz einem 5xx-:Fehler, der eigentlich einen permanenten Fehler anzeigt, später noch mal einen Retry versuchen. Es würde den Anwendern ein erneutes Senden ersparen.

Hinweise für Mailserver-Betreiber und Hoster

Wer einen Mailserver oder Spamfilter betreibt und Mails versendet, muss immer mal damit rechnen, dass er auf einer Block-Liste landet. Ob "zurecht" oder irrtümlich ist dann nicht relevant, weil ihre Anwender der Kunden keine Mails versenden können. Daher sollten Sie ihren Mailbetrieb schon entsprechend regulieren, z.B. mit

  • Throttling
    Spammer wollen schnell viele Mails senden, ehe sie auf Listen landen. Normale Anwender senden aber eher wenige Mails und auch Office 365 hat entsprechende Limits pro Absender (Siehe Exchange Online Message Rate Grenzen, 30 Mails/h pro Benutzer). Ihr System sollte überaktive Clients entsprechend drosseln um das Risiko einen Missbrauchs und Sperrung zu reduzieren.
    Eine Software könnte etwas wie ein "Budget" einführen, welches die Anzahl der Empfänger, Anzahl der Mails und Größe einbezieht. Es kann ja immer mal ein Postfach missbraucht werden.
  • RBLs überwachen und 554 Rate erkennen
    Wichtig ist schnell zu erkennen, ob das eigene System auf einer Block-Liste gelandet ist. Sie können ganz einfach die aus ihrer Sicht relevanten Blocklisten dazu befragen. Denkbar ist aber auch einfach die Anzahl der 5xx-Fehler beim Versand pro Zeiteinheit zu oder Zielsystem zu messen, da diese dann hochschnellen sollten.
  • Backup-Route / IP-Adress-Wechsel
    Wenn ihre IP-Adresse gelistet ist dann sollten Sie zuerst den internen Verursacher ausfindig machen und blockieren. Je nach Blocklist können Sie dann ihre IP per Webformular oder wie bei UCEPROTECT gegen Geld wieder freikaufen. Alternativ ändern Sie ihr Mailrouting über eine andere IP-Adresse oder einen anderen Proxy. Aufgrund der UCEPROTECTL3-Liste kann es sein dass Sie dann sogar über einem anderen Provider gehen müssen.
  • Keine NDRs nach extern
    Auf der Seite NDR-Backscatter habe ich schon das Problem beschrieben, dass ein Mailserver eingehende Nachrichten am besten gleich ablehnt aber nie einen NDR sendet. UCEPROTECT wertet auch solche Hosts aus. Siehe http://www.backscatterer.org/?target=bounces
  • Blocklisten von Zieldomains und Spamtraps
    Spamfilter müssen Spammer zuverlässig erkennen. UCEPROTECT nutzt dazu ihre eigene Appliance bei Kunden und natürlich Spamtraps, d.h. Server und Mailadressen, die von regulären Absendern nie eine Mail erhalten sollten, es sei denn es ist ein Spammer, der die Adressen eingesammelt hat. UCEPROTECT beschreibt, dass sie extra eine Domain "nirvana.admins.ws" betreiben, auf die auch andere "Trap-Domains" geleitet werden können. Zudem werden Mailadressen wie "liste-mich@fast9.uceprotect.net" auf Webseiten für "Crawler" hinterlegt. Klingt wie eine gute Idee aber was hindert mich bei einem Firma so eine Adresse in einem Kontaktformular abzulegen. Sobald die Firma dann mich kontaktiert, ist deren Server geblockt. Eine gute Idee ist nicht immer die beste Idee.
    Daher sollte ein Spamfilter ausgehende Mails an bekannte Trap-Domains blockieren.

So wie die Spamerkennung und der Spamversand einen kontinuierlichen Wettbewerb sich liefern, müssen auch Mailserver ihre ausgehenden Mails immer wieder anpassen und optimieren. Die Welt wäre so schön, wenn alle Absender ihre Server per SPF/DKIM/DMARC kennzeichnen und Mails am besten noch digital signieren. Anonym wäre das dann nicht mehr und es hilft nicht gegen Domain-Diebe und Vertipper-Domains. Auch die Spammer werden also nicht morgen einfach verschwinden.

Weitere Links