Zusammenfassung

  • Ein Server darf den UPDATE-Wunsch einer Suche ablehnen und dennoch die anderen angeforderten Ergebnisse liefern. Der erfolgreiche Abschluss hebt diese Ablehnung nicht auf.
  • CONTEXT ist ein Hinweis auf mögliche Wiederverwendung, PARTIAL begrenzt die zurückgegebenen Ergebnisse und UPDATE betrifft Änderungen der gesamten Treffermenge.
  • Eine dauerhaft aktuelle Ansicht braucht einen angenommenen Betriebsauftrag. Das Produkt muss dessen Beginn, Grenzen und Ende von der ersten korrekten Antwort unterscheiden.

Wann ist eine Suche beendet? Für die Abrechnung einer einzelnen Anfrage scheint die Antwort einfach: Sobald der Server das verlangte Ergebnis geliefert und den Befehl abgeschlossen hat. Für einen Menschen, der eine geöffnete Postfachansicht als laufende Arbeitsliste verwendet, kann genau an diesem Punkt die eigentliche Nutzung beginnen.

Neue Nachrichten kommen hinzu. Andere werden als erledigt markiert oder endgültig entfernt. Eine gefilterte Liste soll diese Veränderungen abbilden, ohne dass ihr Nutzer die Suche ständig wiederholt. Aus einer abgeschlossenen Anfrage ist damit ein fortdauernder Auftrag geworden.

Dieser Auftrag kann jedoch abgelehnt worden sein, obwohl das erste Ergebnis korrekt vorliegt. Die Unterscheidung ist keine theoretische Spitzfindigkeit. RFC 5267, Contexts for IMAP4, vom Juli 2008 sieht sie ausdrücklich vor.

Ein Client kann bei einer Suche oder Sortierung UPDATE anfordern. Will der Server die laufenden Änderungen nicht bereitstellen, etwa wegen einer internen Grenze für Aktualisierungskontexte, meldet er dies während der Verarbeitung mit einer ungetaggten NO-Antwort und dem Antwortcode NOUPDATE. Dessen Argument nennt den Tag des betroffenen Suchbefehls. Andere angeforderte Rückgabeoptionen müssen trotzdem erfüllt werden. Der Befehl kann anschließend erfolgreich enden.

Eine Anwendung, die nur den letzten Erfolg speichert, kann somit eine korrekte Antwort anzeigen und zugleich eine unzutreffende Vorstellung von ihrem weiteren Betrieb vermitteln. Das ist ein mögliches Fehlermuster, kein hier nachgewiesener Vorfall bei einem Anbieter. Der Mechanismus lässt sich bereits aus dem Vertrag ablesen.

Der laufende Auftrag muss angenommen werden

Die erste Suche ermittelt passende Nachrichten. Ein aktualisierter Kontext muss darüber hinaus genügend Informationen behalten oder wiedergewinnen, um spätere Änderungen den Kriterien zuzuordnen. Er muss gegebenenfalls die Reihenfolge erhalten und Änderungen zum Client transportieren.

Wie viel Speicher oder Rechenzeit dies kostet, hängt von Kriterien und Implementierung ab. Eine zusätzliche sortierte Ansicht kann teurer sein als eine unsortierte Suche. Die Anzahl sichtbarer Zeilen ist dafür kein verlässlicher Maßstab.

RFC 5267 lässt Ressourcenbegrenzung zu, setzt aber eine Untergrenze: Ein Server muss mindestens einen Aktualisierungskontext je Client bereitstellen und sollte mehr anbieten. Daraus folgt weder ein unbegrenzter Anspruch auf gespeicherte Ansichten noch ein bestimmtes Speicherbudget oder eine zugesagte Aktualisierungslatenz.

Die Spezifikation unterscheidet ausdrücklich zwischen den höheren Implementierungskosten sortierter und den geringeren Kosten unsortierter Kontexte. Eine Ablehnung für SORT bedeutet deshalb nicht, dass auch SEARCH abgelehnt werden muss. Ein Client kann eine unsortierte Suche versuchen oder einen bestehenden Kontext aufgeben.

