Zusammenfassung

  • RFC 1486 kehrte die Ziffern einer internationalen Rufnummer um, legte sie als DNS-Labels unter tpc.int ab und nutzte MX-Routing zur Auswahl eines Remote-Printing-Gateways.
  • Ein Wildcard-MX erklärte die Bereitschaft, einen Rufnummernbereich zu bedienen. Er bestätigte weder eine einzelne Nummer noch ein daran angeschlossenes G3-Faxgerät; der RFC grenzte das ausdrücklich ab.
  • Mailannahme, Gateway-Verarbeitung, Telefonverbindung, Faxübertragung, Papierausgabe und menschliches Lesen waren getrennte Abschlüsse. Die Erfolgsmeldung reichte nur bis zum Gerät.

Wie groß durfte ein Versprechen sein?

Ein Gateway konnte alle Nummern einer Vorwahl übernehmen, nur einen Vermittlungspräfix bedienen oder eine ungewöhnlich geschnittene Teilmenge ankündigen. RFC 1486 schrieb keine einheitliche Granularität vor. Der Betreiber wählte den DNS-Knoten, an dem sein Wildcard-MX stand.

Diese Freiheit war keine Ungenauigkeit im Protokoll. Sie bildete lokale Reichweite ab: Ein Standort wusste, welche Ortsgespräche oder organisationsinternen Nummern er erreichen konnte. Ein zweiter Betreiber konnte denselben Bereich mit anderer MX-Präferenz anbieten.

Der RFC-Editor-Eintrag datiert den Experimental RFC auf Juli 1993. Der Versuch verband Internet-Mail mit entfernten Ausgabegeräten, insbesondere G3-Faxgeräten am öffentlichen Telefonnetz. Seine Skalierung beruhte auf aggregierter Bereitschaft, nicht auf einer globalen Endgerätedatenbank.

Die Rufnummer wurde delegierbar gemacht

Zur Adressbildung entfernte der Absender die Darstellungssymbole einer internationalen Rufnummer, kehrte die Ziffern um, machte jede Ziffer zu einem Label und setzte die Folge unter tpc.int. Der Local Part lautete remote-printer.

Die Umkehrung brachte die Hierarchie der Telefonie in die Richtung der DNS-Delegation. Ländercode, Vorwahl, Vermittlung und Anschluss konnten entlang des Namensbaums verfeinert werden. Der Mechanismus sagte jedoch nichts über Zuteilungsrechte oder den aktuellen Zustand der Leitung.

Die Mailer folgten dem MX-Verfahren aus RFC 974. RFC 1034 und RFC 1035 lieferten Delegation, Caches, Wildcards und Resource Records. Damit gewann der Versuch Wiederholungsversuche und alternative Gateways, erbte aber auch veraltete Cacheeinträge und unvollständige Antworten.

RFC 1486 setzte den entscheidenden Warnhinweis direkt an den Wildcard-Fall: Ein Treffer bedeutet nicht, dass die betreffende Telefonnummer gültig ist. Selbst eine gültige Nummer beweist kein angeschlossenes G3-Fax. Der MX war ein Wegweiser zu einem Betreiber, keine Messung am Endpunkt.

Zwischen Mail und Papier lag ein Interpreter

Die Anwendung erzeugte eine RFC-822-Nachricht mit Message-ID. Ein MIME-Multipart konnte Deckblattdaten in application/remote-printing und den zu druckenden Inhalt getrennt tragen. RFC 1341 stellte den damaligen Rahmen für Text, eingebettete Nachrichten, PostScript, TIFF und Multipart bereit.

Ein bekannter Medientyp war noch keine Zusage des Druckers. Zeichensätze konnten fehlen, PostScript brauchte eine sichere Ausführung, und bei Multipart-Alternativen musste eine Variante gewählt werden. Das Gateway konnte die Mail annehmen und später an der Umwandlung scheitern.

Ein optionaler opaker Text im Local Part erzeugte Name und Raum auf dem Deckblatt. Er war kein Verzeichnisabruf. Er bewies nur, welche Beschriftung der Absender übertragen hatte. Zwischen syntaktisch korrekter Adresse, gerendertem Deckblatt und realer Person lagen eigene Prüfungen.

