Zusammenfassung

  • CLOSE wechselte von Selected nach Authenticated und entfernte in einem beschreibbaren Postfach sämtliche mit \Deleted markierten Nachrichten dauerhaft. Einzelne ungetaggte EXPUNGE-Antworten blieben aus.
  • RFC 3691 führte UNSELECT ein. Der Befehl gibt den ausgewählten Kontext frei, löscht aber nichts. Damit wurden Ressourcenfreigabe und irreversible Datenentscheidung getrennt sichtbar.

Der Name CLOSE klingt nach Aufräumen. Ein Mailprogramm ist mit dem Postfach fertig, gibt den Zustand beim Server ab und bleibt für weitere Arbeit angemeldet. Genau dieses Bild konnte bei IMAP täuschen.

In einem beschreibbar ausgewählten Postfach hatte CLOSE eine zweite Wirkung. Alle Nachrichten mit dem Flag \Deleted wurden dauerhaft entfernt. Das Flag konnte aus einer früheren Handlung oder einer anderen Sitzung stammen. Wer jetzt nur den Arbeitskontext verlassen wollte, bestätigte dennoch den gesamten wartenden Satz.

RFC 3691 schuf 2004 den fehlenden Ausdruck. UNSELECT besitzt keine Argumente. Nach Erfolg ist die Verbindung wieder Authenticated, die Ressourcen der Auswahl sind frei, doch keine Nachricht wird wegen dieses Befehls entfernt.

Die Erweiterung zeigt, weshalb dasselbe Ziel in einer Zustandsmaschine nicht dieselbe Befugnis bedeutet.

Auswahl war ein serverseitiger Arbeitszustand

Nach der Anmeldung kann ein IMAP-Client Postfächer verwalten, für nachrichtenbezogene Befehle wählt er jedoch eines aus. In Selected beziehen sich Suche, Abruf, Flag-Änderung, Kopie und Löschung auf diesen Kontext. Der Server hält dazu Beobachtungen und meldet Veränderungen.

Das Ende dieser Auswahl muss weder die TCP-Verbindung noch die Authentifizierung beenden. Ein Client kann zu einem anderen Postfach wechseln oder angemeldet warten. Der Übergang zurück zu Authenticated ist deshalb eine eigenständige, alltägliche Operation.

CLOSE vollzog diesen Übergang und zugleich Expunge. Eine reine Zustandszeichnung verbirgt den Unterschied: Beide Wege enden am selben Knoten, aber nur einer kann gespeicherte Nachrichten vernichten.

\Deleted ist zunächst eine Vormerkung. Erst Expunge entfernt die Nachricht endgültig. So lassen sich Kandidaten markieren und später gemeinsam bestätigen. Dadurch können aber auch Markierung und Bestätigung von verschiedenen Akteuren stammen. Ein allgemeiner Aufräumbefehl darf diese Herkunft nicht stillschweigend zusammenziehen.

Weniger Antworten änderten nicht die Löschwirkung

Der normale Befehl EXPUNGE sendet für jede entfernte Nachricht eine ungetaggte Antwort. Darin steht eine message sequence number, also eine aktuelle Position. Nach jeder Entfernung rücken spätere Positionen auf; die Antwortfolge beschreibt diese Bewegung.

CLOSE spart diese Folge. Wer das Postfach ohnehin verlässt, braucht die neuen Positionen meist nicht. Bei vielen Löschungen kann das deutlich schneller sein.

Die Kürze war aber keine Negativbescheinigung. Ein getaggtes OK bestätigt den Abschluss von CLOSE, nicht die Abwesenheit einer Löschung. Es liefert auch keine Liste stabiler UIDs. Gerade die irreversible Wirkung kommt ohne Einzelmeldungen aus.

Auch der Auswahlmodus zählt. Nach EXAMINE oder einer sonst schreibgeschützten Auswahl entfernt CLOSE nichts und meldet deswegen keinen Fehler. Derselbe Befehl kann also mit Erfolg und ohne Mutation enden oder mit Erfolg dauerhaft löschen. Ohne Postfach, Modus, vorherige Flags und gewählten Ausgang bleibt die Beobachtung unvollständig.

Der sichere Ausgang war zuvor ein Umweg

IMAP4rev1 erlaubte SELECT, EXAMINE oder LOGOUT, ohne vorher CLOSE zu senden. Dabei endete die bisherige Auswahl implizit ohne Expunge. Ein zerstörungsfreies Ergebnis war also möglich.

Es fehlte der direkte Fall: kein Postfach mehr auswählen, angemeldet bleiben, nichts löschen. RFC 3691 nennt zwei damalige Methoden. Ein Client konnte absichtlich ein nicht vorhandenes Postfach auswählen und den Fehlschlag als Rückweg nach Authenticated verwenden. Oder er wählte dasselbe Postfach mit EXAMINE erneut.

Die erste Methode macht einen erwarteten Fehler zum Normalpfad. Protokolleinträge vermischen Absicht und Defekt; Fehlerkennzahlen verlieren Aussagekraft. Die zweite öffnet eine schreibgeschützte Sicht, obwohl der Client überhaupt keine Sicht behalten will. Beide Methoden funktionieren über Nebenwirkungen fremder Befehle.

