Zusammenfassung

  • RFC 1505 schlug ein optionales Feld Encoding vor, das Nachrichtenteile durch Zeilenzahlen und geordnete Codierwörter beschrieb. Klammerkommentare durften Menschen helfen, aber niemals die Inhaltsinterpretation steuern.
  • Die registrierte und korrekt gelesene Zeichenfolge beschrieb einen Decodierweg. Sie bewies weder die Unterstützung einer konkreten Implementierung noch die Sicherheit oder Zulässigkeit des folgenden Schritts.
  • Bei SHAR-Befehlen, Dateisystemrechten, Klartextpasswörtern, Signature und CRC-Prüfungen blieb dieselbe Grenze bestehen: Beschreibung und Integrität übertrugen keine lokale Autorität.

Zwei Arten von Text in einer Zeile

Ein Empfänger las etwa eine Folge von Codierwörtern und daneben einen Kommentar in Klammern. Für den Menschen konnte der Kommentar erklären, worum es ging. Für den Decoder musste er bedeutungslos bleiben. RFC 1505 sagte ausdrücklich, dass solche Kommentare an Benutzerprogramme weitergereicht werden durften, aber nicht zur Interpretation des Inhalts dienen sollten.

Das war keine typografische Feinheit. Wenn frei formulierter Text die Verarbeitung steuert, kann jede freundliche Erläuterung zur inoffiziellen Programmierschnittstelle werden. Schreibweisen, Sprachen und Erwartungen driften auseinander. Ein Empfänger beginnt, aus „bitte entpacken“ eine Operation abzuleiten, während ein anderer nur das registrierte Schlüsselwort beachtet.

RFC 1505 hielt deshalb zwei Belege auseinander. Der Kommentar belegte, was jemand zeigen oder mitteilen wollte. Das Schlüsselwort belegte, welche definierte Transformation die Nachricht behauptete. Erst die Implementierung des Empfängers entschied, ob sie dieses Wort unterstützte. Eine weitere lokale Entscheidung bestimmte, ob mit dem decodierten Ergebnis überhaupt etwas geschehen durfte.

Die Trennung wirkt bis heute modern: sichtbare Erklärung, maschinenlesbare Anweisung, technische Fähigkeit und Befugnis sind vier verschiedene Ebenen. Eine Oberfläche, die sie in „Nachricht verstanden“ zusammenfasst, verliert gerade jene Unterschiede, die einen Vorgang prüfbar machen.

Eine geordnete Karte durch den Nachrichtenkörper

RFC 822 hatte eine Mail in Kopf und Körper gegliedert, getrennt durch eine Leerzeile. RFC 1505 wollte mehrere Körperteile und deren Repräsentationen beschreiben, ohne mitten im Inhalt zusätzliche Steuerstrukturen einzufügen. Ältere Leser hätten solche Strukturen womöglich als gewöhnlichen Text angezeigt.

Das optionale Feld Encoding enthielt daher Teilfelder in derselben Reihenfolge wie die Körperteile. Ein Teilfeld konnte eine dezimale Zeilenzahl und ein oder mehrere Schlüsselwörter enthalten. Eine nur aus CRLF bestehende Trennzeile gehörte zu keiner der benachbarten Zählungen. Beim letzten oder einzigen Teil durfte die Zahl fehlen.

Verschachtelte Transformationen waren reihenfolgeabhängig. Der Decoder arbeitete die Wörter von links nach rechts ab. Der Encoder schrieb sie in umgekehrter Reihenfolge zu den vorgenommenen Transformationen. uuencode LZW tar war somit kein Menü dreier beliebiger Fähigkeiten, sondern ein konkreter Rückweg zum ursprünglichen Material.

Ein Parser konnte prüfen, ob die erwarteten Zeilen vorhanden waren, und die angegebene Kette ablaufen. Damit wusste er, wie der Absender den Körper beschrieben hatte. Er wusste noch nicht, ob die Behauptung wahr war, ob jedes Modul vertrauenswürdig arbeitete oder ob der Endzustand lokal erwünscht war.

