Zusammenfassung

  • RFC 10022 liefert absteigende UID-Bereiche nahe einer gewünschten Nachrichtenanzahl. Sie bereiten spätere Befehle vor, auch unter UIDONLY; sie sind weder eingefrorene Seiten noch gespeicherte Suchergebnisse.
  • Bereichsgrenzen müssen keine vorhandenen Nachrichten bezeichnen. Stapel dürfen kleiner ausfallen, nach Löschungen schrumpfen und trotz gleicher Zählung sehr unterschiedliche Byte-, Zeit- und Rechenkosten verursachen.
  • Daniel Eggert redigierte das IETF-Konsensdokument. Der gemeinsame Mechanismus bleibt absichtlich schmal und überlässt Algorithmus, Planung, Konsistenzbehandlung und Dienstergebnis den ausführenden Parteien.

Ein Synchronisationsdienst wählt 2.000 Nachrichten, weil ein früher Test damit unter einer Sekunde blieb. Monate später dauert derselbe Zähler zehn Sekunden. Der Befehl ist unverändert, aber die Nachrichten sind größer, der Suchindex anders und der Server ausgelasteter. Wer die Zahl „2.000“ als Leistungszusage speichert, hat die Beobachtung durch die Konfiguration ersetzt.

RFC 10022, IMAP UIDBATCHES Extension, erschien im Juli 2026 als Proposed Standard. Herausgeber ist Daniel Eggert von Apple Inc. Die Erweiterung lässt einen Client im ausgewählten Postfach UID-Bereiche vorab bestimmen, damit spätere FETCH-, SEARCH- oder STORE-Befehle nur eine handhabbare Anzahl von Nachrichten betreffen.

Unter UIDONLY ist das besonders nützlich, weil Nachrichtensequenznummern nicht verfügbar sind. Doch ein handhabbarer Bereich ist keine stabile Seite. Die Spezifikation hält diese Grenze an mehreren Stellen offen sichtbar.

Die Zählgrenze ist keine Leistungsgrenze

Der Client muss mindestens 500 Nachrichten je Stapel anfordern. Der Server darf nie mehr als die gewünschte Zahl in einem Bereich zurückgeben. Er sollte den exakten Wert und möglichst mindestens 90 Prozent erreichen. Für wesentlich einfachere oder effizientere Implementierung sowie bei Postfachänderungen während der Berechnung darf er kleiner bleiben. Der letzte Stapel enthält üblicherweise den Rest.

Diese Regeln beziehen sich auf vorhandene Nachrichten, nicht auf Bytes. Der Abruf von Headern unterscheidet sich von ganzen Nachrichtentexten. Eine indexierte Suche unterscheidet sich von einer Inhaltsprüfung. STORE kann zusätzliche Zustandsarbeit auslösen.

Die RFC beschreibt eine Optimierung, die Serverarbeit, übertragene Daten und Speicherverbrauch senken kann. Sie verspricht keine feste Antwortgröße und keine gleichmäßige Laufzeit. Für Kapazitätsplanung müssen tatsächliche Nachrichten, Bytes, Server- und Clientzeit, Befehlstyp, Fehler und Wiederholungen gemessen werden.

Auch das Ziel muss benannt sein. Soll die Stapelgröße Speicherspitzen, Netzlast, Serverlatenz oder sichtbaren Fortschritt begrenzen? Ein einziger Zähler kann diese Ziele nicht gleichzeitig vertreten. Lokale Politik bleibt verantwortlich für ihre Messgröße.

Numerische Grenzen sind keine Bestandsliste

Der Server ordnet die Bereiche von hohen zu niedrigen UIDs. Die Start- und End-UID eines Bereichs müssen aber keine existierenden Nachrichten sein. Löschungen hinterlassen Lücken, und die Implementierung darf effiziente Grenzen um ungefähr die gewünschte Zahl vorhandener Nachrichten legen.

Ein letzter Bereich kann bei UID 1 enden, obwohl die älteste vorhandene Nachricht UID 302 trägt. Die 1 markiert eindeutig das Ende des Postfachs; sie behauptet keine Nachricht mit dieser UID.

Darum lässt sich die Anzahl nicht durch Subtraktion der Endpunkte bestimmen. Ebenso beweist eine Zahl innerhalb des Intervalls nicht, dass die Nachricht vorhanden war. Diese Aussage gehört zur Antwort des späteren FETCH, SEARCH oder STORE.

Ein prüfbares System speichert die UIDBATCHES-Antwort als Arbeitsaufteilung und das spätere Ergebnis als eigene Ebene. Werden beide zu „Seite“ verschmolzen, kann eine spätere Lücke nicht mehr auf Grenzflexibilität, Löschung oder Ausführung zurückgeführt werden.

UIDBATCHES ist ausdrücklich weder SEARCH noch UID SEARCH. SEARCHRES darf das Ergebnis nicht in $ speichern. PARTIAL stellt paginierte SEARCH- und FETCH-Vorgänge bereit; UIDBATCHES liefert dagegen vorab Bereiche für frei gewählte Folgearbeit.

Ein Bereich kann nur schrumpfen

Neue Nachrichten erhalten höhere UIDs und erscheinen nicht innerhalb eines bereits zurückgegebenen Bereichs. Seine Population wächst daher nicht. Durch EXPUNGE kann sie sinken.

Der Client kann EXPUNGE, VANISHED und EXISTS beobachten. Eine neue UIDBATCHES-Berechnung ist nach Auswahl eines anderen Postfachs, nach Löschung von mehr als einer halben Stapelgröße oder nach Ankunft von mehr als einer halben Stapelgröße neuer Nachrichten angemessen. Sonst darf der Client den Befehl nicht erneut senden.

