Sebastian Kraus — 14.12.2015
Wir stellen seit einiger Zeit auf mehreren unserer Server fest, das E-Mail an Microsoft-E-Mail-Dienste nicht zustellbar ist. Nachfolgend einige Ausführungen dazu.
Die ticktoo Systems GmbH ist technisch gesehen ein Internet Service Provider (ISP). Wir bieten dem Kunden gegen Entgelt die Möglichkeit, E-Mail-Postfächer bei uns zu betreiben und stellen hierfür die erforderliche Infrastruktur bereit. Mailserver oder SMTP-Server sind seit den späten 1980’er Jahren ohne größere Änderungen am eigentlichen Protokoll in Betrieb und alle Server spielen nach denselben Spielregeln, die in verschiedenen RFCs (Request for Comments) niedergeschrieben sind. Dadurch ist es möglich, dass ein Kunde von t-online.de einen Kunden von web.de per E-Mail erreichen kann, ohne dass dieser sich näher um die technischen Details kümmern muss.
Die für den E-Mail-Transport relevante RFCs, nämlich der RFC 821 (aus 1982) sowie die Erweiterung RFC 5321 (aus dem Jahr 2008) regeln präzise, wie sich Mailserver bei der Kommunikation untereinander zu verhalten haben (die Protokollebene), sowie organisatorische Maßnahmen, die neben der eigentlichen Implementierung der Software stattzufinden haben (welche E-Mail-Adressen muss ein ISP zwingend akzeptieren, z.B. abuse@example.com oder postmaster@example.com).
Grundsätzlich ist jeder Betreiber eines solchen SMTP-Servers aber in der Lage, diesen Dienst nach Tageslaune zu konfigurieren und niemand ist verpflichtet, E-Mails von irgendjemandem anzunehmen. In diesem Fall muss allerdings dennoch das Protokoll eingehalten werden. Wenn ein Mailserver eine Mail also ablehnt, weil er beispielsweise den Verdacht hat, dass die Mail Spam enthält oder er den Empfänger der E-Mail gar nicht kennt, so hat er dem einliefernden Mailserver das mitzuteilen. Das erfolgt über Statuscodes wie z. B. 550 (Mail rejected), 450 (Temporarily suspended) oder - im Erfolgsfall - 250 (Mail accepted).
Wenn ein Mailserver die E-Mail-Annahme mit 550 (Rejected) verweigert, ist das sein gutes Recht. Der einliefernde Mailserver hat darauf zu reagieren und dem Absender der E-Mail wird ein sog. Non-Delivery-Report zugestellt, der ihn darauf hinweist, dass die Mail nicht zustellbar war. So weit, so gut.
Microsoft macht das anders. Microsoft akzeptiert E-Mail mit dem Statuscode 250, kommt aber offenbar später zu der Ansicht, dass sie jetzt doch keine Lust haben, die E-Mail zuzustellen und unterschlägt diese einfach. Dieses Verhalten ist nicht nur ein grober Verstoß gegen die einschlägigen RFCs aus Protokollebene, sondern ist auch juristisch höchst problematisch, da der einliefernde Mailserver nicht erkennen kann, dass die Mail nicht zugestellt wurde.
Microsoft bietet auch keine praktikable Möglichkeit für einen ISP, Kontakt aufzunehmen und zu erfahren, warum die E-Mails nicht zugestellt werden. Das wiederum ist erneut ein Verstoß gegen die RFCs, nämlich auf der organisatorischen Ebene. E-Mails an postmaster@hotmail.com werden mit einem Autoresponder beantwortet, der erklärt, dass E-Mails an diese Adresse nicht gelesen werden. Dasselbe gilt für E-Mails an abuse@hotmail.com. In den RFCs steht jedoch klar drin, dass das so nicht geht.
Da wir als ISP dieses Problem nicht umgehen können, müssen wir leider derzeit allen Kunden von Microsoft nahelegen, den Provider zu wechseln und ihr Postfach bei einem beliebigen anderen ISP zu betreiben.
Dabei ist es egal, ob man zu T-Online, Web.de, Gmail oder einem kleineren ISP wie uns geht. Soweit wir es sehen, halten sich alle anderen relevanten Provider an die RFCs, obwohl mitnichten jeder Provider Mails ohne Probleme akzeptiert. Wenn er sie aber akzeptiert, stellt er sie auch zu, wenn auch nur in einen Junk-Ordner.
Wir fordern Microsoft auf, dieses Verhalten unverzüglich zu ändern. Und ja, die Hoffnung stirbt zuletzt.