Zusammenfassung

  • RFC 1440 ließ einen Absender ohne Konto auf dem Zielsystem eine Nicht-Mail-Datei an einen Empfangsdämon senden.
  • Ein NULL ACK bestätigte genau einen Befehl; EOF oder Verbindungsende sagten nichts darüber aus, ob der Empfänger die Datei angenommen oder genutzt hatte.
  • Die Bequemlichkeit des Senders verlagerte Kapazität, Aufbewahrung, Authentisierung und die Kontrolle ausführbarer Pseudobenutzer auf das Empfangssystem.

Die Sendung begann beim Absender

Beim klassischen FTP öffnete der Benutzer die Steuerverbindung, wies sich aus, soweit der Server es verlangte, und veranlasste eine Dateisystemoperation. SIFT/UFT kehrte den Anfang um. „Unsolicited“ hieß nur, dass der Empfänger die Transaktion nicht begonnen hatte. Der Begriff behauptete nicht, die Datei sei unerwünscht.

Vorbild waren unter anderem NJE-Netze wie BITNET. Dort ließ sich eine Datei außerhalb der elektronischen Korrespondenz zustellen. Der Autor sprach vom Paket im Unterschied zum Brief. Der Sender brauchte weder Konto noch Registrierung am Ziel; der Empfänger konnte das Objekt später abholen.

Weniger Aufwand auf einer Seite bedeutete mehr dauerhafte Arbeit auf der anderen. Der Zielrechner musste zuhören, lokale Adressaten erkennen, Speicher zuteilen, wartende Objekte verwahren und veraltete Einträge entfernen. Die Zustände verschwanden nicht, sie wechselten den Besitzer.

Zwei Dateien in einem Strom

Der Dienst lauschte auf TCP-Port 608. ASCII-Befehle und binäre Daten liefen durch denselben Socket. Die RFC beschrieb den Auftrag als Verkettung einer Steuerdatei mit einer Datendatei.

FILE nannte Absender, ungefähre oder genaue Größe und ein optionales Authentisierungsticket. USER bestimmte einen lokalen Benutzer oder Dienst, TYPE die Darstellung. Alle drei mussten vor DATA stehen. NAME und DATE ergänzten Kontext. EOF schloss eine Datei, ABORT verwarf ein Fragment, QUIT beendete den Auftrag.

Der Empfänger durfte Steuerung und Körper getrennt speichern. So musste der Listener ein fremdes Format nicht sofort auswerten. Dafür entstand eine Zuordnungspflicht: Befehle, empfangene Bytes, Abschluss und spätere Verfügung mussten dauerhaft zum selben Objekt gehören.

Das kleinste ACK hatte den kleinsten Geltungsbereich

Eine positive Antwort begann mit einem Null-Oktett. Dieses NULL ACK nahm einen Befehl an. Es bestätigte weder den ganzen Transfer noch die Entscheidung eines Benutzers.

Die FILE-Größe sollte die Frage beantworten, ob genügend Platz vorhanden war, durfte aber ungenau sein. Ein Server konnte FILE akzeptieren und USER wegen eines unbekannten Namens ablehnen. Er konnte Metadaten bestätigen und beim Schreiben scheitern. Frühe Zulassung blieb eine lokale Prognose.

Zur Begrüßung sendete der Server Hostnamen, UFT-Stufe und Implementierungsversion. Das half bei Synchronisation und Protokollabgleich. Es authentisierte den Rechner nicht. Das auth-Token von FILE war nicht implementiert; die RFC erklärte, Authentisierung sei nicht gewährleistet.

Verwahrung begann nach dem Netzabschluss

Eine eingetroffene Datei lag in einem gemeinsamen Bereich, beispielhaft /usr/spool/uft. Dort wartete sie auf Annahme oder Ablehnung durch den Empfänger oder auf altersbedingte Löschung. Öffentlich bedeutete geteilt, nicht unbeschränkt zugänglich. Größen- und Zeitgrenzen waren lokale Verwaltungsentscheidungen.

Netzempfang, Host-Verwahrung und Benutzerannahme besaßen eigene Zeitpunkte. Die Verbindung konnte beendet sein, während die Datei tagelang wartete. Sie konnte ablaufen, ohne je Gegenstand einer Benutzerentscheidung zu werden.

