Zusammenfassung

  • UIDPLUS ergänzte erfolgreiche APPEND- und COPY-Befehle um UIDVALIDITY und die neu vergebenen Ziel-UIDs, sodass ein offline arbeitender Client die Mutation unmittelbar mit ihrem Ergebnis verbinden konnte.
  • Die Rückmeldung blieb auf Befehl und Mailbox-Generation begrenzt: Berechtigungen oder UIDNOTSTICKY konnten sie unterdrücken, COPYUID war keine globale Identität, und UID EXPUNGE löschte nur ausdrücklich genannte, bereits mit \Deleted markierte Nachrichten.

Gleiche Länge, eindeutige Zuordnung

Beim Kopieren einer Nachricht wandert ihre UID nicht in eine andere Mailbox mit. Der Zielordner besitzt einen eigenen Namensraum; der Server vergibt dort neue UIDs. Ein Client, der mehrere Nachrichten kopiert, muss deshalb nicht nur erfahren, welche Zielwerte entstanden, sondern welcher Wert zu welchem Ursprung gehört.

COPYUID liefert die UIDVALIDITY der Ziel-Mailbox, eine Quellmenge und eine Zielmenge. Beide Mengen müssen dieselbe Anzahl von UIDs enthalten. Die Reihenfolge definiert die Paarung. Weder * noch eine am Befehl unbeteiligte UID darf in der Antwort auftauchen.

Damit erhält der Client keine vage Liste möglicher Treffer, sondern eine überprüfbare Abbildung. Er kennt seine Eingabemenge und kann Anzahl und Position der Ausgabe kontrollieren. Die Werte müssen weder gleich noch lückenlos sein; ihre Autorität stammt aus der Serverantwort auf genau diesen COPY-Befehl.

Sichtbare Sequenznummern könnten dieselbe Aufgabe nicht zuverlässig erfüllen. Löscht eine andere Sitzung während des Kopierens eine Nachricht, werden nachfolgende Positionen neu nummeriert. UIDs halten den Befehlsumfang stabil, während sich die Ansicht bewegt.

Die Abbildung gilt dennoch nicht allgemein. RFC 8474 erklärt, dass ein anderer Client, der die COPY- oder MOVE-Antwort nicht gesehen hat, aus gewöhnlichen UIDs später keine mailboxübergreifende Gleichheit ableiten kann. Object IDs bearbeiten dieses weiter reichende Problem. COPYUID belegt das Ergebnis einer Operation für ihren Empfänger.

APPEND brauchte die vom Server gewählte Kennung

Bei APPEND sendet der Client eine Nachricht, doch der Server bestimmt ihre UID. Ein einfaches OK bestätigt die Erstellung, schließt aber die lokale Buchhaltung nicht: Welche entfernte Referenz ersetzt nun den wartenden Offline-Eintrag?

APPENDUID trägt die Antwort in den getaggten Erfolg. Es nennt zuerst die UIDVALIDITY des Zielordners, dann die vergebene UID. Der Client kann sein lokales Objekt mit dem Serverzustand versöhnen, ohne den Ordner erneut nach Betreff, Inhalt oder einer eigens eingefügten Markierung zu durchsuchen.

Die Generation ist kein Zusatzdetail. UID 3955 hat nur zusammen mit Server, Mailbox-Name und UIDVALIDITY eine belastbare Bedeutung. Wechselt die UIDVALIDITY, verliert die alte Zuordnung ihre Gültigkeit. UIDPLUS liefert also nicht nur einen Namen, sondern auch den Geltungsbereich dieses Namens.

Bei einem APPEND mehrerer Nachrichten kann die Antwort eine geordnete UID-Menge enthalten. Die erste Ausgabe gehört zur ersten Eingabe. Fremde UIDs und offene Sternbereiche sind verboten. Die Antwort bewahrt so die Form der Mutation.

Löschen als Schnittmenge

Der gewöhnliche EXPUNGE-Befehl entfernt dauerhaft jede Nachricht in der gewählten Mailbox, die \Deleted trägt. In gemeinsam genutzten Ordnern kann die Markierung aus einer anderen Sitzung und mit einer anderen Absicht stammen.

UID EXPUNGE verlangt zusätzlich eine UID-Menge. Entfernt wird nur, was sowohl in dieser Menge liegt als auch markiert ist. Eine genannte UID ohne Markierung bleibt erhalten; eine markierte Nachricht außerhalb der Menge ebenfalls. Der Client macht nicht sämtliche offenen Löschabsichten unwiderruflich, sondern nur seinen ausdrücklich abgegrenzten Teil.

