Zusammenfassung

  • IMAP-Sequenznummern bezeichnen die gegenwärtige Position. Nach dem endgültigen Entfernen einer früheren Nachricht rücken spätere Nummern nach. UIDs überdauern Sitzungen, gelten aber nur in einem Postfach und einer UIDVALIDITY-Generation.
  • Ändert sich UIDVALIDITY, widerruft der Server die behauptete Kontinuität. Der Client muss den betroffenen Cache und alte UID-Befehle verwerfen, damit eine wiederverwendete Zahl nicht auf eine andere Nachricht wirkt.

Der alte Befehl traf eine neue Nachricht

Ein Laptop speichert den Posteingang für eine Reise ohne Netz. UID 4821 gehört dort zu einer Rechnung, die der Nutzer offline löschen will. Währenddessen zieht der Betreiber das Postfach auf einen Speicher um, der die bisherigen UID-Metadaten nicht übernehmen kann. Die Mails bleiben erhalten, werden aber neu nummeriert. Nun trägt eine andere Nachricht UID 4821.

Beim Wiederverbinden stimmen Benutzerkonto, Verschlüsselung und Befehlssyntax. Behält der Server trotzdem die alte UIDVALIDITY bei, wird aus einer zufälligen Zahlengleichheit eine angebliche Objektkontinuität. Ein berechtigter Löschbefehl vernichtet das falsche Stück.

IMAP lässt lieber den Cache scheitern. Eine neue UIDVALIDITY zwingt den Client, den lokalen Zustand dieses Postfachs und die vorgemerkte Aktion aufzugeben. Die sichtbare Neusynchronisierung schützt die unsichtbare Absicht des Nutzers.

Ein Listenplatz ist keine dauerhafte Identität

Sequenznummern sind relative Positionen im ausgewählten Postfach. Bei 30 Nachrichten reichen sie von 1 bis 30. Damit lassen sich Bereiche kompakt abfragen und Zuwächse berechnen.

Nach dem Expunge der Nummer 5 wird die bisherige 6 zur 5; alle späteren Nachrichten rücken nach. Dieselbe Zahl kann nacheinander verschiedene Objekte bezeichnen. RFC 2060 beschreibt dies für IMAP4rev1, RFC 9051 behält es in IMAP4rev2 bei.

Ein verbundener Client kann die laufenden Meldungen verarbeiten und seine Zuordnung anpassen. Ein Gerät im Funkloch sieht die Zwischenereignisse nicht. Nach der Rückkehr bedeutet „Nachricht 5“ nur den heutigen fünften Platz, nicht die gestrige Nachricht.

IMAP4 trennte 1994 Gedächtnis und Reihenfolge

RFC 1730 definierte IMAP4 im Dezember 1994 als Protokoll für entfernte Postfächer und die spätere Abgleichung offline genutzter Clients. Der 32-Bit-UID steigt innerhalb eines Postfachs streng an, darf Lücken haben und bleibt über Sitzungen hinweg bestehen.

Damit konnte ein Client gelesene Nachrichten und aufgeschobene Handlungen wiederfinden, ohne nach jeder Verbindung sämtliche Inhalte zu vergleichen. Doch diese Dauerhaftigkeit brauchte Unterstützung im realen Speicher. Ältere Mailstores besaßen keinen Platz für permanente UIDs; externe Programme konnten Dateien umordnen; ein Postfach konnte gelöscht und unter demselben Namen neu angelegt werden; bei einer Wiederherstellung konnten Inhalte ohne Identitätsmetadaten zurückkehren.

Das Protokoll verlangte keine unmögliche Ewigkeit und gestattete auch keine heimliche Wiederverwendung. Es verlangte einen sichtbaren Generationenwechsel.

UIDVALIDITY bezeichnet eine Generation, nicht das Postfach

Jedes Postfach liefert einen UIDVALIDITY-Wert. Wenn frühere UIDs nicht fortbestehen, muss die neue Zahl größer sein. Erstellungszeit oder monotoner Zähler sind mögliche Verfahren, nicht die eigentliche Semantik. Entscheidend ist, dass ein Client alte und neue UID-Welt unterscheiden kann.

RFC 2683 warnt vor einer verbreiteten Fehlannahme: UIDVALIDITY ist keine Postfachkennung. Zwei Postfächer dürfen denselben Wert haben. Auch UIDVALIDITY plus UID ergeben keine serverweit eindeutige 64-Bit-Identität. Der nötige Geltungsbereich umfasst Postfachname, UIDVALIDITY und UID.

RFC 3501 und RFC 9051 binden dieses Tripel dauerhaft an genau eine unveränderliche Nachricht auf dem Server. Text, Umschlag, internes Datum, Größe und Struktur dürfen darunter nicht zu einem anderen Inhalt werden. Änderbare Flags sind ausgenommen. Nach dem Expunge darf dieselbe UID in derselben Generation nicht neu vergeben werden.

Eindeutigkeit ist somit kein Zauber großer Zahlen. Sie entsteht aus Geltungsbereich, Nichtwiederverwendung und einer überprüfbaren Abbruchbedingung.

Auch ein unvollkommener Speicher musste ehrlich sein