Die Karte erklärte den Weg. Sie erteilte keine Fahrerlaubnis.

Ein bekanntes SHAR blieb ein fremder Befehlsträger

Am deutlichsten wurde die Grenze bei SHAR, einem Shell-Archiv. Ein solches Archiv konnte Befehle enthalten, die Dateien wiederherstellten. Dieselbe Ausdrucksfähigkeit erlaubte jedoch auch Anweisungen, die der Empfänger nicht ausführen wollte.

RFC 1505 unterstützte SHAR, empfahl seine Verwendung aber nicht. Ein Decoder sollte die wiedergewonnenen Shell-Anweisungen nicht automatisch starten. Die Warnung galt ebenso für künftige Typen, die Befehle an die empfangende Maschine enthielten.

Der Ablauf verlangte getrennte Nachweise. Das Schlüsselwort wurde erkannt. Das Format wurde decodiert. Die Anweisungen wurden zur Prüfung bereitgestellt. Eine berechtigte Person oder Regel genehmigte eine Ausführung in einer bestimmten Umgebung. Ein Prozess wurde tatsächlich gestartet. Schließlich wurde beobachtet, welche Datei, welcher Dienst oder welcher Zustand sich änderte.

Keiner der ersten beiden Nachweise ersetzt die Genehmigung. Ein registriertes Wort zeigt, dass eine gemeinsame Bedeutung existiert. Erfolgreiche Decodierung zeigt, dass Material wiedergewonnen wurde. Beides sagt nichts darüber, ob ein Benutzer die Wirkung akzeptiert hat, ob Ressourcen begrenzt sind oder ob der Interpreter geeignet ist.

Die Quellen dokumentieren keinen konkreten SHAR-Angriff unter RFC 1505 und keine benannte Produktimplementierung. Sie belegen etwas Engeres: Die Spezifikation selbst lehnte es ab, Formatkenntnis als Ausführungsbefugnis zu behandeln.

Registrierung koordinierte Wörter, nicht Fähigkeiten

Schlüsselwörter ohne Präfix X- sollten bei der IANA registriert werden; X- blieb implementierungsspezifischen Verwendungen vorbehalten. Eine Registrierung gab Gemeinschaften einen gemeinsamen Namen und einen Weg zur zugehörigen Beschreibung. Sie verringerte Kollisionen zwischen verschiedenen Verfahren.

Sie installierte jedoch kein Decodiermodul. Sie bestätigte weder dessen korrekte Umsetzung noch dessen Ressourcenverhalten. Und sie erklärte den Inhalt nicht für sicher. Ein Empfänger konnte das Wort kennen, die Transformation aber nicht unterstützen. Er konnte sie unterstützen und dennoch deaktivieren. Er konnte das Ergebnis isolieren, ohne es einem Programm zu übergeben.

Würde Registrierung als allgemeine Freigabe verstanden, verwandelte sich die Verwaltung eines Vokabulars in eine Fernsteuerung von Fähigkeiten. Mit jedem neuen Eintrag könnten Absender dann indirekt bestimmen, was fremde Systeme tun. Der Sinn des Registers war das Gegenteil: Bedeutung koordinieren, während die Entscheidung über Wirkung örtlich blieb.

Auch hier half der Unterschied zwischen Kommentar und Schlüsselwort. Ein Kommentar war nicht einmal Teil der maschinellen Semantik. Ein registriertes Schlüsselwort war Teil der Semantik, aber noch keine Verpflichtung zur Unterstützung. Unterstützte Semantik war wiederum noch keine Zustimmung zur Ausführung.

Dateiattribute trugen fremde Verwaltungsannahmen

Die FS-Codierung stellte Verzeichnisse, Einträge, Dateien, Segmente und Daten aus unterschiedlichen Systemen dar, darunter Unix, DOS, VMS, Primos und Macintosh. Sie konnte Anzeigenamen, Kommentar, Typ, Erstellungs-, Änderungs- und Zugriffszeiten, Eigentümer, Gruppe, ACL, Passwort, Block- und Satzgröße sowie eine Anwendungszuordnung transportieren.

