Zusammenfassung

  • Ein Server durfte DELETE oder RENAME verweigern, das Postfach für bestehende Sitzungen „geistern“ lassen oder andere Clients nach erfolgreicher Löschung trennen.
  • Clients mussten verzögerte EXPUNGE-Antworten, Teilresultate und wandernde Sequenznummern verarbeiten; das Verhalten eines vertrauten Servers war nicht der gesamte Protokollvertrag.

Der Name verschwand vor dem Inhalt

Zwei Clients haben FOO ausgewählt. Client eins sendet DELETE FOO und erhält OK. Ein neuer Client kann FOO nicht mehr per STATUS finden und den Namen noch nicht neu anlegen. Client zwei kann trotzdem FETCH oder STORE im bereits ausgewählten Postfach ausführen.

RFC 2180 beschreibt diese referenzgezählte Geisterkopie ausdrücklich. Erst wenn die letzte Sitzung schließt, werden die Informationen endgültig entfernt und der Name wieder frei. Ebenso zulässig sind die Ablehnung der Löschung bei Nutzung oder die Löschung mit anschließendem BYE an andere Sitzungen.

Die Varianten verteilen Kosten verschieden. Ablehnung schützt laufende Arbeit, kann ein stark genutztes Postfach aber faktisch unlöschbar machen. Ghosting erhält Kontinuität, verzögert jedoch die Entfernung sensibler Informationen. Trennung schafft einen härteren Schnitt, beendet aber legitime Sitzungen.

Beim RENAME kann der Server nur das Namensattribut ändern. Eine ausgewählte Sitzung arbeitet mit namenlosen Befehlen wie FETCH weiter. Erst ein APPEND FOO entdeckt den alten Namen und kann einen NEWNAME-Hinweis erhalten. Namensraum und ausgewählter Zustand sind getrennte Beobachtungsflächen.

EXPUNGE änderte die Liste, bevor die Meldung eintreffen durfte

Nach RFC 2060 sind Sequenznummern aktuelle Positionen. Wird eine Nachricht expungiert, rücken spätere Positionen nach. Während der Antwort auf FETCH, STORE oder SEARCH darf der Server aber keine EXPUNGE-Antwort einfügen. Die Änderung ist bereits wirksam, während der Client noch die alte Karte benutzt.

RFC 2180 erlaubt mehrere Reaktionen: gelöschte Nachrichten vorübergehend aufbewahren; nur bestehende Treffer liefern und mit NO enden; für verschwundene Nachrichten NIL-förmige Daten und für die übrigen normale Daten liefern und mit OK enden; oder EXPUNGE bei Mehrfachzugriff verweigern.

NIL kann einen echten leeren Wert oder eine verschwundene Nachricht bedeuten. Wenn der Unterschied zählt, muss der Client mit NOOP ausstehende EXPUNGE-Meldungen auslösen und seine Sequenzkarte korrigieren.

Auch STORE.SILENT zeigt die enge Bedeutung von Erfolg. Wurden alle noch vorhandenen Nachrichten geändert, kann OK folgen, obwohl andere Nummern des angeforderten Bereichs bereits verschwunden sind. Der Beleg gilt für ausführbare Arbeit, nicht für den unveränderten Bestand der ursprünglichen Menge.

COPY stabilisierte nur die Referenz eines Befehls

COPY interpretiert die Sequenznummern zu Beginn. Verschieben sie sich währenddessen, müssen bei Erfolg trotzdem genau die anfangs identifizierten Nachrichten im Ziel erscheinen. Bei Misserfolg ist das Ziel in den vorigen Zustand zurückzuversetzen.

Das ist kein Postfach-Snapshot. Es ist eine begrenzte Zusage darüber, was dieser eine Befehl meinte. Andere Sitzungen und spätere Befehle bleiben beweglich.

Historische Praxis statt heutiger Produktbehauptung

Der Informationseintrag des RFC Editor klassifiziert RFC 2180 als informativ; der Text erklärt selbst, weder Konformität zu definieren noch alle gültigen Verhaltensweisen aufzuzählen. RFC 2060 bleibt die Grundlage. Der Text belegt daher keine heutige Providerstrategie, keine Verbreitungsquote und keine physische Löschung in einem benannten System.

Sein historischer Wert liegt in der Verantwortungsverteilung: Serverflexibilität ist nur dann interoperabel, wenn Clients alle erlaubten Antworten beherrschen und nicht eine lokale Gewohnheit verallgemeinern.

RFC 2177 beschleunigte Benachrichtigungen mit IDLE. RFC 7162 reduzierte mit Mod-Sequenzen, VANISHED und QRESYNC den Aufwand der Wiederabstimmung. Doch schnellere Information macht OK nicht zum Nachweis sofortiger globaler Einigkeit.

Befehlsabschluss, Namensentfernung, Sitzungsentzug und Byte-Löschung sind vier Tatsachen. RFC 2180 bewahrt ihre Grenzen.