Ein UIDVALIDITY-Wechsel ist teuer, weil Clients ihre Caches neu aufbauen. Deshalb empfehlen die Standards beständige UIDs nachdrücklich. RFC 4315 definiert dennoch UIDNOTSTICKY für alte Stores ohne Persistenz und rät zugleich davon ab, neue Systeme so zu entwerfen.

Die Ausnahme wird nicht versteckt. Kann der Server die Zusage nicht halten, muss er dies mitteilen. RFC 2683 nennt als schlimmste Folge eines ignorierten Wechsels das Löschen der falschen Mail mit einer veralteten UID. Ebenso können Verschieben, Kopieren, Markieren oder Abrufen ein ungewähltes Ziel treffen.

Scheinbare Verfügbarkeit verschiebt den Schaden nur vom Synchronisierungsvorgang in den Datenbestand des Nutzers.

Cache-Verlust entzog alten Handlungen ihre Befugnis

RFC 4549 beschreibt den Ablauf für getrennt arbeitende Clients. Beim Öffnen vergleicht der Client die erhaltene UIDVALIDITY mit seinem gespeicherten Wert. Stimmen sie nicht überein, muss er den Cache dieses Postfachs leeren, ausstehende Aktionen mit alten UIDs entfernen und als fehlgeschlagen behandeln.

Eine Zuordnung nach ähnlichem Betreff, Datum oder Umfang ist kein Ersatz. Solche Merkmale helfen bei der Suche, beweisen aber nicht, dass ein früherer Löschwunsch auf das gefundene Stück übertragbar ist. Mit der Generation verliert nicht nur ein Datensatz, sondern auch eine gespeicherte Absicht ihr Ziel.

Die Invalidierung bleibt postfachbezogen. RFC 2683 kritisiert serverweite UID-Zähler, weil sie den 32-Bit-Raum schneller verbrauchen und ein einziges Erschöpfungsereignis auf alle Postfächer ausdehnen könnten. Lokaler Geltungsbereich begrenzt den Schaden.

Verweise und Beschleunigung blieben der Gültigkeit untergeordnet

RFC 2192 erlaubte 1997 IMAP-URLs mit Postfach, UIDVALIDITY und UID. Das öffnende Programm sollte die gespeicherte Generation mit der aktuellen vergleichen und einen veralteten Verweis erkennen. UIDVALIDITY ist weder Ablaufdatum der Mail noch Authentizitätsbeweis; es ist der Alterungstest der Referenz.

RFC 7162 machte später den Abgleich mit CONDSTORE und QRESYNC schneller. Änderungsfolgen und VANISHED können Flag-Änderungen und entfernte UIDs oft in einem Rundlauf liefern. Der erste Zustandswert von QRESYNC ist jedoch die bekannte UIDVALIDITY. Bei Abweichung ignoriert der Server die restlichen Deltas.

Erst muss feststehen, dass dieselben Dinge verglichen werden. Danach lohnt die Frage, was sich an ihnen geändert hat.

UIDONLY entfernte Positionen, nicht den Generationenrahmen

Das Experimental RFC 9586 definierte im Mai 2024 UIDONLY. Nach der Aktivierung sind Sequenznummern in Befehlen und Antworten verboten; UID-Formen und VANISHED übernehmen. Client und Server können Ressourcen für die Zuordnung beweglicher Plätze zu UIDs sparen.

Das Dokument schreibt keine flächendeckende Nutzung vor. Es zeigt aber, dass die Entwicklung drei Jahrzehnte nach IMAP4 weiter von relativen Koordinaten wegführt.

Auch unter UIDONLY bleibt eine UID an Postfach und UIDVALIDITY gebunden. Weniger Mehrdeutigkeit bedeutet nicht grenzenlose Gültigkeit.

Dauerhaft wurde die Kennung durch ihren ehrlichen Widerruf

IMAP verteilt Verantwortung entlang des Wissens. Der Server kontrolliert den Speicher und muss erklären, ob UID-Kontinuität überlebt hat. Der Client kontrolliert Cache und aufgeschobene Absichten und muss ihnen beim Generationenwechsel die Wirkung entziehen. Bequemlichkeit darf auf keiner Seite als Beweis gelten.

Die gemeinsame Schicht bleibt dünn. Sie schreibt weder Speicherformat noch Migrationswerkzeug oder Clientdatenbank vor. Sie legt Invariante, Bruchsignal und sichere Reaktion fest. Implementierungen bleiben verschieden, doch eine alte Zahl darf nicht unbemerkt Befehlsgewalt über ein neues Objekt erhalten.

Die UID konnte Sitzungen überleben, weil UIDVALIDITY sagen kann, wann sie die Wiedergeburt des Postfachs nicht überlebt hat.

Quellen und Grenzen

RFC 1730 liefert den Entwurf von 1994; RFC 2060, RFC 3501 und RFC 9051 erklären Sequenznummern, UIDs und das Identitätstripel. RFC 2683 dokumentiert Implementierungserfahrung, RFC 2192 gespeicherte Verweise, RFC 4315 UIDNOTSTICKY, RFC 4549 Offline-Abgleich, RFC 7162 QRESYNC und RFC 9586 das Experimental UIDONLY. Daraus folgen weder heutige Verbreitungszahlen noch Aussagen über bestimmte Produkte, Mailauthentizität, Kryptografie oder einen einzig zulässigen UIDVALIDITY-Algorithmus.