Zusammenfassung

  • Mary Ann Horton wirkte an der Organisation des UUCP Mapping Project mit: Standorte meldeten Nachbarn, regionale Freiwillige pflegten die Daten, und jeder Rechner leitete daraus seine eigene Mailroute ab.
  • Die Karte war kein automatisches Abbild, sondern eine gewartete Vereinbarung über Offenlegung, Kosten, Übersetzung und Zuständigkeit — samt Pflicht, veraltete Daten außer Betrieb zu nehmen.

Eine Adresse wie duke!research!ucbvax!user enthielt eine Wegbeschreibung. Jede Station musste die ganze Nachricht speichern und später weiterreichen. Fiel ein Zwischenrechner aus, änderte sich seine Wählpolitik oder wurde die Telefonrechnung zu hoch, konnte dieselbe Zeichenfolge unbrauchbar werden.

Hortons Leistung bestand darin, dieses lokale Wissen in einen gemeinsamen Arbeitsablauf zu überführen. Nicht eine Person zeichnete das Netz. Administratoren, regionale Pfleger, Softwareautoren, Relays und Gateways machten aus Verbindungen einen Dienst.

Die falsche Gleichsetzung zweier Karten

Im USENIX-Interview berichtet Horton von logischen Usenet-Karten, die sie 1982 und 1983 auf Konferenzen verteilte. Teilnehmer nutzten sie für Mailrouten, obwohl das News-Verteilnetz und das größere UUCP-Mailnetz nicht deckungsgleich waren. Fehlende Kanten belasteten besonders jene Standorte, die freiwillig weiterleiteten.

1984 war das logische Bild zu stark verzweigt. Horton gab eine geografische Karte aus; Bill und Karen Shannon erstellten eine achtseitige logische Fassung. Mehr Seiten lösten jedoch weder Aktualisierung noch Verantwortung. Wer nahm neue Nachbarn auf, wer entschied bei Widersprüchen, und wann war eine Ausgabe noch frisch?

Auch die Ökonomie blieb unsichtbar. Manche Hochschulen untersagten Ferngespräche, während Unternehmensstandorte hohe Kosten trugen. Eine Verbindung konnte nur von einer Seite angewählt werden, selten zustande kommen oder unzuverlässig sein. Existenz war nicht gleich Nutzbarkeit.

Regionale Pflege als Institution

Auf einer informellen USENIX-Sitzung in Washington entstand im Januar 1984 das UUCP Mapping Project. Freiwillige betreuten Regionen, sammelten Standort- und Nachbarschaftsdaten, bereinigten Konflikte und veröffentlichten Aktualisierungen in comp.mail.maps.

Die Teilnehmerzahlen betreffen verschiedene Phasen. Das Stargate-Museum nennt mehr als dreißig Personen beim ersten Treffen, Hortons Erfolgsbilanz ein Team von etwa fünfzig. Breitere Rückblicke erfassen weitere regionale Mitwirkende. Daraus lässt sich keine einzige Gesamtzahl bilden.

Auch die Leitung wird unterschiedlich zusammengefasst. Horton beschreibt sich als Einberuferin und Leiterin der Gründung. Ein Abschlussentwurf von 2000 nennt Karen Summers-Horton als erste Leiterin des USENIX-finanzierten Starts und Horton als Betreiberin ab 1985. Beide Angaben gehören mit Attribution in die Geschichte; eine Alleingründerin ergibt sich daraus nicht.

RFC 850 zog eine Sicherheitsgrenze. Mit senduuname konnten UUCP-Nachbarn für Karten erfragt und Antworten administrativ bearbeitet werden. Telefonnummern, Passwörter und die private Wähldatei durften nicht veröffentlicht werden. Discovery brauchte Topologie, nicht Zugangsdaten.

Der kürzeste Weg beruhte auf Wertungen

Steve Bellovin und Peter Honeyman entwickelten pathalias. Ein gerichteter Graph beschrieb Hosts und Netze; jede Kante trug nichtnegative Kosten und einen Adressoperator. Eine Dijkstra-Variante berechnete vom lokalen Standort Pfade zu bekannten Zielen vor.

Kosten waren keine neutrale Maßeinheit. Sie konnten Telefongeld, Anrufhäufigkeit, Geschwindigkeit, Zuverlässigkeit und die Präferenzen erfahrener Betreiber enthalten. Für ein Unternehmen und eine Universität war derselbe Sprung wirtschaftlich verschieden. Aufbauzeit und Wartezeit bis zum nächsten Anruf waren oft wichtiger als Nenngeschwindigkeit.

