Zusammenfassung

  • RFC 772 und RFC 780 boten R für recipients-first und T für text-first. Der Sender äußerte eine Präferenz, der Empfänger bestimmte die nutzbare Form.
  • MRSQ prüfte, wählte und setzte Zustand zurück. MRCP nannte Empfänger, bestätigte in R aber Listenspeicherung und in T die Anwendung eines bereits gespeicherten Textes.
  • RFC 788 und RFC 821 ersetzten beide Wege durch MAIL, wiederholtes RCPT, DATA. Ein Text blieb für mehrere Empfänger nutzbar; nur die externe Choreografie wurde vereinheitlicht.

Die Abfrage war zugleich ein Reset

In RFC 780 fragt MRSQ ? nach R oder T. Ohne Argument bestätigt MRSQ die Funktion und wählt keinen Modus. Mit R oder T versucht der Sender eine Auswahl, die der Empfänger ablehnen kann.

Jede MRSQ-Verwendung löscht Moduszustand. Eine Präferenzabfrage ist keine harmlose Leseoperation; sie kann gespeicherte Namen oder Text verwerfen. Diagnosesoftware darf sie nicht mitten in eine Transaktion setzen und danach denselben Zustand erwarten.

Der Empfänger entscheidet, weil er seine Ressourcen kennt. Ein zentraler Mailer braucht einen anderen Übergabepunkt als eine Implementierung, die Postfächer einzeln bearbeitet.

R speicherte zuerst eine Empfängertabelle

Im R-Modus liefert jedes MRCP TO:<path> einen eigenen Erfolg oder Fehler. Akzeptierte Pfade werden gesammelt; eine ungültige Adresse zerstört die übrigen nicht.

Anschließend überträgt ein MAIL ohne TO den Text einmal für alle gespeicherten Namen. Der Schlusserfolg gilt der Gruppe, ein Schlussfehler muss für die Gruppe als Fehler gelten. Danach wird die Tabelle geleert.

Das passt zu Systemen, die vollständige Liste und Inhalt als Paket an einen zentralen Mailer geben. Die Leitung trägt den Inhalt nicht pro Person.

Die Tabelle ist endlich. 452 kann einen vollen Namensspeicher anzeigen. Dann muss der Sender den Text für die bisherige Gruppe senden, weitere Namen sammeln und den Text wiederholen. Fünfzig Empfänger bei zehn Plätzen ergeben bis zu fünf Lose.

T speicherte zuerst den Text

Im T-Modus nimmt MAIL ohne Empfänger den Inhalt auf. Spätere MRCP-Befehle wenden die gespeicherte Kopie einzeln auf Adressen an und geben je einen Zustellwert zurück.

Der Text bleibt bis zum nächsten MAIL oder MRSQ erhalten. Er reist nicht für jede Adresse erneut; der Empfänger puffert statt einer Namenstabelle das größere Objekt.

Direkte inkrementelle Zustellung kann dadurch Quoten und Zugriffskonflikte pro Postfach melden. Der Text ist allerdings schon angenommen, bevor ein gültiger Empfänger feststeht.

MRCP vor gespeichertem Text entspricht einem Versuch mit leerer Nachricht und kann implementationsabhängig akzeptiert oder abgelehnt werden. Reihenfolge ist Zustandsvoraussetzung.

Ein 2xx brauchte den Modus als Kontext

R-MRCP bestätigt primär einen Platz in der Liste; der gemeinsame Textschritt steht noch aus. T-MRCP verarbeitet einen bereits vorhandenen Text für genau diesen Adressaten. Gleiches Verb und gleicher Zahlenbereich belegen Verschiedenes.

MRSQ und normales MAIL können Zustand zurücksetzen. Fehlt diese Zeile im Protokoll, lässt sich ein späteres MRCP leicht mit einem bereits gelöschten Text oder einer alten Liste verbinden.

Zwei Reihenfolgen vergrößern damit den gemeinsamen Zustandsraum: zwei Pufferobjekte, andere Beweiszeitpunkte und mehrere Löschgrenzen. Lokale Optimierung wird zur Pflicht aller Gegenstellen.

Der Empfänger kannte die Werkstatt

RFC 780 begründet R mit vollständigen Übergaben an zentrale Mailer. T dient Empfängern, die direkt und schrittweise zustellen und variable Ergebnisse pro Postfach besitzen.

Der Sender kennt weder Tabellengröße noch Speicherpreis oder lokale Architektur. Seine Präferenz ist schwächer als die Fähigkeitserklärung der Seite, die Ressourcen hält und Fehler verantwortet.