Gerade die Unterschiede der Systeme machten dieses Vokabular nützlich. Sie machten eine wortgetreue Anwendung zugleich riskant. Eine Benutzernummer konnte am Ziel zu einer anderen Person gehören. Eine Gruppe konnte fehlen oder unter demselben Namen andere Rechte besitzen. Ein Anwendungsname konnte ein anderes Programm aufrufen.

Die ACL-Syntax beschrieb Rechte wie Hinzufügen, Löschen, Auflisten, Schutz ändern, Lesen, Benutzen, Schreiben, Ausführen oder Vollzugriff. Reservierte Rollen hießen $OWNER, $GROUP, $SYSTEM und $REST. Sie waren transportierbare Beschreibungen von Rollen, keine weltweit gültigen Konten.

Wird $SYSTEM dem lokalen Administrator zugeordnet, entsteht eine Befugnis. Wird es verworfen, geht Absicht verloren. Wird es dem Empfänger der Mail zugeordnet, werden Empfang und Eigentum vermischt. Jeder Weg ist eine politische Entscheidung des Zielsystems, auch wenn ein Dialogfeld ihn als bloße Wiederherstellung bezeichnet.

Zeitwerte zeigten denselben Abstand in kleinerem Maßstab. Wenn das Ziel eine geringere Genauigkeit hatte, sollte der Decoder die überschüssige Präzision ignorieren. Empfangener Wert, darstellbare Genauigkeit und tatsächlich gespeicherter Wert blieben drei verschiedene Tatsachen.

Das Klartextpasswort benannte den Verantwortlichen

FS erlaubte ein Attribut password, das das Zugriffspasswort eines Elements im Klartext enthielt. RFC 1505 argumentierte, dies müsse keine zusätzliche Offenlegung sein, weil der geschützte Inhalt in derselben Codierung folgte.

Entscheidend war die anschließende Einschränkung. Falls der Decoder dieses Passwort tatsächlich am erzeugten Element setzte, fiel die Sicherheit oder Unsicherheit dieses Vorgangs in die Anwendungsdomäne, die den Decoder kontrollierte. Dasselbe galt für ACLs und andere Schutzattribute.

Eine empfangene Zeichenfolge namens Passwort war also noch kein lokales Geheimnis. Sie durfte nicht allein wegen ihres Namens vorhandenen Schutz ersetzen. Sie bewies auch keine Gleichheit zwischen Konten beider Seiten. Das Ziel musste entscheiden, ob es den Wert nur als Herkunftsnachweis bewahrte, sicher abbildete, eine Zustimmung verlangte oder ihn ablehnte.

Wörtliche Treue kann die Bedeutung verfälschen. Wer einen Schutzmechanismus in ein System kopiert, in dem er einen anderen Umfang besitzt, restauriert nicht nur Daten, sondern vergibt neue Macht.

Signature konnte eine gewöhnliche Grußformel sein

Das Wort Signature bezeichnete in RFC 1505 den üblichen Signaturbereich am Ende einer Mail oder eines Usenet-Beitrags. Er konnte den Namen des Absenders oder einen Lieblingsspruch enthalten und wurde häufig automatisch angefügt. Text Signature beschrieb daher einen Präsentationsteil, kein kryptografisches Prüfergebnis.

PEM, PEM-Clear und PGP waren eigene Schlüsselwörter mit internen Formaten für Verschlüsselung, Integrität, Schlüsselblöcke oder abgetrennte Signaturen. Auch dort reichte das äußere Wort nicht. Zu prüfen waren die abgedeckten Bytes, das mathematische Ergebnis, die Herkunft des Schlüssels und das lokale Vertrauen in den behaupteten Namen.

RFC 1505 merkte sogar an, dass ein verschachtelter Typ nach PGP verraten konnte, ob es sich um Text oder eine EDI-Transaktion handelte. Eine erfolgreiche Schutzoperation beseitigte nicht jede Kontextinformation.