Die Berechnung kann ressourcenintensiv sein. Server sollen Beschränkungen durchsetzen, damit fehlerhafte oder bösartige Clients keine Erschöpfung verursachen. Ein Zeitplan „alle 30 Sekunden aktualisieren“ ist ohne Zustandsbedingung kein Komfortmerkmal, sondern ein Risiko.

Der Nachweis einer Neuberechnung umfasst ursprüngliche Stapelgröße, seitdem gezählte Ereignisse, Schwelle und Auslöser. LIMIT, TOOFEW und TOOMANY müssen erhalten bleiben; blinde Wiederholung verschärft die Bedingung, die der Code meldet.

Postfach und UIDVALIDITY bilden die Identität eines UID-Kontexts. Ein gespeicherter Bereich unter einer anderen Gültigkeit ist nicht bloß veraltet. Seine Nummern beziehen sich nicht mehr verlässlich auf dasselbe Objekt.

Überlappung näht getrennte Berechnungen zusammen

Für große Postfächer kann der Client Stapelindizes abschnittsweise anfordern. Statt 1:100 und 101:200 empfiehlt die RFC als mögliche Kontrolle 1:100 und 100:200. Der wiederholte Randstapel macht Unterschiede zwischen zwei Berechnungen sichtbar.

Die Überlappung löst keine Inkonsistenz. Der Client muss entscheiden, ob er erneut abfragt, mehr überlappt, mit sichtbarer Unsicherheit fortfährt oder einen sensiblen Export stoppt. Ein positives Ergebnis ist auch kein vollständiger Snapshotnachweis.

Das Verfahren zeigt, warum ein Stapelindex kein dauerhaftes Seitentoken ist. Er beschreibt eine Position der damaligen Berechnung vom höchsten UID aus. Postfachänderungen können dieselbe Nummer später anders abgrenzen.

Ein Bereichsabruf darf höchstens 100.000 Nachrichten umfassen. Der Server muss mindestens diesen Umfang unterstützen, kann darüber aber TOOMANY melden. Bei einem sehr großen Postfach darf auch der Abruf aller Bereiche scheitern. MESSAGELIMIT sollte zusätzlich die gewählte Stapelgröße begrenzen.

Die Mindestgröße schützt die Architektur von UIDONLY. Winzige Stapel könnten feingranulare Positionsinformation ähnlich Sequenznummern rekonstruieren. Effizienz und Begrenzung unerwünschter Ableitungen beruhen hier auf derselben Regel.

Leere Antworten brauchen ihren Kontext

Ein leeres Postfach liefert eine UIDBATCHES-Antwort ohne Bereiche und danach OK. Dasselbe Format gilt, wenn ein nichtleeres Postfach die angeforderten Stapelindizes nicht besitzt.

Command-Tag, angeforderter Indexbereich und EXISTS-Zustand unterscheiden die Fälle. Eine Anzeige „0 Stapel“ kann sonst ein Ende außerhalb des Bereichs in eine Behauptung über ein leeres Postfach verwandeln.

Der Tag ist damit kein Protokolldetail, das nach Parsing verworfen werden darf. Er bindet die Antwort an die Frage. Zusammen mit Identität, Fähigkeiten und Antwortcode bildet er den Mindestkontext für eine automatisierte Entscheidung.

Daniel Eggert ist Kontext, nicht Betriebsnachweis

Zum 1. September 2026 führte Daniel Eggerts offizielles IETF-Datatracker-Profil RFC 10022 und RFC 9979. Swift.org beschrieb ihn 2022 im Beitrag zu SwiftNIO IMAP als Mitglied des Apple-Teams für Mail unter iOS und macOS und verlinkte seine öffentliche GitHub-Identität.

Der datierte Kontext beweist keine konkrete Produktimplementierung. Er zeigt weder, dass Eggert einen Produktionsserver steuert, noch dass ihm der IETF-Konsens gehört. Dokumentbearbeitung, Softwareimplementierung und Dienstbetrieb bleiben getrennt.

Die dokumentierte Leistung ist gerade diese begrenzte Koordination. Die RFC definiert gemeinsame Syntax und Schutzgrenzen. Server behalten ihre Berechnung, Clients ihre Planung und Betreiber ihre Abnahme. Heng Lus Minimum Initial Specification erklärt die Stärke dieses dünnen gemeinsamen Kerns; Running-Code Primacy verlangt danach die beobachtete Ausführung als Ergebnisbeweis.

Ein belastbarer Stapelbeleg

Zuerst Server, Kontogrenze, Postfach, UIDVALIDITY und Fähigkeiten erfassen. Dann Tag, Wunschgröße, optionale Indizes, Antwortcode und genaue Bereiche. EXISTS, EXPUNGE und VANISHED sowie Neuberechnungsgrund und Überlappungsvergleich anbinden.

Für jeden Bereich folgen Befehl, tatsächlich gefundene UIDs, fehlende Nachrichten, Bytes, Zeiten, Fehler, Wiederholung, lokaler Checkpoint und sichtbares Ergebnis. Inhalte und Zugangsdaten gehören nicht in ein öffentliches Audit. Begrenzte Kennungen, Zähler, Hashes und Zeitpunkte reichen für die Entscheidungskette.

So bleibt der Bereich eine effiziente Arbeitshilfe und wird nicht zur Seite umbenannt, bevor überhaupt feststeht, was erledigt wurde.

Quellen