Zusammenfassung

  • RFC 1211 beschreibt Zustellfehler für Postfächer, die nicht einzeln in der IETF-Hauptliste standen. Dort war nur ein Exploder-Alias eingetragen; eine extern verwaltete Unterliste enthielt die Zieladresse.
  • Received-Zeilen, ähnliche Rechnernamen und SMTP-Abfragen mit EXPN oder VRFY konnten die Suche eingrenzen, blieben aber oft ergebnislos. Ein Pfadhinweis bewies keine Mitgliedschaft.
  • Die zentrale Pflege konnte eine Bitte an den registrierten Eigentümer oder postmaster senden. Nur die entfernte Stelle konnte ihre verborgene Liste prüfen und ändern; die Weiterleitung war kein Vollzugsnachweis.

Ein leerer Suchtreffer widerlegte den Fehler nicht

RFC 1211 beginnt mit einer Suche im Hauptbestand. Eine Rückmeldung nennt einen unbekannten Benutzer oder Rechner. Der Betreuer sucht das Postfach in der Liste und findet es bisweilen nicht.

Große Verteiler konnten andere Verteiler aufnehmen. Ein einzelnes Postfach fungierte als Exploder: Am entfernten Standort wurde es in eine lokale Empfängergruppe aufgelöst. Die äußere Liste kannte den Alias; die innere Liste kannte die Personen. Deshalb konnte ein Zustellsystem eine tatsächlich versuchte Zieladresse nennen, die im zentralen Bestand nie als Einzelzeile existiert hatte.

Die Register hatten verschiedene Besitzer. Zentral ließ sich die Zugehörigkeit des Alias belegen. Lokal ließ sich seine Mitgliedschaft prüfen. Das Mail-System konnte nur seinen Zustellversuch beschreiben. Keine dieser Aussagen war automatisch ein vollständiges Abbild der anderen.

Der RFC-Editor-Eintrag datiert das Informational-Dokument auf März 1991. Der IETF-Datatracker führt es im Legacy-Stream. Es ist ein begrenzter Betriebsbericht, kein Standard für alle Listen.

Freitextfehler wurden bei Größe zu einem Steuerungsproblem

Ann Westine und Jon Postel berichteten von ungefähr 25 bei ISI gepflegten Listen für Internet-Forschungsgruppen, die IETF und andere Gemeinschaften. Monatlich trafen rund 400 Änderungswünsche und 300 Fehlernachrichten ein; nach Dubletten blieben etwa zehn Fälle pro Tag. Diese Zahlen gelten für den beschriebenen Ort und Zeitraum, nicht als Internet-Messung.

Die Diagnosen hatten keine einheitlichen Namen. Manche kündigten weitere Versuche nach einer Verzögerung an, andere sprachen von unbekanntem Benutzer oder Rechner. Systemspezifische Texte waren kaum verständlich. Eine Nachricht konnte mehrere Empfänger mit vorläufigen und scheinbar endgültigen Zuständen mischen.

Vor der Listenänderung musste jemand den Zustand bewerten. Eine einzelne Verzögerung war kein Löschgrund. Wiederholung über Tage konnte eine Untersuchung auslösen. Auch ein scheinbar unbekannter Benutzer verdiente weitere Prüfung, wenn er als aktiver Teilnehmer bekannt war. Der Fehler eröffnete einen Fall; er erteilte keinen Schreibbefehl.

Eine falsche Entfernung blieb unter Umständen unbemerkt, bis der Betroffene nach ausbleibender Post fragte. Eine erneute Aufnahme derselben Adresse beseitigte auch nicht zwingend den Transportfehler. RFC 1211 beschreibt daher menschliches Urteil und Umkehrbarkeit statt einer universellen Regel.

Der Transportpfad bestimmte die nächste Frage

Fehlte die Adresse im Hauptbestand, lasen die Betreiber die Received-Zeilen und suchten einen Rechner, der zu einem bekannten Exploder passen konnte. Übergänge in UUCP, BITNET oder über Gateways machten die Verwaltungsbeziehung noch indirekter.

