Dieser humoristische Beitrag liegt im Original beim MIT. Der “Ich”-Erzähler nennt sich Trey Harris. Vielleicht sollte man so seine Bewerbungen schreiben: 

Hier ist ein Problem, das *unmöglich* klang… Ich bereue fast, dass ich die
die Geschichte an ein breites Publikum schicke, weil sie eine großartige Geschichte bei Drinks auf einer Konferenz ist. 🙂 Die Geschichte ist leicht abgewandelt, um die Schuldigen zu schützen, irrelevante und langweilige Details auszulassen und generell die Sache unterhaltsamer zu machen.

Ich arbeitete vor einigen Jahren in einem Job, in dem ich das E-Mail-System des Campus verwaltete als ich einen Anruf vom Vorsitzenden der Statistikabteilung bekam.

“Wir haben ein Problem mit dem Versand von E-Mails aus der Abteilung.”

“Was ist das Problem?” fragte ich.

“Wir können keine E-Mails über mehr als 500 Meilen verschicken”, erklärte der Vorsitzende.

Ich verschluckte mich an meinem Milchkaffee. “Wie bitte?”

“Wir können keine Post weiter als 500 Meilen von hier verschicken”, wiederholte er. “Ein bisschen mehr, eigentlich. Nennen wir es 520 Meilen. Aber nicht weiter.”

“Ähm … E-Mail funktioniert normalerweise nicht auf diese Weise”, sagte ich und versuchte die Panik aus meiner Stimme herauszuhalten. Man zeigt keine Panik, wenn man mit einem wenn man mit einem Abteilungsleiter spricht, selbst in einer relativ armen Abteilung wie Statistik. “Wie kommen Sie darauf, dass Sie die Post nicht weiter als 500 Meilen?”

“Es geht nicht darum, was ich *denke*”, antwortete der Vorsitzende gereizt. “Sehen Sie, als wir das zum ersten Mal bemerkten, vor ein paar Tagen–“

“Sie haben ein paar TAGE gewartet?” Ich unterbrach ihn, ein Zittern in der Stimme. “Und Sie konnten die ganze Zeit keine E-Mails verschicken?”

“Wir konnten E-Mails verschicken. Nur nicht mehr als -“

“–500 Meilen, ja”, beendete ich für ihn, “das habe ich verstanden. Aber warum haben Sie nicht früher angerufen?”

“Nun, wir hatten nicht genug Daten gesammelt, um sicher zu sein, was vor sich geht. bis gerade eben.” Aha. Das ist der Vorsitzende der *Statistik*. “Wie auch immer, habe ich einen der Geostatistiker gebeten, sich das anzusehen…”

“Geostatistiker…”

“-Ja, und sie hat eine Karte erstellt, die zeigt, dass der Radius, in dem wir
in dem wir E-Mails senden können, etwas mehr als 500 Meilen beträgt. Es gibt auch eine Reihe von Zielen innerhalb dieses Radius, die wir nicht oder nur sporadisch erreichen können. Aber wir können niemals weiter als diesen Radius mailen.”

“Ich verstehe”, sagte ich und stützte den Kopf in die Hände. “Wann hat das angefangen? Vor ein paar Tagen, sagten Sie, aber hat sich zu diesem Zeitpunkt irgendetwas an Ihren Systemen geändert?”

“Nun, der Berater kam und hat unseren Server gepatcht und neu gebootet.
Aber ich habe ihn angerufen und er sagte, dass er das Mailsystem nicht angefasst hat.”

“Okay, lassen Sie mich einen Blick darauf werfen, und ich rufe Sie zurück”, sagte ich und konnte kaum glauben, dass ich mitspielte. Es war kein Aprilscherz. Ich versuchte mich zu erinnern, ob mir jemand einen Scherz schuldete.

Ich loggte mich in den Server von deren Abteilung ein und schickte ein paar Testmails. Dies war im Forschungsdreieck von North Carolina. Auch eine Testmail an mein eigenes Konto wurde ohne Probleme zugestellt. Dasselbe gilt für die Mails nach Richmond, Atlanta und Washington. Eine weitere nach Princeton (400 Meilen) funktionierte.

Aber dann habe ich versucht, eine E-Mail nach Memphis (600 Meilen) zu senden. Es schlug fehl. Boston, gescheitert. Detroit, gescheitert. Ich holte mein Adressbuch heraus und begann zu versuchen, die Sache einzugrenzen. New York (420 Meilen) hat funktioniert, aber Providence
(580 Meilen) schlug fehl.