Die Autoren schildern unvollständige, widersprüchliche und fehlerhafte Eingaben. Aus Usenet abgeleitete Karten unterschätzten Verbindungen. Das Programm ergänzte teils Rückkanten zu unerreichbaren Hosts und nutzte Heuristiken für Domains. Optimierung konnte sogar einen absichtlichen Umweg um einen toten Link beseitigen.

Das Ergebnis war deshalb eine lokale Betriebssicht. Die Gemeinschaft veröffentlichte Behauptungen, pathalias bewertete sie aus einer Quelle, und der Mailer führte die Wahl aus. Horton arbeitete mit Adam Buchsbaum an smail, das diese Tabellen nutzte und den Bang-Pfad aus der Benutzeroberfläche verdrängte.

Ein Name ist kein Weg

In „What Is a Domain?“ erklärt Horton, dass Punkte in einem Domainnamen keine Durchgangsstationen sind. Die Domain ist ein absoluter Name in einer administrativen Hierarchie; Tabelle, Resolver oder Gateway bestimmen weiterhin den nächsten Sprung.

RFC 819 ordnet einer Domain Namensautorität und Übersetzungsverantwortung zu und stellt sie der relativen UUCP-Quellroute gegenüber. RFC 920 nennt Domains administrative Einheiten, die weder Geografie noch Topologie, Hardware, Software oder Protokoll teilen müssen.

Horton zufolge beteiligte sich das UUCP Project 1986 mit BITNET, CSNET und der ARPANET-Gemeinschaft am gemeinsamen Namensraum. Ihre Erfolgsseite nennt mehr als 150 UNIX-Organisationen ohne direkten Internetzugang, die zwischen 1986 und 1988 .com- oder .edu-Mail erhielten. Das ist ihre rückblickende Angabe, keine unabhängige Zählung dieses Beitrags.

RFC 976 setzte die Kompatibilität praktisch um. Statt eines weiteren Formats übernahm er Domain- und Mailstandards, unterschied Hostklassen und verlangte Gateways mit erweiterten Fähigkeiten. Hinter user@domain übersetzte eine Tabelle den stabilen Namen weiterhin in UUCP-Sprünge.

RFC 974 ergänzte MX-Einträge. Eine Domain konnte bevorzugte Mail-Exchanger nennen und bei Ausfall die Daten ändern. Die Komplexität verschwand nicht; sie wanderte vom Absender in eine gemeinsam verwaltete Steuerungsebene.

Eine Karte braucht ein Ende

Der Projektentwurf von 2000 berichtet, die Datenbank sei im August eingefroren worden, weil die Karten kaum noch genutzt wurden. Alte Daten könnten Mail verlieren oder fehlleiten. Das Dokument blieb ein Internet-Draft und belegt die eigene Stilllegung, keinen angenommenen Standard.

Eine erhaltene Datei bleibt nicht automatisch autoritativ. Dazu braucht es benannte Personen, die Änderungen annehmen, Konflikte lösen, Aktualität ausweisen und schließlich erklären, dass die Karte nicht mehr verwendet werden darf.

Moderne Systeme beobachten Topologie schneller. Die institutionelle Frage bleibt: Wer behauptet eine Verbindung, wer trägt ihre Kosten, und wer entzieht einer veralteten Darstellung die operative Autorität? Hortons Geschichte macht sichtbar, dass diese Antworten Teil der Infrastruktur sind.

Quellen

  1. Wikimedia Commons: Porträt Mary Ann Horton 2012
  2. Abschluss des UUCP Mapping Project, Internet-Draft
  3. Profil der UC Berkeley EECS
  4. Mary Ann Horton: Leistungen
  5. Mary Ann Horton: Internetgeschichte
  6. Stargate Internet Museum: UUCP Project
  7. Stargate Internet Museum: UUCP und E-Mail
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton: What Is a Domain?
  10. RFC 1036: Austausch von USENET-Nachrichten
  11. RFC 819: Domain-Namenskonvention
  12. RFC 850: Austausch von USENET-Nachrichten
  13. RFC 920: Domain-Anforderungen
  14. RFC 974: Mailrouting und Domain-System
  15. RFC 976: UUCP-Mail-Austauschformat
  16. USENIX-Interview mit Mary Ann Horton