Für eine Verbindung ist diese Autorität sinnvoll. Netzweit müssen dafür aber Clients, Relays und Analysewerkzeuge beide Pfade beherrschen. Nicht jede berechtigte lokale Wahl muss Teil der öffentlichen Grammatik bleiben.

SMTP machte die sichtbare Reihenfolge fest

RFC 788 ordnet drei Schritte: MAIL FROM eröffnet und nennt den Absender; ein oder mehrere RCPT TO verhandeln Adressaten; DATA bringt den Inhalt. Der Dialog ist bewusst lock-step und die Reihenfolge verbindlich.

MRSQ und das Mail-MRCP fehlen. Ein abgelehntes RCPT muss die übrige Transaktion nicht verwerfen. Der Text folgt erst für die angenommene Menge.

RFC 821 behält das Modell. Server dürfen intern weiterhin bündeln, puffern oder einzeln prüfen. Nur der Vertrag zwischen den Peers besitzt eine Choreografie.

Externe Einheitlichkeit schränkt lokale Implementierung weniger ein, als es zunächst scheint. Ein Server kann seinen Mailer ersetzen, ohne alle Clients einen neuen Modus lernen zu lassen.

Ein Text für viele blieb erhalten

R und T sollten wiederholte Textübertragung vermeiden. SMTP erreichte dasselbe mit einem MAIL, mehreren RCPT und einem DATA.

RFC 788 und RFC 821 empfehlen eine Datenkopie für mehrere Empfänger am selben Ziel. RFC 1123 drängt ausdrücklich zu RCPT, RCPT, ... RCPT, DATA statt wiederholtem RCPT, DATA.

Die Konvergenz verlor also nicht das ökonomische Ziel. Sie entfernte die Text-zuerst-Variante und machte Empfänger-zuerst zur gemeinsamen Form.

PIPELINING ändert Wartezeit, nicht Abhängigkeit

Lock-step erzeugt viele Rundreisen. PIPELINING kann zulässige Befehle vor Antworten senden, stellt DATA aber nicht vor RCPT.

MRSQ T bestimmte, welcher Zustand zuerst existiert. PIPELINING beschleunigt eine bereits geordnete Folge. Zeitliche Nähe von Bytes ist keine neue Transaktionsordnung.

Diese Abgrenzung trennt den Gegenstand vom vorhandenen PIPELINING-Artikel und verhindert falsche Deutung kompakter Mitschnitte.

Der heutige Rahmen bleibt einheitlich

RFC 5321 hält an MAIL, einem oder mehreren RCPT und DATA fest. Erweiterungen fügen Parameter hinzu, nicht die R/T-Wahl.

Intern können Server unterschiedliche Prüf- und Warteschlangengrenzen haben. Die feste Oberfläche hält diese Unterschiede aus dem Clientvertrag heraus und verkleinert den Zustand, den das ganze Netz teilen muss.

Die Vereinfachung erklärt nicht T zum Fehler. Sie verlegt eine legitime Optimierung hinter eine stabile Schnittstelle.

MRCP bezeichnet später etwas anderes

MRCP ist hier der MTP-Befehl Mail Recipient. Das spätere Media Resource Control Protocol für Sprachressourcen hat trotz gleicher Buchstaben keine technische Verbindung.

Recherche muss MRCP mit MRSQ, Mail oder RFC 772/780 verbinden. Ein Akronym allein beweist keine historische Identität.

Quellen und Grenzen

Die Dokumente belegen damit einen Wandel der spezifizierten Zustandsmaschine, nicht automatisch einen gleichzeitigen Wechsel jeder laufenden Installation. Gerade diese Trennung schützt die Analyse davor, aus einer klaren Protokollfolge unbelegte Nutzungszahlen oder einen einzigen historischen Abschaltmoment abzuleiten.

Verwendet werden RFC 772, 780, 788, 821, 1123 und 5321. Sie belegen Modi, Resets, Empfängerautorität, Ressourcenlimits, SMTP-Reihenfolge und erhaltene Mehrfachempfängerökonomie.

Sie messen keine Installation, nennen kein einzelnes Abschaltereignis und versprechen keinen universellen Leistungsgewinn. RFC 788 definiert schlicht eine andere, einzige Sequenz.

R ist nicht atomare Zustellung, T keine Textwiederholung pro Empfänger. Entscheidend sind Zustand und Beweiszeitpunkt.