Darum war Alterslöschung keine Ablehnung. Ebenso bewies ein später leeres Spool-Verzeichnis keine Verarbeitung. Löschung, Quarantäne, Fehler und Annahme hinterließen ohne expliziten Verfügungsdatensatz dieselbe Abwesenheit.

Der Inhalt sollte bis zur Entscheidung möglichst wenig bearbeitet werden. Eine unbekannte Darstellung blieb binär erhalten. Diese Zurückhaltung schützte Wahlmöglichkeiten, nicht Integrität, Sicherheit oder Brauchbarkeit.

Eine Längenangabe schuf Haltepunkte

Im normalen Betrieb trug DATA die Größe des nächsten Blocks. Der Server las genau diese Oktette, schrieb sie und kehrte zur Befehlsauswertung zurück. Viele Blöcke konnten eine Datei bilden, viele Dateien eine Verbindung nutzen. Zwischen den Blöcken gab es wieder einen Ort für ACK oder ABORT.

Der schnelle Modus ließ die Länge fort. Dann las der Server bis zum Schließen der Verbindung. EOF und QUIT entfielen; während des Stroms war ABORT nicht möglich. Das Lebensende des Sockets wurde zur Dateigrenze.

Die eingesparten Dialogschritte kosteten Kontrollpunkte. Ein beabsichtigtes Ende und ein Leitungsbruch sahen gleich aus. Erst Soll- und Ist-Menge, Prüfsumme und Abschlussursache konnten die Vollständigkeit stützen. Ein geschlossener Socket allein konnte es nicht.

Hinter USER konnte ein Programm stehen

USER durfte eine Softwaremaschine oder eine als Pseudobenutzer sichtbare Auftragsschlange bezeichnen. Damit konnte die verwahrte Datei zum Eingang einer automatischen Verarbeitung werden.

Die Auflösung des Namens war dennoch keine Ausführungserlaubnis. Absenderidentität, Einreichungsrecht, Formatprüfung, Ressourcenlimit, Quarantäne, Start und Ergebnis blieben getrennte Entscheidungen. Der Listener konnte den Zielnamen kennen, ohne die Folgen autorisieren zu dürfen.

Genau hier wog die Sicherheitslücke schwer. Die RFC behandelte Sicherheitsfragen nicht und wartete bei der Authentisierung auf andere Entwicklungen. Die Entfernung des Zielkontos senkte Reibung; sie erzeugte keine neue Vertrauensgrundlage.

Der MIME-Umweg änderte die Beweiskette

Manche Hosts hatten keine direkte IP-Anbindung, wollten keinen weiteren Dämon oder lagen hinter einer Firewall, die nur Mail passieren ließ. UFT konnte deshalb in MIME reisen. Die Befehle wurden Parameter von application/octet-stream, der Körper lief Base64-kodiert durch das Mailsystem.

MIME löste Darstellung und Transportkompatibilität. Es entschied nicht über die Annahme. An die Stelle direkter Begrüßung, Befehls-ACKs und Blöcke traten Store-and-forward-Zustände. Für Authentisierung war ausdrücklich das Mailsystem zuständig.

SIFT/UFT blieb Experimental. RFC 1499 führte es weiterhin so, und das IANA-Register enthält heute sift-uft auf Port 608. Diese Einträge belegen Dokumentation und Registrierung, nicht laufende Implementierungen.

Ein Statuswort reicht nicht

RFC 1440 trennt Initiieren, Zulassen, Empfangen, Verwahren, Annehmen, Ablehnen, Verfallen und Ausführen. Jeder Schritt hat einen anderen Akteur. Wer sie zu „zugestellt“ verdichtet, verleiht dem frühesten Signal fremde Autorität.

Ein belastbarer Datensatz verbindet Transportpartner und Begrüßung, jeden Befehl samt ACK, gemeldete und gemessene Größe, Typ, Hash, Spool-Abschluss, Ablaufzeit, Empfängersuche, Verfügung und Anwendungsergebnis. Erst dann lässt sich sagen, was angekommen ist und wer den nächsten Schritt wirklich getan hat.

Quellen