Eine solche Ausweichentscheidung darf die Bedeutung der Benutzeraufgabe nicht unbemerkt verändern. Wer Nachrichten in einer bestimmten Reihenfolge bearbeitet, hat nicht lediglich eine beliebige Treffermenge verlangt. Eine kostengünstigere Alternative kann sinnvoll sein. Sie muss als Alternative behandelt werden, nicht als Beweis, dass die ursprüngliche Leistung vollständig verfügbar war.

Das Ende des Befehls ist nicht das Ende seines Tags

NOUPDATE ist auf eine bestimmte neue Anfrage bezogen. Es erklärt nicht pauschal alle bereits angenommenen Aktualisierungen für beendet. Der Client muss die Ablehnung der richtigen Ansicht zuordnen und deren Zustand entsprechend darstellen.

Der Tag des ursprünglichen Befehls bleibt auch nach dessen erster Antwort nützlich. Spätere Ergebnisänderungen verweisen auf ihn. RFC 5267 verlangt eine BAD-Antwort, wenn ein weiterer UPDATE-Suchbefehl einen Tag wiederverwendet, den bereits ein noch laufender Aktualisierungskontext belegt.

Das ist eine begrenzte Identitätsregel. Ein Befehlstag wird dadurch nicht zum dauerhaften Geschäftskennzeichen, zur Berechtigung oder zum Postfachnamen. Er erhält lediglich eine längere Korrelationsaufgabe, als die Lebensdauer der ersten Anfrage vermuten lässt.

Für die Anwendung ist diese begrenzte Aufgabe entscheidend. Ohne sie lassen sich eine erfolgreiche erste Antwort, eine verweigerte Aktualisierung und später eintreffende Änderungen nicht zuverlässig derselben Ansicht zuordnen. Ein schneller Bildschirmaufbau kann diese Beziehung nicht ersetzen.

Auch das Ende der fortdauernden Arbeit ist definiert. Wird das Postfach nicht länger ausgewählt, enden seine Aktualisierungen. Mit CANCELUPDATE kann der Client außerdem die ursprünglichen Tags eines oder mehrerer Kontexte nennen, deren Updates aufhören sollen. Der Server darf zugehörige Ressourcen freigeben; eine spätere Suche bleibt möglich.

Damit ist jedoch keine Rekonstruktion der gesamten Zwischenzeit versprochen. Einen Kontext neu zu erstellen kann den gegenwärtigen Zustand wieder zugänglich machen, ohne jede während einer Unterbrechung verpasste Veränderung nachzuliefern.

Drei Optionen, drei unterschiedliche Reichweiten

CONTEXT klingt nach einem dauerhaft angelegten Objekt. Tatsächlich dient die Option als Hinweis, dass dieselben Suchkriterien voraussichtlich erneut verwendet werden. Der Server darf diesen Hinweis ignorieren oder für eine interne Optimierung nutzen. Es entsteht kein eingefrorener Schnappschuss.

UPDATE setzt einen vorherigen CONTEXT-Hinweis nicht voraus. Es verlangt Änderungen der gesamten Ergebnismenge. Diese kommen als Ergänzungen und Entfernungen, nicht notwendig als Wiederholung der ursprünglich angeforderten Kennzahlen.

Ein anfängliches COUNT wird deshalb nicht automatisch zu einer Folge neuer COUNT-Werte. Der Client kann seinen Zähler aus den Mitgliedschaftsänderungen fortschreiben. Dafür trägt er die Verantwortung, auch wenn auf dem Bildschirm nur eine Zahl sichtbar ist.

PARTIAL legt dagegen fest, welcher Ausschnitt der Ergebnisse zurückgegeben werden soll. Dieser Ausschnitt begrenzt nicht die Reichweite von UPDATE. Änderungen außerhalb der sichtbaren Seite können weiterhin gemeldet werden. Weniger Zeilen auf dem Bildschirm bedeuten somit nicht ohne Weiteres weniger fortdauernde Beobachtung.

Die Erweiterung RFC 9394 von 2023 hält diese Unabhängigkeit ausdrücklich fest. Sie ergänzt unter anderem vom Ende gezählte Ergebnispositionen und einen PARTIAL-Modifikator für UID FETCH. Die Fähigkeit PARTIAL ist nicht mit CONTEXT=SEARCH gleichzusetzen; Kombinationen setzen die jeweils passenden angekündigten Fähigkeiten voraus.

