Zusammenfassung

  • FTP behandelte USER, PASS und ACCT als getrennte Angaben zur Zugriffskontrolle. Ein erfolgreicher Passwortschritt bewies weder den vollständigen Login noch die Zulässigkeit jeder späteren Dateioperation.
  • 332 war eine positive Zwischenantwort. Nach einem Dateibefehl bedeutete sie außerdem, dass der Server den Befehl aufbewahrte; 532 bedeutete, dass er verworfen war und nach ACCT erneut gesendet werden musste.
  • Der Standard definierte kein universelles Kontomodell. Bedeutung und Pflicht des Strings blieben lokal; RFC- und IANA-Einträge beweisen weder Abrechnung noch Geheimhaltung, Einsatzhäufigkeit oder Operationserfolg.

Ein akzeptierter Schritt ohne abgeschlossene Anmeldung

Nach USER fordert ein Server das Passwort an. Folgt ein akzeptiertes PASS, scheint 230 User logged in die natürliche Antwort zu sein. RFC 959 kennt jedoch den regulären Zustand 332 Need account for login.

Die führende 3 bezeichnet keine Ablehnung. Der vorherige Befehl ist angenommen, die Handlung wartet auf weitere Information. Der Client soll ACCT senden und nicht das bereits akzeptierte Passwort wiederholen.

Damit hielt FTP zwei Aussagen auseinander, die moderne Dialoge oft zusammenlegen: Der Benutzer hat einen passenden Nachweis geliefert; der Server weiß dennoch nicht, welchem lokalen Konto die Nutzung zugeordnet oder unter welchem Kontext sie erlaubt werden soll.

ACCT war eine Antwort auf heterogene Betriebssysteme

RFC 385 führte den Befehl im August 1972 ein. Als Beispiel nannte es TENEX, wo neben Benutzer und Passwort eine separate Kontospezifikation erforderlich war.

Der Text unterschied ACCT ausdrücklich von PASS. Das Konto musste nicht fest an USER gebunden sein, konnte jederzeit eintreffen und zwischen Dateiübertragungen desselben Benutzers wechseln. Es konnte den Login vervollständigen oder erst für einen bestimmten Zugriff nötig werden.

„Account“ ist deshalb weder automatisch Bankkonto noch zweites Passwort. Die Syntax blieb eine Telnet-Zeichenkette. Projekt, Ressourcenallokation, Kostenstelle oder lokaler Berechtigungsbereich waren mögliche Bedeutungen, aber keine vom Protokoll vorgeschriebene Ontologie.

Die Zustandsfrage überlebte einen Wechsel der Nummern

1973 nahm RFC 542 ACCT in die Zugriffsbefehle auf. Sein älteres Antwortschema nutzte 331 Enter account für die Login-Ergänzung und 433, wenn ohne gültiges Konto nicht übertragen werden konnte und der Befehl neu zu senden war.

RFC 640 ordnete 1974 die dreistelligen Codes neu. Programme sollten aus den Ziffern den Ausgang und nächsten Zustand bestimmen, ohne standortabhängigen Antworttext zu parsen. 3yz wurde zur positiven Zwischenantwort, 5yz zum negativen Abschluss der konkreten Anfrage; x3z gruppierte Authentifizierung und Accounting.

So erhielt 331 die heutige Passwortfrage, 332 die Kontoanforderung für den Login und 532 die Kontoanforderung fürs Speichern. Wer eine alte Spur mit der späteren Tabelle liest, verwechselt, welche Information der Server damals verlangte.

332 behielt die Absicht, 532 gab sie auf

RFC 765 und RFC 959 behandeln auch das Konto, das erst nach dem Login für eine Operation benötigt wird. Ein Client sendet etwa STOR; der Server braucht dafür einen Kontokontext.

Bewahrt der Server STOR auf und wartet nur auf ACCT, antwortet er 332. Verwirft er den Befehl, antwortet er 532. Nach erfolgreichem ACCT muss der Client im zweiten Fall STOR erneut senden; im ersten Fall liegt die ursprüngliche Absicht bereits beim Server.

