NE #47: Die 500-Meilen-E-Mail
Dieser Moment, in denen man an seiner Wahrnehmung zweifelt, weil ein Computer, der doch eigentlich nach den strengen Regeln der Logik arbeiten sollte, plötzlich Dinge tut, die gar nicht mehr so logisch erscheinen. Dieser Moment muss 2002 wohl auch Trey Harris ereilt haben [MIT1].
Harris, Mitglied der System Administrators Guild (SAGE), arbeitete als Admin für eine Universität in North Carolina und war dort für das E-Mail-System verantwortlich. Eines Tages rief ihn der Vorsitzende der Statistik-Abteilung an und behauptet, dass seine E-Mails nicht ankommen, sobald der Empfänger mehr als 500 Meilen entfernt sei. Das Problem bestand offenbar schon ein paar Tage. Um es zu dokumentieren, hatte man auf einer Karte markiert, bei welchen Empfänger der E-Mail-Versand funktionierte. Und das funktioniere wohl nur bei Empfängern innerhalb eines 500-Meilen-Radius.
Harris war skeptisch und testete das System selber. Er sendete eine E-Mail nach Richmond, Atlanta und Washington —beide befinden sich innerhalb des 500 Meilen Radius. Ohne Probleme. Und dann nach Memphis — 600 Meilen Distanz. Die E-Mail ging nicht durch. Providence, 580 Meilen. Kein Erfolg. New York, 420 Meilen? Funktioniert.
Harris verglich die Konfigurationen des E-Mail-Servers mit anderen Systemen und fand keinerlei Auffälligkeiten. Zur weiteren Diagnose loggte er sich per Telnet auf den SMTP-Port des Servers ein. Der Server reagierte, wie erwartet mit dem SunOS Sendmail Logo. Und das führte Harris auf die richtige Fährte.
Der Vorsitzende der Statistik-Abteilung erwähnte zwar, dass vor ein paar Tagen ein Wartungs-Updates für des Betriebssystems installiert wurde. Angeblich betraf das aber nicht sendmail, welches Harris vor längerer Zeit in der Version 8 installiert hatte.
Das besagte Update von SunOS enthielt jedoch noch die alte Version 5 von sendmail! Der E-Mail-Server wurde durch das Update des Betriebssystem auf eine alte Version zurückgesetzt. Die Konfigurations-Dateien, die Harris für die Version 8 angelegt hatte, waren allerdings noch vorhanden. Nur waren sie nicht mit Version 5 kompatibel. So wurde für einige wichtige Parametern von sendmail der Standard-Wert 0 angenommen.
Einer dieser Parameter bezog sich auf das Timeout für die Verbindung zum externen SMTP-Server. Der Wert dafür betrug nun 0 Sekunden.
Aber was hatte das zu bedeuten? Wenn sendmail versucht, eine Verbindung mit einem externen SMTP-Server aufzubauen, schickt es eine Anfrage in das Internet und wartete dann auf die Antwort. Aufgrund der Auslastung des Systems brauchte sendmail einen Augenblick, um die Routine für die Verarbeitung der Antwort aufzurufen. Harris fand heraus, das sendmail dafür etwa 3 Millisekunden benötigt. Eine Antwort, die nach 3 Millisekunden bei sendmail eintraf, wurde aufgrund des Timeouts als nicht erfolgreich gewertet.
Da die Universität über ein Glasfasernetz an das Internet angeschlossen war, gelang eine derartige Anfrage also mit nahezu Lichtgeschwindigkeit nach draußen. Also fragte sich Harris, wie weit das Signal innerhalb von 3 Millisekunden kommen konnte. Er bemühte units, ein Kommandozeilen-Programm, um die Distanz auszurechnen:
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979558 Meilen. (Das *-Zeichen ist kein Operator, sondern zeigt das Ergebnis an.) Harris hatte die Ursache für das seltsame Verhalten gefunden.
Harris räumte später ein, einige technische Details, auch aus dramaturgischen Gründen, nicht ganz exakt wiedergeben zu haben. So musste natürlich auch die Antwort vom SMTP-Server innerhalb von 3 Sekunden wieder bei sendmail landen, womit sich die verfügbare Zeit eigentlich auf 1,5 Millisekunden halbiert. Das ändert aber nichts daran, dass das Zusammenspiel aus Timeout, Übertragungsgeschwindigkeit und Verzögerung bei der Verarbeitung dafür gesorgt haben, dass E-Mails nur in einem bestimmten Radius versendet werden konnten, nämlich 500 Meilen…
…but I would walk 500 miles, and I would walk 500 more…