Ein weiteres Detail verhindert voreilige Schlüsse über den Umfang gespeicherten Zustands. In den beschriebenen Kombinationen kann SAVE zusammen mit PARTIAL die zurückgegebene Teilmenge speichern. Kommt COUNT hinzu, umfasst die gespeicherte Suchmenge alle Treffer. Die knappe Ausgabe beschreibt dann nicht den gesamten semantischen Umfang.

Das ist noch keine Messung des Arbeitsspeichers. Implementierungen können den Zustand unterschiedlich repräsentieren. Es ist aber ein belastbarer Grund, Netzwerkausgabe, gespeicherte Menge und Aktualisierungsarbeit getrennt zu betrachten.

Eine Änderungsliste verlangt geordnete Verarbeitung

Wurde UPDATE angenommen, darf der Client Ergänzungen und Entfernungen nicht beliebig umsortieren. ADDTO und REMOVEFROM müssen in Empfangsreihenfolge verarbeitet werden, auch innerhalb einer einzelnen Antwort. Der Server muss sie so erzeugen, dass die gewünschte Ergebnisreihenfolge erhalten bleibt.

Nachrichtensequenznummern bringen weitere Abhängigkeiten mit. Eine durch neu eingetroffene oder angehängte Nachrichten verursachte Ergänzung mit solchen Nummern muss nach EXISTS erfolgen. Eine durch endgültiges Entfernen verursachte Herausnahme aus dem Suchergebnis muss vor EXPUNGE erfolgen. Andernfalls kann sich die Bedeutung der Nummer ändern, bevor die betreffende Operation verarbeitet wird.

Diese Ordnung dient dem aktuellen Ergebnis. Sie macht aus dem Strom kein dauerhaftes, global geordnetes Archiv aller Geschäftsvorgänge. Eine Liste unbeantworteter Nachrichten dokumentiert nicht automatisch, wer wann welche Aufgabe übernommen hat oder welche Entscheidung während einer getrennten Verbindung getroffen wurde.

Die Änderungen sollten zeitnah übermittelt werden. Eine allgemeine feste Millisekundengrenze nennt RFC 5267 dafür nicht. Wer eine bestimmte Aktualitätsgrenze als Produkteigenschaft verspricht, braucht zusätzliche Betriebsmessungen und eine verständliche Behandlung von Phasen, in denen die Grenze nicht eingehalten wird.

Ein Cache ist kein Recht auf alte Antworten

Der Server darf Ergebnisse intern zwischenspeichern, mit oder ohne CONTEXT-Hinweis. Sein beobachtbares Verhalten muss jedoch dasselbe bleiben wie ohne Cache. Ändert sich das Postfach, muss der Cache passend aktualisiert oder verworfen werden.

Diese Regel lässt Optimierungen zu und hält zugleich deren Bedeutung begrenzt. Eine gespeicherte Ergebnismenge wird nicht allein durch ihre Speicherung zum zugesagten Snapshot. Das Verwerfen eines Caches ändert nicht den Anspruch an die nächste Suche.

Der Implementierungsanhang von RFC 5267 erläutert verschiedene Wege. Bei manchen unsortierten Kontexten können alte und neue Flags gegen die Kriterien geprüft werden. Für einen Ergebnisausschnitt kann eine Suche erneut laufen, frühe Treffer überspringen und nach genügend Ergebnissen enden. Sortierte Kontexte brauchen eher gespeicherte Ergebnisse. Nach dem endgültigen Entfernen einer Nachricht können ohne vorherigen Zustand Informationen fehlen, die für ihre frühere Zugehörigkeit nötig sind.

Diese Überlegungen erklären Kostenverschiebungen, nicht das Verhalten eines bestimmten Produkts. Ein kleinerer Cache kann mehr erneute Berechnung bedeuten. Ein größerer Cache kann Antworten beschleunigen und zugleich Pflegearbeit erzeugen. Keine einzelne Ressourcenzahl reicht aus, um den fortdauernden Auftrag vollständig zu beschreiben.

