Zusammenfassung

  • RFC 1204 empfahl 250 für einen syntaktisch gültigen USER, auch wenn der Posting-Server den Namen nicht erkannte. Die Gleichbehandlung sollte Kontoabfragen verhindern, nicht Existenz bestätigen.
  • Ein späteres PASS 250 erklärte dagegen das Kennwort als passend zum zuvor genannten Benutzer. DATA 354 öffnete nur den Texteingang; das 250 nach dem Text stand für lokale Einreihung.
  • NOOP 250 beschrieb lediglich einen Posting-Server ohne bekannten internen Sitzungsfehler. Ohne Befehl, Zustand und ausstellende Komponente ist der Code keine eigenständige Tatsache.

Die bejahende Antwort sollte eine Frage offenlassen

In RFC 1204 beginnt die Schutzmaßnahme mit einem unscheinbaren USER. Der Client nennt einen Benutzernamen, der Server kann ihn mit 250 annehmen. Unmittelbar danach empfiehlt der Text dieselbe Antwort für einen unbekannten Namen, sofern dessen Syntax stimmt.

Damit sollte der Client die Benutzerdatenbank nicht als Auskunftsdienst missbrauchen können. Ein vorhandenes und ein nicht vorhandenes Konto sahen von außen gleich aus. Der Server verlor die interne Unterscheidung nicht; er verweigerte nur, sie an dieser Protokollstelle offenzulegen.

„Akzeptiert“ bezeichnete folglich den Eingang in den nächsten Dialogzustand. Es war kein Urteil über die Existenz des bezeichneten Kontos. Ein Auswertungssystem, das aus USER 250 ein gültiges Konto macht, setzt die gewollte Anti-Enumeration-Eigenschaft außer Kraft.

Der RFC-Editor-Eintrag führt das Dokument als Experimental und datiert es auf Februar 1991. Der heutige IETF-Datatracker ordnet es dem Legacy-Stream zu: Es entstand vor der formalen Quellenzuordnung, ist nicht vom IETF gebilligt und hat im aktuellen Standardisierungsprozess keinen formalen Rang. Das begrenzt die Aussage auf einen historischen Entwurf.

Der Posting-Server war Vermittler, nicht Endpunkt jeder Entscheidung

RFC 1204 beschrieb Personalcomputer-Betriebssysteme jener Zeit als Systeme ohne Benutzerauthentisierung. Für E-Mail sollte dennoch die Absenderfälschung erschwert werden. Ein Message Posting Server auf einem Mail-Service-Host sollte deshalb den PC-Nutzer prüfen und dessen Nachricht an ein Zustellsystem wie Sendmail oder MMDF übergeben.

Die Rollen blieben getrennt. Der PC lieferte Eingaben. Der Posting-Server besaß lokale Kontenprüfung und Warteschlange. Das Delivery System übernahm spätere Zustellversuche. Netix MPP lief über TCP-Port 218 und übernahm Befehls- und Antwortformen aus SMTP und FTP.

RFC 821 hatte den schrittweisen SMTP-Dialog, nummerierte Replies, DATA und den Punktabschluss beschrieben. MPP nutzte diese Grammatik an einer anderen Grenze. Ein vertrauter Code erhielt seinen Gegenstand weiterhin aus Befehl und Zustand.

PASS gab der zweiten Antwort einen anderen Gegenstand

Nach USER 250 durfte der Client PASS senden. Ein 250 bedeutete nun, dass das Kennwort als korrekt zum zuvor genannten Benutzer gehörend geprüft worden war. 530 stand für eine falsche Zuordnung; Form-, Reihenfolge- und interne Fehler hatten eigene Antworten.

Die erste positive Antwort hielt Kontenerkennung geheim. Die zweite dokumentierte eine konkrete Credential-Beziehung. Nur durch diese Trennung konnte die Außenfläche gleichförmig bleiben, während der Server intern tatsächlich authentisierte.