Eine Übereinstimmung half bei der Auswahl des Ansprechpartners. Sie bewies nicht, dass das Postfach Mitglied der vermuteten Unterliste war. Ähnliche Namen konnten zu verschiedenen Abteilungen gehören; Gateways zeigten nur einen Abschnitt; ein Nachrichtenkopf war kein authentisiertes Änderungsprotokoll.

Die zeitgenössische RFC 821 legte den reverse path für Fehlermeldungen fest und erlaubte ein besonderes Fehlerpostfach statt des menschlichen Autors. VRFY prüfte einen Benutzer, EXPN sollte eine Liste auflösen. Beide Befehle gehörten aber nicht zur Mindestimplementierung und mussten nicht über Relays hinweg funktionieren.

In RFC 1211 endete die Prüfung deshalb häufig ohne Urteil: Befehl nicht vorhanden, Auflösung verweigert, anderes Protokoll, Rechner unerreichbar. Dann blieb eine begründete Vermutung und die Bitte an den entfernten postmaster, die Adresse zu entfernen, falls sie vorhanden sei. Dieses „falls“ hielt Spur und Tatsache auseinander.

Eigentum verband Änderungsrecht mit dem richtigen Bestand

Bei Aufnahme einer Unterliste notierte ISI den Antragsteller und betrachtete ihn als deren Eigentümer. Jeder Exploder sollte lokal betreut werden, die Fehler seiner Mitglieder erhalten und deren Zu- und Abgänge verwalten.

Der zentrale Betreuer konnte den ganzen Alias entfernen, würde damit aber alle dahinterliegenden Mitglieder treffen. Für eine einzelne Korrektur brauchte es die Stelle, die den entfernten Bestand sehen und bearbeiten konnte.

Kontakte veralteten. Antragsteller wechselten Rolle oder Unternehmen. Als Ausweichadresse diente häufig postmaster, doch manche Standorte erkannten sie nicht. RFC 2142 ordnete später solche Funktionspostfächer und ihre schreibungsunabhängige Behandlung. Sie beweist nicht, dass ein früheres Postfach besetzt war oder sein Empfänger entscheiden durfte.

Eine belastbare Kette trennt ursprünglichen Antragsteller, heutigen Eigentümer, Eingang der Bitte, Bestätigung, Genehmigung, Speicherung und spätere Beobachtung. Eine Kontaktadresse zeigt, wohin eine Frage geht; sie ist kein Änderungsresultat.

Die zentrale request-Adresse verwaltete nicht jede Ebene

Nutzer einer Firmen-Unterliste schickten Änderungswünsche trotzdem an die zentrale IETF-request-Adresse. Dort fand man die Person nicht, leitete aus dem Pfad einen möglichen Exploder ab und gab die Bitte an dessen Eigentümer weiter.

Die Weitergabe korrigierte die administrative Richtung. Daten waren noch nicht geändert. Die entfernte Stelle musste den Eintrag finden, den Antrag zuordnen, entscheiden, schreiben und die Änderung erhalten. Ähnliche Hostnamen konnten zum falschen Verteiler führen; ein alter Eigentümer konnte schweigen.

Die sichtbare Mitte wirkte wie die Instanz für den ganzen Baum. RFC 1211 zeigt: Koordination ist nicht dasselbe wie Schreibrecht in jeder verschachtelten Liste.

Spätere Regeln bewahrten das Nichtwissen

RFC 5321 erlaubte später, VRFY und EXPN aus Sicherheitsgründen abzuschalten, und unterschied echte Verifikation von scheinbarer Gültigkeit ohne Echtzeitprüfung. Eine verweigerte Auskunft ist kein Abwesenheitsbeweis.

RFC 3464 strukturierte Zustellmeldungen und bezeichnete expanded als nicht terminal: weitere Verzögerungen oder Fehler können folgen. Das erklärt spätere Expansion, schreibt aber RFC 1211 nicht rückwirkend um und verleiht dem meldenden MTA kein Recht zur Änderung fremder Mitgliedschaft.

Fehleradresse, äußerer Alias, Pfadspur, Abfrage, alter Kontakt, heutiger Eigentümer, Bitte, ausgeführte Änderung und nächste Zustellung sind aufeinanderfolgende Ereignisse. „Unzustellbar, also löschen“ entfernt genau die Provenienz und Zuständigkeit, die eine sichere Korrektur braucht.

Quellen