Erweiterungen sind keine austauschbaren Abschaltsignale

RFC 5465, The IMAP NOTIFY Extension, von 2009 erweitert die Steuerung unaufgeforderter Benachrichtigungen. Unterstützt der Server auch die jeweiligen Kontextfähigkeiten, lässt sich UPDATE um gewünschte FETCH-Attribute ergänzen, wenn neue Nachrichten in die Ergebnismenge aufgenommen werden.

NOTIFY besitzt eigene Mechanismen zur Begrenzung. Eine zu teure Anfrage kann zunächst mit einer getaggten NO-Antwort und NOTIFICATIONOVERFLOW abgelehnt werden. Später kann ein Server, der das verlangte Benachrichtigungsvolumen nicht liefern kann oder will, dies mit einer ungetaggten OK-Antwort samt NOTIFICATIONOVERFLOW mitteilen und sich wie nach NOTIFY NONE verhalten.

Das ist nicht derselbe Vorgang wie eine NOUPDATE-Ablehnung bei einer neuen Suche. Daraus wird hier auch keine pauschale Aussage abgeleitet, dass das Abschalten einer Benachrichtigungsart jeden anderweitig eingerichteten UPDATE-Kontext beendet.

Die Errata zu RFC 5465 zeigen zwei weitere Grenzen. Das verifizierte technische Erratum 2318 korrigiert ein Beispiel, das erst den Postfachstatus abfragte und danach Benachrichtigungen einrichtete. Die umgekehrte Reihenfolge schließt eine Lücke, in der Änderungen sonst unbemerkt bleiben könnten.

Zwei erfolgreich beendete Befehle beweisen also noch keinen lückenlosen Übergang von einer ersten Beobachtung zur fortgesetzten Meldung. Die Korrektur betrifft das Standardbeispiel; sie belegt keinen hier gemessenen Vorfall.

Das technische Erratum 4833 steht weiterhin auf Reported. Es beschreibt widersprüchliche Vorgaben zur Reihenfolge von FETCH und ESEARCH in zwei Abschnitten. Eine abschließend korrigierte Reihenfolge lässt sich daraus nicht behaupten. Die Aussage des Einreichers über eine eingesetzte Implementierung ist historisches Zeugnis, keine heutige Bestandsaufnahme. Verifizierte redaktionelle Errata korrigieren Tippfehler, Klammern und Abschnittsverweise, nicht diesen technischen Widerspruch.

Die Errata-Abfragen zu RFC 5267 und RFC 9394 ergaben zum Recherchezeitpunkt keine passenden Einträge. Das ist kein Fehlerfreiheitsnachweis für reale Implementierungen. Für diesen Bericht wurde weder ein Postfach bedient noch ein Serververhalten gemessen.

Die Verantwortung muss über die erste Antwort hinausreichen

Auch berechtigte Nutzer können durch zahlreiche Kontexte Ressourcen überlasten. Authentifizierung begrenzt nicht automatisch den laufenden Aufwand. RFC 5267 nennt deshalb Begrenzung, Protokollierung und Implementierungsstrategien als mögliche Gegenmaßnahmen.

Eine ausdrücklich abgelehnte Verpflichtung kann den übrigen Dienst schützen. Problematisch wird sie, wenn der Nutzer trotzdem eine uneingeschränkte Aktualitätszusage erhält. Infrastruktur und Anwendung können jeweils ihren Teil korrekt ausführen, während die gemeinsame Leistung falsch beschrieben wird.

Lu Hengs Text zum Agency-Problem bietet hierfür eine strukturelle Perspektive: Entscheidungsmacht und wirtschaftliche Folgen gehören zusammen. Die Zusage einer aktuellen Ansicht, die Annahme ihrer Betriebskosten und die Folgen einer veralteten Entscheidung liegen häufig an verschiedenen Stellen.

Sein Text zum Zweck von BTW fordert zudem, Strukturen zu beschreiben statt Gegner zu erfinden. Die Standards belegen weder Täuschung noch Unterdimensionierung bei einem Anbieter. Sie zeigen etwas Präziseres: Nach einer fertigen Suche kann ein Betriebsauftrag beginnen, dessen Annahme nicht im ersten Erfolg enthalten ist.