Auch PASS 250 war keine universelle Identitätsurkunde. RFC 1204 wusste damit nicht, welche natürliche Person die Tastatur bediente, wer den Text verfasst hatte oder ob jede Zieladresse erlaubt war. Die Aussage gehörte zum konfigurierten Konto und zum Posting-Server.

Die spätere RFC 4954 definierte SMTP AUTH als ausgehandelten SASL-Austausch. Sie verlangte außerdem eine Konfiguration, die Klartext-Kennwortmechanismen ohne TLS oder gleichwertigen Schutz vor Ausspähung unterbindet. Diese Regeln dürfen nicht rückwirkend MPP zugeschrieben werden. Sie zeigen, dass Authentisierungsmechanismus und Kanalschutz eigene Nachweise brauchen.

354 öffnete den Parser, nicht die Warteschlange

Nach erfolgreicher Kennwortprüfung folgte DATA. Mit 354 erklärte sich der Posting-Server bereit, Nachrichtentext anzunehmen. Der Parser wechselte den Modus; ein vollständiger Body war noch nicht eingetroffen.

Erst nachdem Text und SMTP-artige Endsequenz vollständig ankamen, konnte ein weiteres 250 melden, dass der Text erfolgreich zur Zustellung eingereiht worden war. Verhinderte ein interner Fehler die Aufnahme, zeigte 451, dass keine Einreihung stattgefunden hatte.

Die Queue war echte lokale Obhut, aber noch keine Zustellung. Der Posting-Server sollte angenommene Nachrichten möglichst bald an das Delivery System übergeben. Zustellfehler sollte danach dieses System behandeln; der Posting-Server sollte sich nicht einmischen.

Eine lokale Queue konnte deshalb weder Relay-Annahme noch Mailbox-Speicherung, Anzeige oder menschliche Kenntnisnahme bezeugen. Die Verantwortung des ersten Systems endete genau dort, wo die Beobachtung des nächsten begann.

Ein Health-Check verwendete denselben Code

NOOP veränderte keine Nachricht. Sein 250 sagte nur, dass dem Posting-Server in der aktuellen Sitzung kein interner Fehler begegnet war. Es prüfte nicht das Delivery System.

Vier gleich aussehende Replies konnten daher heißen:

  • Namenssyntax zulässig, Erkennung absichtlich verborgen;
  • Kennwort-Beziehung zum vorherigen Namen geprüft;
  • vollständiger Nachrichtentext in lokaler Queue;
  • kein bekannter interner Sitzungsfehler im Posting-Server.

Eine Normalisierung auf success=true entfernt Objekt und Zuständigkeit. Brauchbare Evidenz bewahrt Protokoll, Verbindung, Befehl, Reihenfolge, Vor- und Nachzustand, antwortende Komponente und den konkreten Gegenstand der Entscheidung.

Spätere Submission-Regeln benannten die Rollen ausdrücklich

RFC 6409 formalisierte später die Nachrichteneinlieferung auf Port 587. Ein Message Submission Agent nimmt Nachrichten vom User Agent an und stellt sie selbst zu oder reicht sie an einen Message Transfer Agent weiter. Submission und Relay können deshalb unterschiedliche Sicherheits- und Betriebsregeln tragen.

Die strukturelle Ähnlichkeit belegt keine direkte Abstammung und keine MPP-Verbreitung. Sie bestätigt nur, warum Rollennamen wichtig sind. Ein Submission-System darf einen lokalen Erfolg aussprechen, ohne das Ergebnis des gesamten Pfades zu kennen.

RFC 1204 ist damit weniger eine Geschichte über eine vergessene Portnummer als über präzise Ungewissheit. Der erste Erfolg verbarg ein Kontofaktum, der zweite prüfte ein Geheimnis, der dritte übernahm Queue-Obhut, und ein vierter beschrieb lokale Gesundheit. Die Ziffern blieben gleich, die Autorität wechselte.

Quellen