Zusammenfassung

  • RFC 1465 brachte Angaben zu Gemeinschaft, Domain, Relay, Kontakt, Netz, Protokollstapel, Priorität und Gültigkeit in ein gemeinsames Format, solange X.500-Routing noch nicht bereitstand.
  • START terminierte eine Deklaration; Empfang, lokale Installation, Adressprüfung, Verbindung, Nachrichtenübernahme und endgültige Zustellung blieben eigenständige Nachweise.

X.400-MTAs liefen über unterschiedliche Kombinationen von Transport und Netz: TP0 über X.25, TP4 über CLNS oder RFC 1006 über TCP/IP. Ein gemeinsamer Stapel allein schuf keinen Weg. Auch die Netze mussten verbunden sein, und manche Gegenstellen akzeptierten nur registrierte Anrufer.

RFC 1465 erschien im Mai 1993 als Experimental und verstand sich als Übergang. Mehrprotokoll-MTAs sollten zwischen Netzinseln vermitteln. Gemeinsame Tabellen sollten Routingdaten verteilen, bis ein X.500-Verzeichnis diese Aufgabe übernehmen konnte.

Vier Dokumente bildeten keinen einzigen Eigentümer

COMMUNITY legte Koordinationsstelle, Dateiserver und gemeinsame Netz-/Stapelbezeichnungen fest. RELAY-MTA beschrieb die Verbindung zu einem Relay. DOMAIN ordnete X.400-Adressunterbäume verantwortlichen Personen und priorisierten Relays zu. PERSON enthielt Kontaktdaten.

Eine Relay-Kennung konnte Bestandteile einer Management-Domain tragen, um eindeutig zu sein. Der RFC stellte klar: Das Ergebnis war ein Schlüssel, keine Adresse. Ebenso war ein Relay weder die bediente Domain noch deren Verantwortlicher oder der Empfänger.

Die Koordinationsstelle veröffentlichte den Satz. Domainmanager erklärten Zuständigkeit. Relaybetreiber verwalteten Verbindungen. Lokale Administratoren überführten die empfangene Fassung in Softwarezustand. Das Format verband diese Entscheidungen, ohne sie zu vollziehen.

Das Startdatum gehörte zur Planung

Jedes Dokument führte ein Aktualisierungsdatum, ein verpflichtendes Startdatum und optional ein Enddatum. Vorzeitige Veröffentlichung war ausdrücklich zulässig, damit Relaymanager ohne automatische Werkzeuge Vorbereitungszeit erhielten.

Am Stichtag konnte Standort A bereits die neue Tabelle ausführen, B sie nur heruntergeladen haben und C noch die alte Fassung verwenden. Der Eintrag war nach Dokumentregel gültig. Ein verteilter Beleg für die tatsächliche Konvergenz entstand daraus nicht.

Auch END entfernte eine Altlast nicht aus jeder lokalen Konfiguration. Dafür musste man die laufenden Tabellen prüfen. Der Scan-Anhang von RFC 2626 fand 1999 die yymmdd-Felder von RFC 1465. Das belegt einen prüfenswerten Zweistellen-Code, nicht einen eingetretenen Jahr-2000-Ausfall.

Priorität war Reihenfolge, nicht Verfügbarkeit

Domains konnten primäre und sekundäre Relays mit Prioritäten nennen. Die Prozedur wählte Relay und Dienst. Scheiterte die Verbindung, folgten ein anderer Dienst oder ein anderes Relay; ohne Alternative wurde das gewählte erneut versucht.

Damit beschrieb die Tabelle die nächste Handlung. „Primär“ war eine Rolle, die Zahl eine Präferenz. Weder Rolle noch Zahl maßen aktuelle Last, Erreichbarkeit oder Annahme dieser Nachricht.

Jede Gemeinschaft sollte eigene Aktualisierungsverfahren festlegen; automatische Updates mussten laut RFC sorgfältig untersucht werden. Mehr Relays konnten Robustheit erhöhen, steigerten aber den Aufwand, lokale Tabellen aktuell zu halten und Verbindungen fortlaufend zu überwachen. Redundanz im Dokument half nur, wenn sie installiert und erreichbar war.

Eine X.25-Änderung konnte die unveränderte Route brechen

Einige X.400-Systeme prüften die Netzadresse des Anrufers. RFC 1465 warnte, dass die Neukonfiguration eines X.25-Switches diese Adresse ändern und damit Verbindungen zu anderen Relays stoppen konnte, obwohl sich in höheren Schichten nichts geändert hatte.

Domain, Relay-Schlüssel, Priorität und Dienstname konnten in der Datei gleich bleiben. Die tatsächlich präsentierte Adresse passte trotzdem nicht mehr zur Prüfung der Gegenstelle. Ein stabiler symbolischer Eintrag hatte eine veränderte Betriebsbedingung überlebt.

Optionale Hardware- und Softwaredaten halfen bei der Diagnose, sofern sie aktuell waren. Lokale Testadressen und Echo-Server ermöglichten Prüfungen. Die Dokumentation eines Tests war aber noch kein positives Testergebnis.

Die Nachfolgeplanung benannte die Konsistenzlücke

RFC 1649 beschrieb 1994 statische Tabellen, die O/R-Adressen auf den nächsten MTA abbildeten. Eine vollständige Liste aller MTAs wäre zu groß und zu beweglich gewesen; Relays begrenzten den Umfang. RFC 1711 führte GO-MHS als operativen, überwiegend statisch und tabellenbasiert gerouteten X.400-Dienst.

Das weist betrieblichen Gebrauch nach, aber keine vollständige Teilnehmerzahl, keine identischen Tabellenstände und keine Zustellung einzelner Nachrichten.

RFC 1802 erklärte 1995, zentral gepflegte Tabellen skalierten nicht weiter und manuelle Weitergabe und Installation könnten weltweit keine Konsistenz garantieren. Project Long Bud sollte X.500-Routing erproben. Verzeichnisfähige MTAs lasen direkt; für ältere Systeme sollten Werkzeuge weiterhin statische Tabellen erzeugen.

Die Pilotphase verlangte Registrierung, Test mit einem anderen Teilnehmer, Default-Routen, genaue Daten und Ankündigung nach Prüfung. Eine kleine Anfangsgruppe arbeitete bereits, doch der größere Versuch blieb ein Vorhaben ohne zugesagte Großressourcen. RFC 1801 definierte das längerfristige Modell, nicht dessen weltweiten Erfolg.

Eine belastbare Route besteht aus mehreren Belegen

Zur Rekonstruktion gehören: akzeptiertes Dokument und Hash, Veröffentlichung und Gültigkeitsfenster, Empfang pro Standort, erzeugte und installierte Tabelle, Übereinstimmung von Netz/Stapel/Adressprüfung, ausgewählte Verbindung, Übergabeantwort und Zustell- oder Unzustellbarkeitsbericht.

RFC 1465 standardisierte den Anfang dieser Kette. Es machte Verwaltungsabsicht über inkompatible Netze hinweg transportierbar. Seine Grenze ist die bleibende Lehre: Erst Antworten laufender Systeme verwandeln eine gut formulierte Route in beobachteten Dienst.