Zusammenfassung

  • Die angeforderte Stapelgröße ist nach RFC 10022 eine harte Obergrenze, keine exakte Zusage. Ein Bereich kann weniger Nachrichten enthalten; selbst seine erste und letzte UID müssen keine vorhandenen Nachrichten bezeichnen.
  • OK UIDBATCHES completed beendet nur die Planberechnung. Belastbarer Abschluss verbindet Postfach und UIDVALIDITY, Planepoche, Änderungsereignisse, tatsächlich adressierte Nachrichten und die Endergebnisse aller nachfolgenden Befehle.

Ein sauberer Plan kann einen unsauberen Nenner erzeugen

Ein ausgewähltes Postfach meldet 6.823 Nachrichten. Der Client fordert mit UIDBATCHES 2000 geeignete Arbeitseinheiten an. Der Server liefert vier Bereiche in absteigender UID-Reihenfolge und quittiert den Befehl mit OK.

Für einen Scheduler ist das ein hervorragender Startpunkt: vier begrenzte Aufgaben, die neueste zuerst. Für einen Fortschrittsbalken ist es eine Falle. Wer den angeforderten Wert mit der Zahl verarbeiteter Nachrichten gleichsetzt, baut den Nenner aus einer Kapazitätsgrenze statt aus beobachteten Objekten.

Der Befehl hat keine Nachricht gelesen, markiert, kopiert oder verschoben. Er hat auch keinen Snapshot angelegt. Er hat Grenzen im UID-Raum berechnet, innerhalb derer spätere Befehle die dann vorhandenen Nachrichten auswählen können.

Der Unterschied ist mehr als technische Vorsicht. Planer, Server und Ausführungsdienst besitzen verschiedene Tatsachen. Sobald ein Dashboard sie zu „Stapel erfolgreich“ zusammenzieht, wird unklar, wessen Erfolg gemeint ist.

Die Oberkante ist normativ, die Unterkante beweglich

Fordert der Client 2.000 Nachrichten pro Stapel an, darf kein zurückgegebener Bereich mehr als 2.000 vorhandene Nachrichten enthalten. Diese Grenze darf der Server nicht überschreiten.

Eine genaue Untergrenze gibt es nicht. Der Server soll Bereiche möglichst nahe an der gewünschten Größe liefern und nach Möglichkeit 90 Prozent erreichen. Weniger ist zulässig, wenn die Implementierung dadurch wesentlich einfacher oder effizienter wird oder wenn sich das Postfach während der Berechnung ändert, insbesondere durch Expunges.

Ein Ergebnis mit 1.990, 1.977 und 2.000 Nachrichten kann also vertragsgemäß sein. Die 90-Prozent-Marke ist kein Dienstgütesiegel und kein absoluter Fehlerpunkt. Sie beschreibt eine angestrebte Nähe unter ausdrücklich genannten Bedingungen.

Der Client kann die Zahl als Ressourcenbudget verwenden. Der Server kann passende Grenzen wählen. Nur der spätere Befehl kann berichten, wie viele Nachrichten er tatsächlich antraf. Diese drei Werte gehören in drei getrennte Felder.

Auch die Mindestgröße von 500 ist bedeutend. Kleinere Anforderungen werden mit TOOFEW abgewiesen. Das schützt nicht nur Rechenkapazität. UIDONLY entfernt Nachrichtensequenznummern; Ein-Nachricht-Stapel könnten die verborgenen Positionen durch die Hintertür rekonstruieren. UIDBATCHES darf grob teilen, aber keine feinere Autorität zurückbringen.

Ein Randwert ist nicht zwingend bewohnt

UIDs steigen innerhalb einer Postfachgeneration, doch Löschungen hinterlassen Lücken. Außerdem kann eine Implementierung bequeme Grenzen wählen. Deshalb darf ein Bereich UIDs als Anfang oder Ende nennen, zu denen keine Nachricht existiert.

163886:99703 ist dann ein Auswahlzaun. Ein späteres UID FETCH bearbeitet die vorhandenen Nachrichten innerhalb des Zauns. Es erzeugt weder die Randobjekte noch füllt es die Zahlen dazwischen.

Beim ältesten Stapel kann der Server bis UID 1 reichen, obwohl die älteste vorhandene Nachricht UID 302 trägt. Die 1 sagt: Unterhalb dieses Bereichs gibt es keinen weiteren Stapel. Sie sagt nicht: Nachricht 1 ist vorhanden.

Diese Semantik muss die interne Darstellung überleben. Bereichsgrenzen sind keine bestätigten Nachrichten-IDs. Numerische Breite ist keine Anzahl. Ein Datenmodell, das die Grenzen als Objekte speichert, verschiebt eine nützliche Protokollaussage in eine falsche Realitätsschicht.