Die Codes bescheinigen somit Verwahrung, nicht Dateierfolg. Ein Adapter, der beide als dieselbe Ausnahme „account required“ ausgibt, weiß nicht, ob nur Kontext oder auch die Aktion erneut übertragen werden muss.

532 war keine Aussage über freien Speicher

„Need account for storing files“ klingt nach Speicherproblem. Für Kapazität hat RFC 959 jedoch andere Antworten: 452 steht für unzureichenden Systemspeicher, 552 für eine überschrittene Zuteilung des aktuellen Verzeichnisses oder Datensatzes.

Fehlender Kontext, fehlende Kapazität und überschrittenes Kontingent benötigen verschiedene Eingriffe. Wer sie in einer Storage-Fehlerklasse zusammenfasst, kann Speicher beschaffen, obwohl eine Kontozuordnung fehlt, oder einen verworfenen Befehl nie erneut auslösen.

Die Kontrollverbindung war nicht der Zugriffskontext

RFC 959 erlaubt ein neues USER auf derselben Verbindung. Dadurch werden bisherige Benutzer-, Passwort- und Kontoinformationen gelöscht und die Loginfolge beginnt neu. Übertragungsparameter bleiben erhalten; ein laufender Transfer endet noch unter den alten Zugriffsparametern.

Der Wechsel wirkt nicht rückwirkend. Der neue Benutzer übernimmt keine bereits fließenden Bytes, und das alte Konto darf nicht auf neue Befehle durchsickern. REIN löscht Benutzer und Konto ebenfalls, setzt andere Parameter zurück und lässt die Kontrollverbindung offen.

Für Audits genügt daher keine Verbindungs-ID. Vor jeder Operation muss die jüngste Folge aus USER, ACCT, REIN und Neuverbindung rekonstruiert werden. Eine früher akzeptierte Kontoinformation beweist keinen gegenwärtigen Kontext.

Unterstützung bedeutete nicht Pflicht zur Nutzung

RFC 1123 nahm ACCT in die Mindestmenge auf, die Server und Clients unterstützen müssen, soweit das zugrunde liegende System den jeweiligen Befehl zulässt. Damit sollten Clients einen legitimen dritten Zustand ausdrücken können.

Nicht jeder Standort musste Konten verlangen. War der erkannte Befehl lokal überflüssig, konnte 202 positiv bestätigen, dass keine solche Zuordnung nötig war. Sprachliche Interoperabilität und einheitliche Standortpolitik sind verschieden.

Das IANA-Register der FTP-Befehle und -Erweiterungen führt ACCT weiterhin als Basisbefehl der Zugriffskontrolle mit RFC 959 als Referenz. Der Eintrag belegt Syntax und Normquelle, nicht heutige Verbreitung, Stringbedeutung oder erfolgreiche Übertragung.

Der dritte Zustand bewahrte eine lokale Entscheidung

FTP vereinheitlichte Kontosysteme nicht. Es gab dem Server das Recht, seinen lokalen Kontext anzufordern, und dem Client die Information, ob Passwort, Login, Operationsannahme und Befehlsverwahrung wirklich dasselbe Ergebnis hatten.

Die dauerhafte Lehre ist keine Empfehlung für alte Kontoformulare. Sie lautet, Subjektnachweis, Ressourcenkontext und Operationsannahme nicht in ein einziges Login-Bit zu pressen. Verschwindet ein Zustand aus der öffentlichen Schnittstelle, kehrt er als standortspezifisches Skript, gemeinsam genutztes Geheimnis oder undiagnostizierbare Ablehnung zurück.

Quellen und Grenzen

Die geschlossene Basis besteht aus RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 und IANA. Sie belegt Semantik und Entwicklung, nicht aktuelle Implementierungen, Vertraulichkeit, Abrechnung, Verbreitung oder Abschluss einer Dateioperation.