Ohne UIDPLUS besteht der beschriebene Rückweg darin, die Markierung bei zu erhaltenden Nachrichten vorübergehend zu entfernen, EXPUNGE auszuführen und die Markierungen zurückzusetzen. Das kann funktionieren, verändert aber mehr gemeinsamen Zustand. UID EXPUNGE legt den irreversiblen Umfang in einem Befehl fest.

Ein korrekter Server durfte die Kennung verschweigen

Manche Berechtigungen gestatten APPEND oder COPY in eine Mailbox, verbieten aber SELECT und EXAMINE. Würde der Server trotzdem UIDVALIDITY und neue UIDs preisgeben, lieferte der Schreibvorgang Informationen über einen nicht einsehbaren Speicher. RFC 4315 verlangt deshalb in diesem Fall den Verzicht auf APPENDUID oder COPYUID.

Auch bei UIDNOTSTICKY darf die Antwort fehlen. Diese Kennzeichnung warnt, dass UIDs nicht sitzungsübergreifend beständig sind. Die Spezifikation rät von solchen neuen Speichern ab, erkennt ältere Beschränkungen aber an. Eine scheinbar dauerhafte Quittung für einen flüchtigen Namen wäre irreführend.

Das Fehlen des Codes hebt den Erfolg nicht auf. Hat der Client Leserechte, kann er den Zielordner auswählen und über FETCH oder SEARCH nach einer eindeutigen, zuvor gesetzten Markierung suchen. Dieser Ersatzweg trennt Ausführung, Sichtbarkeit und Persistenz, statt sie in einem Erfolgsbit zusammenzuziehen.

MOVE machte den Zeitpunkt zum Teil der Beweiskette

MOVE erzeugt im Ziel eine neue Nachricht und entfernt das Original. Ein UIDPLUS-Server soll bei UID MOVE COPYUID liefern, sofern keine der Ausnahmen greift. Treffen EXPUNGE-Meldungen zuerst ein, verändern sie die Quellansicht, bevor der Client die Zuordnung kennt.

RFC 6851 empfahl deshalb, COPYUID in einem ungetaggten OK vor den Löschmeldungen zu senden. RFC 9051 nahm diese Reihenfolge in IMAP4rev2 auf. Eine Zuordnung ist am nützlichsten, solange die Zustände, die sie verbindet, noch gemeinsam lesbar sind.

Von der Offline-Optimierung zur Kernregel

RFC 2359 führte UIDPLUS 1998 als Optimierung ein, besonders für getrennt arbeitende Clients. RFC 4315 ersetzte es 2005, präzisierte Mengen, Datenschutz-Ausnahmen und UIDNOTSTICKY. Die IANA führt UIDPLUS weiterhin mit RFC 4315; IMAP4rev2 integrierte die wesentlichen Mechanismen.

Aus einer Einsparung zusätzlicher Suchläufe wurde eine Disziplin für Ergebnisbelege. Sie verspricht keine universelle Transaktion. Sie sagt präzise, welche Zielreferenzen ein bestimmter Befehl in einer bestimmten Mailbox-Generation erzeugte und welchen stabilen Teil eine Löschung betraf.

Die Reichweite ist Teil der Wahrheit

UIDPLUS machte einen lokalen Namen nicht global und einen Erfolg nicht kryptografisch beweiskräftig. Seine Stärke liegt in der Begrenzung: Befehl, Ziel-Mailbox, UIDVALIDITY, Berechtigung und geordnete Mengen. Wo eine dieser Voraussetzungen fehlt, muss der Client entdecken statt behaupten.

Historisch zeigt die Erweiterung, dass Überprüfbarkeit nicht möglichst viele Daten verlangt. Sie verlangt genau jene Daten, mit denen sich die Folge einer Änderung prüfen lässt, sowie die Grenze, jenseits derer diese Daten keine Aussage mehr tragen.

Quellen und Grenzen

Die erste Fassung steht in RFC 2359, ersetzt durch RFC 4315. RFC 3501 liefert den IMAP4rev1-Kontext, RFC 6851 MOVE, RFC 8474 die Grenze für andere Clients und RFC 9051 die IMAP4rev2-Integration. Das IANA-Register verzeichnet UIDPLUS. Diese Quellen messen keine heutige Verbreitung und machen aus einer UID weder Authentifizierung noch globale Nachrichtenidentität.