UNSELECT sagte die Absicht unmittelbar. Dadurch mussten Server, Protokollanalysen und spätere Implementierer keinen versteckten Kontrollfluss mehr erraten.

Capability statt Versionsfolklore

Ein IMAP4rev1-Server zeigte seine Unterstützung mit der Capability UNSELECT. Erst danach konnte der Client den neuen Befehl verwenden. Eine Ablehnung eines unbekannten Wortes war kein erfolgreicher Ausgang; die Verbindung konnte Selected bleiben.

Die Aushandlung beweist weder Benutzeridentität noch Datenechtheit. Sie schafft nur eine gemeinsame, begrenzte Semantik. Das genügt, um vor dem Senden zu wissen, dass dieser Übergang kein Expunge enthält.

UNSELECT entfernt vorhandene Flags nicht, holt bereits gelöschte Nachrichten nicht zurück und sperrt konkurrierende Sitzungen nicht. Nach späterer Auswahl können Markierungen fortbestehen und durch einen anderen autorisierten Befehl endgültig werden. Der Befehl bewahrt den Entscheidungspunkt, nicht jede Nachricht für immer.

IMAP4rev2 machte die Trennung zum Grundwortschatz

RFC 9051 nahm UNSELECT in den Grundbestand von IMAP4rev2 auf. Sowohl CLOSE als auch UNSELECT führen von Selected nach Authenticated. Die Datenwirkung bleibt verschieden: CLOSE entfernt in der beschreibbaren Auswahl alle markierten Nachrichten; UNSELECT entfernt keine.

Damit wurde eine kompatible Reparatur gewöhnlich. Alte indirekte Wege wurden nicht umgedeutet, doch eine normale Absicht musste nicht länger durch einen künstlichen Fehler oder eine unnötige Neuauswahl ausgedrückt werden.

Das Muster reicht über Mail hinaus. Eine Datenbankverbindung kann nach Commit oder Rollback schließen. Eine Datei kann nach Flush oder nach Verwerfen eines Puffers freigegeben werden. Wer nur den Endzustand erfasst, verliert die Entscheidung auf dem Weg.

UNSELECT verringerte die implizite Vollmacht. Die Bitte, Ressourcen freizugeben, autorisiert keine endgültige Entfernung. Für den irreversiblen Schritt braucht es einen Befehl, der ihn ausdrücklich trägt.

Verlorene Bestätigungen machten die Wortwahl operativ

Zwischen Absenden und Empfang des getaggten Ergebnisses kann die Verbindung abbrechen. Dann kennt der Client seinen lokalen Wunsch, aber nicht sicher den vom Server erreichten Zustand. Bei UNSELECT betrifft die Ungewissheit vor allem, ob die Auswahl noch besteht. Bei CLOSE betrifft sie zusätzlich eine möglicherweise bereits vollzogene dauerhafte Entfernung.

Ein automatischer Wiederholungsmechanismus darf diese Fälle nicht gleich behandeln. Erneutes Anmelden und Beobachten kann zeigen, ob das Postfach noch ausgewählt werden muss; es kann eine bereits entfernte einzige Kopie nicht zurückbringen. Die richtige Wiederherstellung beginnt deshalb mit einer Zustandsfeststellung und den stabilen Nachrichtenbelegen, nicht mit blindem Wiederholen des letzten Verbs.

Auch Bibliotheksabstraktionen tragen Verantwortung. Eine Methode namens closeMailbox() wirkt neutral. Wenn sie ohne sichtbar gemachte Option CLOSE sendet, versteckt sie die Expunge-Entscheidung vor jeder aufrufenden Anwendung. Eine sichere Schnittstelle sollte Freigabe und Lösch-Commit getrennt benennen, unterschiedliche Berechtigungs- und Bestätigungspfade zulassen und den gewählten Pfad protokollieren.

Der historische Nutzen von UNSELECT liegt damit auch in der Fehlerbehandlung. Ein kleinerer Befehlseffekt lässt einen kleineren ungewissen Bereich zurück. Er macht nicht jede Störung harmlos, verhindert aber, dass die gewöhnliche Wiederherstellung einer Sitzung zugleich eine Entscheidung über unwiederbringliche Nutzerdaten wiederholt.

Erfolg war nicht dasselbe wie ein Löschbeleg

Der getaggte Erfolg sagt, dass der Server den Befehl abgeschlossen hat. Er sagt bei CLOSE nicht einzeln, welche Nachrichten entfernt wurden, und bei UNSELECT nicht, dass vorhandene Flags verschwunden sind. Für belastbare Rechenschaft müssen Ergebnis, vorheriger Zustand und nachfolgende Beobachtung zusammengesetzt werden.

Gerade deshalb ist die Trennung der Verben wertvoll. Sie erlaubt schon vor dem Senden eine eindeutige Aussage über die beabsichtigte Klasse des Effekts. Das ist stärker als eine nachträgliche Vermutung aus einem knappen Erfolgscode. Wo irreversible Folgen möglich sind, sollte das Protokoll die Absicht am Eingang sichtbar machen und nicht erst vom Ergebnis her erraten lassen.

Quellen