Die dauerhafte IMAP-Referenz bleibt an Postfachname, UIDVALIDITY und UID gebunden. Der UIDBATCHES-Plan erhält zusätzlich eine Epoche. Er ersetzt die Postfachgeneration nicht und beweist keinen Inhalt.

Neue Nachrichten wachsen oben, alte Bereiche verlieren Mitglieder

Neu eintreffende Nachrichten bekommen höhere UIDs. Sie tauchen nicht mitten in bereits zurückgegebenen Bereichen auf. Dadurch bleiben deren geometrische Grenzen stabil.

Ihre Population ist nicht stabil. EXPUNGE oder VANISHED entfernt Mitglieder. Ein Bereich, der bei der Planung ungefähr 2.000 Nachrichten repräsentierte, kann bei der Ausführung nur noch 1.984 finden. Der Bereich ist weiterhin nutzbar; die Behauptung einer unveränderten Menge ist es nicht.

Neue Nachrichten bilden einen Bereich über dem alten Maximum. Ein Export mit festem Stichtag kann sie der nächsten Epoche zuordnen. Eine laufende Synchronisation kann sofort einen neuen Stapel eröffnen. Das gemeinsame Protokoll braucht diese Geschäftsentscheidung nicht zu treffen.

Auch Neuberechnung ist begrenzt. Der Client darf UIDBATCHES nicht für kosmetische Aktualität wiederholen. Zulässig ist sie nach der Auswahl eines anderen Postfachs, nach mehr als einem halben Stapel gelöschter Nachrichten oder nach mehr als einem halben Stapel Neuzugängen. Der Server soll Verstöße verfolgen und kann LIMIT zurückgeben.

Diese Schwellen schützen Rechenarbeit. Sie definieren nicht die Beweislast einer Migration, Aufbewahrung oder rechtlichen Sperre. Technische Wiederverwendbarkeit und geschäftliche Gültigkeit haben unterschiedliche Uhren.

Leeres Ergebnis und Erfolg schließen sich nicht aus

Der Server muss eine ungetaggte UIDBATCHES-Antwort mit dem Korrelator des Befehls senden, auch wenn sie keine Bereiche enthält. Danach kann der getaggte Abschluss OK lauten.

Ein leeres Postfach führt zu diesem Muster. Ebenso eine nicht vorhandene Stapelfenster-Anfrage. Gibt es vier Stapel und der Client verlangt 6:8, lautet die korrekte Aussage: Für dieses Fenster gibt es keine Bereiche. Über den Gesamtbestand sagt sie nichts.

Ohne Account, ausgewähltes Postfach, UIDVALIDITY, Tag, Stapelgröße, Fenster und Zeitpunkt verliert eine leere Antwort ihren Gegenstand. Ein Log, das nur OK speichert, hat eine Antwort ohne Frage.

Auch Ablehnungen dürfen nicht zusammenfallen. TOOFEW verlangt gröbere Stapel. TOOMANY verlangt ein kleineres Fenster. LIMIT verlangt weniger Neuberechnungsdruck. Eine rückwärts geschriebene Fensterangabe wie 4:1 kann CLIENTBUG erzeugen. Jede Reaktion besitzt einen anderen Verantwortlichen.

Die präzisen Fehler sind keine unnötige Komplexität. Sie verhindern, dass jeder Anbieter eine private Deutungsschicht zwischen Protokoll und Betrieb setzt.

100.000 Nachrichten begrenzen die gemeinsame Pflicht

Ein ausdrücklich gewähltes Stapelfenster darf höchstens 100.000 Nachrichten überspannen. Der Server muss mindestens Bereiche über diese Population liefern können. Bei einem extrem großen Postfach darf eine unbeschränkte Anforderung aller Bereiche dennoch mit TOOMANY scheitern.

So bleibt die Macht auf beiden Seiten begrenzt. Der Server muss eine echte gemeinsame Mindestleistung bieten. Der Client kann aus einem registrierten Capability-Namen keinen Anspruch auf unbegrenzte globale Berechnung ableiten.

Für größere Postfächer dienen aufeinanderfolgende Fenster. Weil sich das Postfach zwischen Aufrufen ändern kann, schlägt RFC 10022 eine Überlappung vor: etwa 1:100 und anschließend 100:200. Der wiederholte Randstapel wird zum Zeugen. Weichen die beiden Darstellungen ab, ist Drift sichtbar.