Ein einzelnes Kennzeichen „signiert“ hätte Grußtext, kryptografisches Objekt, mathematische Validierung und anerkannte Identität vermengt. Für jede dieser Aussagen war ein eigener Beleg nötig.

Zeilenzahl und CRC hatten enge Zuständigkeiten

LZJU90 verband Kompression mit einer druckbaren Repräsentation, die Mailer, Gateways und Wechsel zwischen ASCII und EBCDIC überstehen sollte. Seine Ausgabe enthielt die ursprüngliche Bytezahl und einen CRC, die nach der Dekompression übereinstimmen sollten.

Solche Prüfungen konnten Verkürzung, Beschädigung oder eine falsche Transformation erkennen. Sie authentifizierten den Absender nicht. Ein passender CRC genehmigte weder eine ACL noch ein Programm und erlaubte keine Ausführung.

Zudem bezogen sich die Zahlen auf unterschiedliche Gegenstände. Im Encoding-Feld wurden Zeilen des codierten Textes gezählt; der LZJU90-Anhang beschrieb decodierte Bytes und deren CRC. „Die Zahl stimmt“ war ohne Einheit und Verarbeitungsstufe keine belastbare Aussage.

Eine nachvollziehbare Kette musste die ursprüngliche Nachricht, die analysierten Teile und Trennlinien, die geordneten Wörter, Implementierung und Version des Decoders, jedes Transformationsergebnis und die jeweilige Prüfung bewahren. Danach folgten Quellattribute, lokale Abbildung, ausdrückliche Genehmigung, erzeugtes Objekt oder gestarteter Prozess und der tatsächlich beobachtete Zustand.

Ein Experiment neben MIME

RFC 1505 erschien im August 1993 als Experimental und löste RFC 1154 ab. Es definierte keinen Internetstandard. Die zugehörige IESG-Notiz verwies darauf, dass für denselben Bereich bereits eine Technik auf dem Standardisierungspfad existierte: RFC 1341, MIME.

Die Entwürfe lassen sich als zeitgenössische Alternativen vergleichen. RFC 1505 bündelte eine geordnete Beschreibung in einem oberen Feld. MIME gab den einzelnen Teilen eigene Kopfzeilen und trennte sie durch Begrenzungen. Auch MIME warnte in seinem Modell vor aktiven Inhalten und Ressourcenverbrauch.

RFC 2045 überarbeitete später die MIME-Linie über RFC 1521, RFC 1522 und RFC 1590. Daraus folgt nicht, dass RFC 1505 eine Vorstufe von MIME war oder von MIME formal außer Kraft gesetzt wurde. Ebenso wenig beweist die ausführliche Spezifikation eine bestimmte Verbreitung oder Produktunterstützung.

Historisch belastbar ist die dokumentierte Grenze. Ein Mailformat konnte seine eigene Darstellung beschreiben. Die Bedeutung einer menschlichen Erläuterung, die Unterstützung einer Operation und die Befugnis zu ihrer Wirkung blieben verschiedene Fragen.

Was die Quellen belegen

Die Primärquellen belegen Feldsyntax, Zeilenzählung, Reihenfolge der Wörter, FS-Attribute, die SHAR-Warnung, LZJU90-Prüfungen, Registrierungsregel, experimentellen Status und den MIME-Hinweis des IESG. Sie tragen eine Analyse der Unterschiede zwischen Repräsentation, Integrität, Authentisierung, Autorisierung und Wirkung.

Sie belegen keine konkrete Implementierung aller Wörter, keine Verbreitungsrate, keinen tatsächlichen SHAR-Vorfall und keine sichere Übertragung von Identitäten zwischen Systemen. Sie erlauben nicht die Behauptung, ein CRC authentisiere den Absender, Signature bedeute stets Kryptografie oder Registrierung gestatte Ausführung.

Eine genaue Spezifikation ist ein Beleg für beschriebenes Design. Laufender Betrieb verlangt andere Nachweise: Implementierung, Konfiguration, Entscheidung und beobachtetes Ergebnis.

Quellen