Sehr geehrte MSDN Flash-Abonnenten,
Die Wirkung eines Punktes
Man konnte es in Foren und Weblogs lesen und wir haben natürlich sehr viel Post und Feedback bekommen: Mit dem letzten MSDN Flash Newsletter ging etwas schief. Jetzt – da der Staub sich legt – wollen wir zunächst einmal uns bei allen Betroffenen ganz herzlich entschuldigen. Daneben wollen wir aber auch kurz aufzeigen, was die Ursache war und wie wir diese schlussendlich gefunden haben. Ohne Hilfe von vielen Seiten hätten wir es wahrscheinlich nicht geschafft, insbesondere möchte ich mich hier bei der Firma Strato und allen beteiligten Mitarbeiten für die ausnahmslos hervorragende und professionelle Zusammenarbeit bedanken. Also ein Dank auch an all diejenigen, die sich die Nächte um die Ohren geschlagen haben. Und – um es gleich vorweg zu nehmen – es war ein einfacher Punkt.
Am Montag (18.05.2009) haben wir wie in den letzten Jahren alle zwei Wochen unseren Newsletter-Text aus der Redaktion ins Publishing gegeben. Für Newsletter gibt es bei Microsoft ein Tool namens PENS, das neben der Fähigkeit Massen-Emails zu schreiben auch eventuelle Rückläufer zu bearbeiten und vor dem Versand die Adressen u.a. mit der Robinson-Liste der gesperrten Adressen zu vergleichen. Der PENS-Job lief also los und wir waren froher Dinge. Kurz darauf kamen die ersten Meldungen bei uns an, dass einige Empfänger den Newsletter nicht einmal zugestellt bekommen hätten, sondern dutzende Male. Also haben wir angefangen nachzuforschen und bis am Abend konnte ich folgendes feststellen: E-Mail-Accounts von Kunden des Hoster Strato erhielten den Newsletter in großer Menge mehrfach, bei allen anderen Empfängern lief die Zustellung unserer Kenntnis nach ohne Probleme. Dazu haben wir weiterhin viele uns bekannte Empfänger angerufen und dies verifiziert.
Der nächste Schritt war, Kontakt mit dem Hoster und unserem PENS-Engineering-Team herzustellen. Zum Glück hatten wir unseren Kollegen, der den Hoster als Microsoft-Kunden betreut, gleich an der Strippe und er konnte uns die richtigen Kontakte nennen. Was wir also herausbekamen war folgendes: Eine große Menge von Kunden bekam den Newsletter stetig wieder zu gestellt. Alle Adressen liegen bei diesem Hoster. Einen solchen Effekt haben wir weltweit sonst noch nie beobachtet (und unser E-Mail-System PENS sowie die E-Mail-Server des Hosters sind seit Jahren in Betrieb und kommunizierten und kommunizieren einwandfrei miteinander). Alle Systeme des Hosters liefen aber normal.
Wir haben daraufhin in der deutschen Niederlassung von Microsoft die Zustellung aller Newsletter bis auf Weiteres gestoppt.
Am Dienstagmittag hatte sich die Situation leider nicht verbessert und wir drückten den „roten Knopf“. Wir haben also eine Notfall-Anfrage an unser weltweites Engineering-Team über einen internen E-Mail-Verteiler gesendet, der einen sofortigen Alarm auslöst. Das PENS System meldete uns sogenannte Soft Bounces (Server melden "E-Mailpostfach voll etc.", "eine spätere Zustellung wird probiert"). Um dies herauszubekommen, mussten wir die PENS-Logs (und die sind groß) nach Job-Nummer und Email-Adressen durchsuchen lassen und die Meldungen in die zeitlich richtige Reihenfolge bringen. PENS wollte also Emails zustellen und bekam vom Hoster-System eine Fehlermeldung. Im Gegenzug versicherte uns der Hoster, dessen Techniker ihre Logs und diverse Quellen durchforsteten, dass jeder Sendeversuch durch seine Systeme positiv abgeschlossen würden und vielmehr PENS immer weiter zustellen würde. Ununterbrochen suchten wir weiter nach der Fehlerquelle.
Mittlerweile war es Mittwoch und wir hatten einige Fakten. Aber irgendwie war allen Beteiligten immer noch nicht klar, wie das alles nun zu erklären wäre. Das PENS-System zu stoppen, war keine Option, weil es auch für die Zustellung von sicherheitsrelevanten Newslettern/E-Mailbenachrichtigungen und andere weltweite Kommunikation zuständig ist. Es wurde weiterhin fieberhaft und mit allen verfügbaren Mitteln versucht, die Fehlerquelle abzustellen. Für alle Beteiligten zeigte sich ein einmaliges Verhalten auf: Alle Systeme meldeten unisono eine fehlerfreie Kommunikation und unsere Systeme arbeiteten seit Jahren entsprechend fehlerfrei zusammen. Es wurden sämtliche noch so unwahrscheinliche Fehlerquellen akribisch untersucht und weiterhin arbeiteten wir daran, die Mehrfachzustellungen zu unterbinden.
Also hatten wir eine weitere Telefonkonferenz – die größte bisher mit insgesamt etwa 20 Personen: Techniker des Hosters, Leute aus dem Developer-Bereich von Microsoft Deutschland und verschiedene Techniker und Manager von PENS aus den USA und Indien. Donnerstag war Feiertag (Christi Himmelfahrt) in Deutschland und ich muss nochmal allen Beteiligten meinen Dank aussprechen. Die Techniker des Hosters haben am Feiertag eine Nachtschicht eingelegt und die Leute von Microsoft in Deutschland hatten seit Montag 'eh schon kaum mehr Schlaf bekommen.
Das PENS-System war vor seinem fünften und letzten Zustellversuch. Dann würden nur noch die Fehler ins Log geschrieben werden und der Spuk wäre vorbei. Doch was hat ihn ausgelöst und wie stellen wir sicher, dass er nicht nochmal auftritt? Schlussendlich haben die Techniker des Hosters und Microsoft in der Nacht auf Freitag den Grund (ich mag das mal nicht Fehler nennen) gefunden und gegen Mittag deutscher Zeit abgestellt.
Über das Wochenende prüften wir mit diversen Mitteln und Test-Accounts sowie weiteren Testversendungen die Maßnahme und können nun am Montag, 25.05.2009 bestätigen, dass keine Mehrfachversendungen mehr stattfinden.
Was war es jetzt?? Ein simpler Punkt
Das PENS-System schickt auf Basis von SMTP (Simple Mail Transfer Protocol) seine Emails. SMTP trägt seinen Namen zu Recht – es ist simpel. Der Informatiker sieht darin einen endlichen Automaten, der verschiedene Zustände annehmen und zwischen diesen Zuständen wechseln kann. Im Prinzip ist SMTP eine Telnet-Verbindung auf einem bestimmten Port (nämlich 25), bei dem der Sender immer Kombinationen aus Befehl und Argumenten schickt. So gibt es den Befehl „MAIL FROM:“ mit dem Argument „Absenderadresse“. Der Empfänger schickt immer einen Quittungscode, der den Status angibt. Im Laufe einer Übertragung kommt dann schlussendlich der Befehl „DATA“. Hier beginnt der Körper (sozusagen der eigentliche Inhalt) der Email und der empfangende Server wechselt in einen Modus, bei dem er solange Text empfängt, bis das Schlusssignal geschickt wird. Ein einzelner Punkt in einer Zeile.
PENS versucht in diesem Textkörper die volle Länge eines TCP-Paketes pro Zeile zu verwenden. Das macht für einen Massenmailer auch total viel Sinn. Gemäß RFC-Standard 2821 ist das auch ok... oder auch nicht. Denn wie der RFC auch so schön schreibt, gibt es Server die sich anders verhalten als andere. Der Hoster Strato hat z.B. Load-Balancer vor seinen Mail-Servern, die die Zeilen in jeweils so um die 1.000 Zeichen umbrechen, was der ursprünglichen SMTP-Definition entspricht.
In unserem Fall (und ich werde nicht versuchen auszurechnen, wie hoch die Wahrscheinlichkeit war) hat es sich so ergeben, dass durch den Umbruch aus einer Zeile eine zweite entstand, die genau einen Punkt enthielt (plus CR und LF genau genommen). Das ist aber das Stopsignal für den DATA-Bereich. Der Empfänger-Server meldete daraufhin ein „OK, Nachricht erhalten und zugestellt“. Dies hat aber das absendende PENS-System nicht wahrgenommen. Schließlich sind wir doch in einem endlichen Automaten und dieser Status hätte nicht vorkommen dürfen. Wir waren doch mitten in der Nachrichtenübertragung. PENS hat also weitere Textzeilen übertragen, die vom Empfänger salopp gesagt mit „Hä?“ beantwortet wurden. PENS hat die Nachricht bekommen und musste davon ausgehen, das die Zustellung schief ging. Also nochmal probieren. Daher hatte PENS Soft-Bounce-Fehler und im Log des Hosters waren nur OKs.
Betrachtet man die Situation auf diese Weise, hat man geradezu einen klassischen Fall nach Murphys Gesetz. Auf jeder Seite wird das System als in einem bestimmten Zustand angenommen. Weil der Datenkanal auch der Kontrollkanal ist, konnten Daten als Befehle interpretiert werden und so der Zustand von Sender und Empfänger unterschiedlich sein. Wie gesagt: SMTP ist simpel.
Für die betroffenen Empfänger ist das wenig Trost. Man musste vollgelaufene Postfächer von endlosen Kopien des gleichen Newsletters säubern.
Uns bleibt im Moment nur, uns dafür zu entschuldigen. Wir haben eine Woche lang Tag und Nacht an diesem Problem gearbeitet. Wir sind sehr froh über die Hilfe, die absolut sehr gute Zusammenarbeit sowie den ausnahmslos professionellen Support des Hosters gewesen und haben schließlich den Fehler identifiziert und behoben.
Vielen Dank auch an diejenigen, die uns auf die Tatsache aufmerksam gemacht haben. Ehrliche und offene Kritik ist nicht selbstverständlich. Ich hoffe, dass Sie unserem Newsletter trotzdem treu bleiben. Seine Zustellung ist jetzt um eine Kleinigkeit besser geworden.
Ich bitte alle betroffenen Newsletter-Abonnenten nochmalig um Entschuldigung und Verständnis, ich kann Ihnen persönlich versichern, dass wir alle notwendigen Schritte sehr zeitnah eingeleitet haben.
Weiterhin möchte ich mich hier bei der Firma Strato und allen beteiligten Mitarbeiten für die ausnahmslos hervorragende und professionelle Zusammenarbeit bedanken.
Nach der Einführung der oben genannten Maßnahmen sowie der Qualitätssicherung über das Wochenende sowie unserem jetzigen Kenntnisstand nach, dürften Sie diesen speziellen Newsletter nicht noch einmal (doppelt bzw. mehrfach) erhalten.
Viele Grüße aus Unterschleißheim,
Kay Giza
Audience Marketing Manager & MSDN Online Lead | Developer Platform & Strategy Group | Microsoft Deutschland GmbH
PS: Die Beiträge die hier an dieser Stelle standen (in denen ich seit Montagmorgen letzter Woche über den aktuellen Stand berichtete) sind der Übersicht wegen gelöscht und archiviert worden.