Ich begann mich zu fragen, ob ich meinen Verstand verloren hatte. Ich versuchte eine E-Mail an einen Freund zu mailen, der in North Carolina lebte, aber dessen ISP in Seattle war. Zum Glück schlug es fehl. Wenn das Problem mit der Geographie des menschlichen Empfängers zu tun gehabt hätte und nicht mit seinem Mailserver zu tun gehabt hätte, wäre ich wohl am Boden zerstört in Tränen ausgebrochen.

Nachdem ich festgestellt hatte, dass das gemeldete Problem -unglaublicherweise – wahr und reproduzierbar war, warf ich einen Blick auf die Datei sendmail.cf. Die Datei sah ziemlich normal aus. Tatsächlich sah sie vertraut aus.

Ich verglich sie mit der sendmail.cf in meinem Home-Verzeichnis. Sie war nicht verändert worden geändert worden – es war eine sendmail.cf, die ich geschrieben hatte. Und ich war mir ziemlich sicher, dass ich die Option “FAIL_MAIL_OVER_500_MILES” nicht aktiviert hatte. Ich war ratlos und
telnettete ich den SMTP-Port an. Der Server antwortete fröhlich mit einem SunOS sendmail-Banner.

Moment mal… ein SunOS-Sendmail-Banner? Zu dieser Zeit lieferte Sun immer noch Sendmail 5 mit seinem Betriebssystem aus, obwohl Sendmail 8 schon ziemlich ausgereift war. Da ich ein guter Systemadministrator war, hatte ich mein System auf Sendmail 8 standardisiert. Und auch weil ich ein guter Systemadministrator war, hatte ich eine sendmail.cf geschrieben, die die schönen langen selbstdokumentierenden Options- und Variablennamen
Options- und Variablennamen verwendet, die in Sendmail 8 zur Verfügung stehen, anstatt die kryptischen Satzzeichen Codes, die in Sendmail 5 verwendet wurden.

Die Teile fügten sich auf einmal zusammen, und ich verschluckte mich wieder am Bodensatz meines nun kalten Milchkaffees. Als der Berater den Server “gepatcht” hatte, hatte er offenbar die Version von SunOS aktualisiert und dabei Sendmail *downgraded*. Das Upgrade ließ hilfreicherweise die sendmail.cf  in Ruhe, obwohl sie nun die falsche Version war.

Zufälligerweise konnte Sendmail 5 – zumindest die Version, die Sun mit einigen Optimierungen ausgeliefert hatte – mit der sendmail.cf von Sendmail 8 umgehen konnte, da die meisten die meisten der Regeln zu diesem Zeitpunkt unverändert geblieben waren. Aber die neuen
langen Konfigurationsoptionen – die sah es als Müll an und übersprang sie.

Die sendmail-Binärdatei hatte für die meisten dieser Optionen keine Standardwerte einkompiliert, so dass keine passenden Einstellungen in der Datei sendmail.cf gefunden wurden. Diese wurden auf Null gesetzt.

Eine der Einstellungen, die auf Null gesetzt wurde, war der Timeout für die Verbindung zum entfernten SMTP-Server. Einige Experimente ergaben, dass auf  bestimmten Rechnern mit seiner typischen Last, ein Timeout von Null einen Verbindungsaufruf nach etwas mehr als drei Millisekunden abbrechen würde.

Ein merkwürdiges Merkmal unseres Campus-Netzwerks zu dieser Zeit war, dass es zu 100% geswitcht war. Ein ausgehendes Paket würde keine Router-Verzögerung erfahren, bis es auf den POP trifft und einen Router auf der anderen Seite erreicht. Die Zeit für die Verbindung zu einem leicht belasteten entfernten Host in einem nahe gelegenen Netzwerk zu verbinden, würde tatsächlich weitgehend von der Lichtlaufzeit zum Zielort und nicht von zufälligen Router-Verzögerungen bestimmt.

Mit einem leichten Schwindelgefühl tippte ich in meine Shell:

$ units
1311 Einheiten, 63 Präfixe

Sie haben: 3 Millilichtsekunden
Sie wollen: miles
* 558.84719
/ 0.0017893979

“500 Meilen, oder ein bisschen mehr.”