Zusammenfassung

  • Nach ausdrücklicher Aktivierung verbietet UIDONLY Nachrichtensequenznummern und liefert UIDFETCH sowie VANISHED mit UIDs. Eine flüchtige Übersetzungstabelle entfällt; der Nachweis des Postfachzustands nicht.
  • Eine dauerhafte Referenz besteht aus Postfachname, UIDVALIDITY und UID. Ankündigung, Aktivierung, Befehlsabschluss, Cache-Commit und Anwendungsabgleich sind verschiedene Quittungen.

Wird in einem großen Postfach eine frühe Nachricht gelöscht, rücken die Sequenznummern aller folgenden Nachrichten nach. Während weitere Ereignisse eintreffen, muss ein Client die bewegliche Position ständig auf eine stabilere UID abbilden. Genau diese Arbeit nimmt UIDONLY aus dem Protokollpfad.

Die Angabe UIDONLY in CAPABILITY schaltet jedoch noch nichts um. Der Client muss ENABLE UIDONLY senden. Erst danach sind FETCH, STORE, SEARCH, COPY und MOVE ohne UID-Präfix unzulässig; ein Verstoß erhält UIDREQUIRED. Attributänderungen erscheinen als UIDFETCH, Entfernungen als VANISHED. Angebotene Fähigkeit und tatsächlich aktiver Modus sind getrennte Tatsachen.

Die Vereinfachung ist substanziell. Eine Sequenznummer beschreibt nur die derzeitige Position und wird nach einem EXPUNGE neu vergeben. Ohne diese Adresse sinkt das Risiko, dass eine verspätete Antwort der falschen Nachricht zugeordnet wird. Zugleich muss der Client nicht mehr zwei Namensräume laufend gegeneinander führen.

Die verbliebene UID ist trotzdem kein globaler Name. RFC 9051 bindet sie an ein Postfach und dessen durch UIDVALIDITY bezeichnete Generation. Kann der Server den alten Namensraum nicht erhalten, wechselt die Generation und die alten UIDs verlieren ihre aktuelle Autorität. Eine nackte UID in einem Auditprotokoll ist deshalb keine vollständige Referenz.

Auch UIDNEXT verspricht kein nächstes Objekt. Der Wert ist eine Untergrenze für spätere Vergaben, keine Zusage, dass genau diese UID existieren wird. Lücken sind zulässig, Nachrichten können verschwinden und veränderliche Flags können sich bei gleicher Identität ändern. Stabile Identität und abgeschlossener Zustand sind nicht dasselbe.

UIDONLY verändert weder EXISTS noch RECENT. Der Modus ist mit CONDSTORE und QRESYNC vereinbar; MODSEQ kann in UIDFETCH vorkommen. Er verlangt diese Synchronisationsverfahren aber nicht. Der optionale Sequenznummern-Abgleich von QRESYNC ist sogar verboten, weil er den verworfenen Namensraum zurückbringen würde. Saubere Adressierung liefert keine vollständige Historie.

COPY und MOVE zeigen dieselbe Grenze. COPYUID kann Quell-UID, Ziel-UID und die UIDVALIDITY des Ziels verbinden; die markierte Abschlussantwort belegt das Ende des IMAP-Befehls. Sie belegt nicht, dass Suchindex, Archiv, Webansicht oder mobiler Cache das Zielobjekt dauerhaft übernommen haben. Dafür ist eine weitere Quittung nötig.

Die verworfene Null-Lösung ist aufschlussreich. Ein früher Entwurf wollte die normale FETCH-Form behalten und das Feld der Sequenznummer mit null füllen. Das wurde abgelehnt, weil alte Clients den Platzhalter als echte Position behandeln und ihren Cache beschädigen könnten. Äußerliche Kompatibilität hätte den Bedeutungsbruch verborgen; eine eigene Antwortform macht ihn sichtbar.

Eine belastbare Beweiskette hält daher fest: Der Server bot UIDONLY an; diese Verbindung aktivierte es; das Postfach wurde mit dieser UIDVALIDITY gewählt; diese UIDs und Änderungen wurden beobachtet; der markierte Befehl endete; der Client schrieb die Änderung dauerhaft; die konsumierende Anwendung glich ihr Ergebnis ab. Kein einzelnes grünes Signal darf für die ganze Kette stehen.

Quellen