Überlappung ist weder Sperre noch automatische Konfliktlösung. Sie entscheidet nicht, welche Sicht dem Auftrag entspricht, und verhindert keine spätere Löschung. Ihr Wert liegt in der Vergleichbarkeit. Wer den doppelten Bereich vor dem Vergleich entfernt, vernichtet die erkaufte Evidenz.

Zeit, beide Antworten, zwischenzeitliche Ereignisse und die getroffene Auflösung gehören zusammen in den Prüfpfad.

Benachbarte Fähigkeiten bleiben eigenständig

UIDONLY beseitigt Sequenznummern und kündigt Löschungen mit VANISHED an. UIDBATCHES gibt grobe UID-Bereiche zurück, ohne die entfernte Positionssicht wiederherzustellen.

PARTIAL paginiert tatsächliche SEARCH-Ergebnisse oder beschränkt ein tatsächliches UID FETCH. UIDBATCHES plant dagegen Grenzen für noch nicht ausgeführte Befehle. Eine Seite einer Abfrage ist kein Plan; ein Plan ist kein Abfrageergebnis.

SEARCHRES speichert ein Suchergebnis in $. RFC 10022 verbietet UIDBATCHES, diese Variable zu füllen, weil es weder SEARCH noch UID SEARCH ist. Ein ungefährer Bereich darf nicht stillschweigend zum bestätigten Nachrichtensatz aufsteigen.

QRESYNC und CONDSTORE liefern Änderungs- und VANISHED-Evidenz. Sie zeigen, wann die Realität vom Plan abweicht. Sie machen einen alten Plan nicht rückwirkend zu einem aktuellen Snapshot.

MESSAGELIMIT begrenzt, wie viele Nachrichten ein nachfolgender Befehl bearbeiten kann. Bei einem Limit von 1.000 sollte der Client keine UIDBATCHES-Größe von 2.000 wählen. Ein gültiger Plan über 2.000 verleiht einem FETCH keine Erlaubnis, seinen eigenen Vertrag zu überschreiten.

CAPABILITY ist damit eine Liste separater Verträge. Die ausführbare Einheit ist ihre Schnittmenge mit Verb und aktuellem Zustand.

Abschluss ist eine Mengenabstimmung

Statt eines Prozentwerts braucht der Betrieb getrennte Populationen:

Menge Evidenzfrage
P Welche Nachrichten gehören zur Auftragsregel und Postfachgeneration?
B Welche vorhandenen Nachrichten waren bei der Planung über die Bereiche erreichbar?
A Welche Nachrichten wurden durch nachfolgende Befehle tatsächlich adressiert?
C Welche erhielten ein akzeptiertes Endergebnis?
X Welche erwarteten Nachrichten wurden als gelöscht oder verschwunden beobachtet?
N Welche neuen Nachrichten liegen oberhalb des alten Maximums?
U Welche Ergebnisse sind unbekannt oder wiederholbar?

Ein stichtagsgebundener Export kann P = C ∪ X, ein leeres U und einen Grund für jedes X verlangen; N geht in die nächste Epoche. Eine laufende Synchronisation kann für N sofort einen neuen Stapel öffnen. Die lokale Leistungspflicht entscheidet.

Zählgleichheit reicht nicht. Eine erwartete Nachricht kann verschwinden, während eine neue erfolgreich verarbeitet wird. Der Gesamtwert bleibt gleich, die Mitglieder sind andere. Abstimmung braucht Postfach, UIDVALIDITY, UID und Auftragsepoche.

Das entspricht Heng Lus Idee eines minimalen gemeinsamen Kerns: Identität, Grenzen und lokal prüfbare Regeln bleiben gemeinsam; spätere Entscheidungen bleiben bei den Betreibern, die Wirkung und Risiko tragen.

Was der öffentliche Datensatz nicht beweist

RFC 10022 belegt keine Einführung durch einen benannten Mailanbieter, keine Produkteigenschaft und keine Produktionskonformität. Die 90-Prozent-Empfehlung ist keine veröffentlichte Leistungskennzahl. Die Szenarien sind aus dem Vertrag abgeleitete Betriebstests, keine zugeschriebenen Vorfälle.

Das IANA-Register legt die Bedeutung von UIDBATCHES, TOOFEW und TOOMANY fest. Es prüft keine laufende Software. CAPABILITY erklärt eine Möglichkeit, die Bereichsantwort dokumentiert Planungszustand, der spätere Befehl erzeugt Wirkung.

Running-Code-Primacy bedeutet nicht, den Standard zu verwerfen. Sie bedeutet, dass beobachtete Ergebnisse eine zu große Zusammenfassung korrigieren dürfen. Bleibt U übrig, kann ein grüner Plan den Auftrag nicht schließen.

Quellen