Die Rückmeldung hatte ein Objekt

Nach der Verarbeitung sollte das Gateway Erfolg oder Fehler zurückmelden. RFC 1528 präzisierte im Oktober 1993: Erfolg hieß, dass die Nachricht erfolgreich an das Faxgerät gesendet worden war; nach wiederholtem Nichtmelden konnte ein Fehler folgen. Der Statusdatensatz zeigt die Ablösung von RFC 1486 und den späteren Historic-Status.

Die Rückmeldung war mehr als SMTP-Annahme. Sie verband Message-ID, Gateway und einen Telefonversuch. Sie beobachtete aber weder Papierstau noch Toner, Lesbarkeit, hausinterne Verteilung oder Leser. Eine wiedervergebene Rufnummer konnte sogar ein anderes Unternehmen erreichen.

Darum braucht „zugestellt“ ein Objekt: an den Mailserver, an den Gateway-Prozess, über die Faxsitzung, auf Papier oder an den Menschen. Ohne dieses Objekt übernimmt ein frühes grünes Signal die Bedeutung aller späteren Schritte.

Der Betreiber entschied über Zugang und Kosten

RFC 1529 trennte Verwaltungsregeln von der technischen Prozedur. Sein RFC-Editor-Eintrag bezeichnet ihn als Informational. Das Dokument beschrieb gemeinschaftlich finanzierte, vertragliche und werbefinanzierte Betriebsmodelle.

Hinter demselben MX konnten somit eine Universität, ein lokaler Dienstleister oder ein Sponsor stehen. Der DNS-Eintrag entschied nicht, wer Telefonkosten trug, welche Quellen wegen Missbrauchs abgewiesen wurden oder wie lange Verbindungsdaten gespeichert werden durften.

Eine weitere Grenze war die Identität: Mangels verbreiteter Authentifizierung ließ sich der Initiator nicht sicher bestimmen. From-Feld und Message-ID unterstützten Audit und Fehlerbearbeitung, reichten aber weder zur sicheren Abrechnung noch zur Autorisierung einer sensiblen Übertragung. Protokollierung musste gegen die Privatsphäre von Inhalt und Kommunikationsmustern begrenzt werden.

Auch die Stilllegung brauchte Laufzeitbelege

RFC 9121 stellte 2023 fest, dass die Infrastrukturverwendungen unter .int praktisch obsolet waren. tpc.int wurde als historisches Mail-zu-Fax-Gateway benannt, RFC 1528 auf Historic gesetzt und die betreffenden Namen entfernt. Die Bewertung stützte sich auf Inventar, geringe DNS-Anfragen und Kontaktaufnahme, nicht allein auf das Alter des Textes.

Ein veröffentlichter RFC bewies also keinen fortdauernden Dienst. Umgekehrt durfte die Entfernung hart codierte Altanwendungen und Wiederverwendungsrisiken nicht ignorieren. Betrieb war am Anfang und am Ende die maßgebliche Evidenz.

Heng Lus Gedanken zur Primärstellung laufenden Codes, zur minimalen Anfangsspezifikation und lokalen Zukunftsentscheidung und zu Realitätsschichten halten die Zuständigkeiten klein. Gemeinsam waren Umwandlung, Mailroute und Format. Lokal blieben Abdeckung, Zulassung, Finanzierung und Aufbewahrung. Telefon, Fax, Papier und Mensch erzeugten jeweils spätere Belege.

Eine belastbare Historie speichert Ursprungsnummer, Transformationsregel, DNS-Namen, Antwort und TTL, gewählten MX, SMTP-Dialog, Message-ID, Inhaltshashes, Konvertierung, Gateway-Richtlinie, Anrufversuche, Faxsitzung und Rückmeldung. Wo die menschliche Kenntnis zählt, kommt ein menschlicher Empfangsnachweis hinzu.

RFC 1486 machte ein großes Versprechen billig, indem es Präfixe aggregierte. Es blieb zuverlässig, weil es dieses Versprechen nicht mit einer Liste existierender Geräte verwechselte.

Quellen