Summary

  • INPROGRESS steht in einer ungetaggten OK-Antwort. Das Signal kann einen Zähler enthalten, ein unbekanntes Arbeitsvolumen anzeigen oder lediglich die Verbindung am Leben halten.
  • Erst die getaggte Antwort OK, NO oder BAD beendet den Befehl. Befehlsausgabe und Folgen in nachgelagerten Systemen benötigen zusätzliche Nachweise.

Ein fast vollständiger Balken verändert Entscheidungen. Nutzer warten geduldiger, Betriebsteams verschieben ihre Aufmerksamkeit, Automatisierungen bereiten Folgeschritte vor. Aus einer Anzeige wird stillschweigend eine Zusage.

Genau diese Zusage enthält RFC 9585 nicht. Ein Server darf 999 verarbeitete Einheiten bei einem Ziel von 1.000 melden und später weitere Arbeit entdecken. Das Ziel kann wechseln, der Zähler zurückspringen und der Befehl trotzdem fehlschlagen. Gezählt wird, was die Implementierung als Arbeitseinheit gewählt hat — nicht zwingend das, was am Ende als Ergebnis zählt.

Die Erweiterung löst dennoch ein praktisches Problem. Suchen oder Kopieren in großen Postfächern kann so lange dauern, dass der Client einen laufenden Server nicht von einer abgebrochenen Verbindung unterscheiden kann. Freier Text wie „noch beschäftigt“ half Menschen, bot Programmen aber keine gemeinsame Semantik. RFC 9585 standardisierte im Mai 2024 deshalb Capability und Response Code INPROGRESS.

Zuerst kommt die Capability. Unterstützt ein Server die Erweiterung, muss er INPROGRESS in CAPABILITY nennen. Das belegt Unterstützung, aber keine Benachrichtigungspflicht für jeden Befehl. Endet eine Operation vor dem ersten vorgesehenen Intervall, kann sie ganz ohne Zwischenmeldung auskommen.

Entscheidet sich der Server für Meldungen, empfiehlt das RFC zehn bis fünfzehn Sekunden Abstand. Das Signal darf ausschließlich dazu dienen, einen Client vom Timeout abzuhalten. Die nackte Form enthält keine Details; Befehlstag, Fortschritt und Ziel werden sämtlich als NIL verstanden. Sie ist ein Lebenszeichen, keine Messung.

Die ausführliche Form liefert CMD-TAG, PROGRESS und GOAL. Das Tag soll den verursachenden Befehl identifizieren. Fortschritt zählt bearbeitete Einheiten. Das positive Ziel beschreibt die erwartete Gesamtzahl bei Abschluss. Wo Einheiten ungeeignet sind, kann der Server ein Prozentmodell mit Ziel 100 und Werten von 0 bis 99 verwenden.

Unwissen ist ausdrücklich darstellbar. Ohne bekannten Fortschritt müssen Fortschritt und Ziel NIL sein. Ist nur die Gesamtmenge unbekannt, bleibt das Ziel NIL. Ist das Tag nicht verfügbar oder enthält es ], wird auch CMD-TAG zu NIL. Bei einem einzigen laufenden Befehl bleibt das brauchbar. Bei mehreren Befehlen lässt sich die Meldung nicht sicher zuordnen.

Auch vollständige Werte sind keine feste Planung. Fortschritt sollte zwar monoton steigen und das Ziel möglichst konstant bleiben, doch Clients müssen Abweichungen verarbeiten. Die empfohlene Lesart lautet, dass ein früheres Ziel erreicht und anschließend zusätzliche lang laufende Arbeit entdeckt wurde. Sie schützt den Client vor einem Bruch; sie bestätigt weder den früheren Nenner noch eine Restlaufzeit.

Die entscheidende Grenze folgt aus IMAP4rev2. Ungetaggte Antworten beginnen mit * und transportieren Daten oder Status, ohne einen Befehl abzuschließen. Die Abschlussantwort trägt das ursprüngliche Befehlstag und lautet OK, NO oder BAD. Deshalb darf INPROGRESS nur in einem ungetaggten OK stehen und niemals in der getaggten Abschlussantwort.

Das Wort OK allein ist folglich wertlos. * OK [INPROGRESS ...] ist nicht dasselbe wie A001 OK. Das Sternchen hält den Vorgang offen, das passende Tag schließt ihn. Logsysteme und Benutzeroberflächen, die diese Syntax einebnen, vernichten die wichtigste Information.

Abschluss und Ergebnisinhalt bleiben ebenfalls getrennt. Im SEARCH-Beispiel melden Zwischenantworten verarbeitete Einheiten. Danach liefert eine ungetaggte SEARCH-Antwort die passenden Nachrichtenkennungen. Erst anschließend beendet das getaggte OK den Befehl. Das Ziel ist nicht die Trefferzahl, der Zähler nicht die Trefferliste und der Abschluss nicht deren Inhalt.

RFC 9585 untersagt ausdrücklich, die Werte für einen anderen Zweck als die Fortschrittsbewertung als maßgeblich zu behandeln. GOAL darf insbesondere nicht die reguläre SEARCH-Ausgabe ersetzen, um die Zahl der Nachrichten in einem Ordner zu bestimmen. Bei COPY beweist ein Zähler ebenso wenig, wie viele Objekte dauerhaft gespeichert, indiziert oder repliziert wurden.

Schweigen beweist keinen Stillstand. Bis zur ersten Meldung muss der Client Fortschritt null und Ziel unbekannt annehmen. Das ist ein Wissenszustand des Clients, kein Blick in den Server. Ein kurzer Befehl kann ohne Meldung erfolgreich enden; ein defekter Server kann umgekehrt Lebenszeichen senden, ohne eine brauchbare Wirkung zu erzielen.

Die Zahlen müssen wie nicht vertrauenswürdige Eingaben geprüft werden. Die Sicherheitsbetrachtung nennt Werte, die Rechenfehler auslösen können. Null- oder negative Ziele, extreme Größen und Fortschritt oberhalb des Ziels sind zu verwerfen. Zielwechsel und Rücksprünge sollten im Rohverlauf erhalten bleiben, statt für eine hübsche Kurve geglättet zu werden.

Im Betrieb braucht jeder Befehl einen Zustandsdatensatz: Verbindung, authentifizierte Sitzung, angekündigte Capability, Tag, Startzeit und konkurrierende Befehle. Jede Meldung wird roh angehängt, während die fachliche Befehlsausgabe separat bleibt. Erst die passende getaggte Antwort ändert „läuft“ in Erfolg, Fehlschlag oder Protokollfehler. Danach folgt, falls nötig, der Abgleich mit dem Zielsystem.

Denn ein getaggtes OK ist ein IMAP-Protokollbeleg. Es beweist nicht automatisch, dass ein Archiv indexiert, eine Replik konvergiert, eine Aufbewahrungspflicht erfüllt oder ein Kunde benachrichtigt wurde. Mit jedem weiteren System entsteht eine neue Behauptung, die einen eigenen Beleg verlangt.

RFC 9585 schafft Beobachtbarkeit, ohne sie mit Autorität zu verwechseln. Gute Implementierungen sollten dieselbe Disziplin bewahren.

Sources