Zusammenfassung

  • SEARCH RETURN (SAVE) schreibt in genau eine Suchergebnisvariable. Zwei SAVE-Befehle erzeugen keine getrennten Handles; der zweite empfangene Befehl überschreibt das erste Ergebnis.
  • Sichere Parallelisierung braucht deshalb einen Nachweis der Abhängigkeiten. Tags ordnen Antworten zu, benennen aber keine dauerhaften Ergebnismengen.

Der Client schickte zwei Suchen unmittelbar hintereinander. Die erste fand Nachrichten für Legal Hold, die zweite Kandidaten für eine Aufräumaktion. Beide trugen SAVE, beide erhielten OK. Danach arbeitete ein Befehl mit $. Im Audit standen drei erfolgreiche Tags, aber nicht, welche Entscheidung die letzte Aktion autorisiert hatte.

RFC 5182 lässt hier keinen Raum für zwei unsichtbare Variablen. Das Ergebnis der zweiten SAVE-Suche ersetzt stets das erste. Wer aus getrennten Tags getrennte Resultatobjekte ableitet, erfindet eine Abstraktion oberhalb des Protokolls, ohne sie selbst zu speichern.

Das Beispiel ist konstruiert und kein Bericht über einen Anbieter. Es zeigt, weshalb Performance-Optimierung und Entscheidungsidentität getrennt geführt werden müssen.

Ein Slot spart die Rückübertragung

Ohne SEARCHRES liefert der Server die Trefferliste, der Client parst und formatiert sie als message-set und schickt sie für FETCH, STORE, COPY, eine weitere SEARCH oder UID EXPUNGE zurück. Mit SAVE behält der Server das Ergebnis intern; $ ersetzt die Liste im Folgebefehl.

Ein Server zeigt die Unterstützung durch SEARCHRES an und muss ESEARCH implementieren. Fehlt eine andere Ergebnisoption, unterdrückt SAVE sogar die SEARCH-Antwort, die sonst die Liste enthielte. Das spart Bandbreite und Latenz und ermöglicht Pipelining.

Der gemeinsame Vertrag bleibt absichtlich klein. Der Slot besitzt keinen vom Client gewählten Namen, keine Version und keine Sammlung älterer Werte. Das Protokoll verlangt nicht, die Suchkriterien, den geschäftlichen Anlass oder den Verantwortlichen dauerhaft mitzuführen.

Eine Anwendung darf benannte Suchaufträge bauen. Dann muss sie selbst eine unveränderliche ID, Kriterien, Geltungsbereich, Ersteller, Zeitpunkt und erwartete Population speichern. Die Beschriftung „gespeicherte Suche“ macht aus $ allein noch keinen solchen Auftrag.

Reihenfolge ist ausführbare Autorität

SAVE gefolgt von einem $-Verbraucher erzeugt eine direkte Abhängigkeit. Der Server muss die empfangene Reihenfolge wahren. Intern darf er kompatible Arbeit parallelisieren oder Kriterien substituieren, solange die beobachtbare Semantik erhalten bleibt.

Ein SAVE kann mehrere Verbraucher versorgen. COPY und STORE dürfen nacheinander dasselbe Ergebnis verwenden. Ein zweites SAVE ändert dagegen den gemeinsamen Zustand. Künftige Verbraucher sehen dessen Ergebnis, nicht beide Populationen.

IMAP-Tags helfen, Antworten den Befehlen zuzuordnen. Sie sind keine Namen für Ergebnisvariablen. Auch die zeitliche Reihenfolge eintreffender Antworten ersetzt nicht die empfangene Befehlsfolge. Der lokale Nachweis muss jeden Verbraucher mit dem zu diesem Zeitpunkt gültigen Produzenten verbinden.

RFC 5267 macht den Unterschied sichtbar: CONTEXT kann Update-Kontexte durch Tags kennzeichnen, Änderungen liefern und Aktualisierungen abbrechen. SEARCHRES ist der letzte Ergebnisslot. Wer mehrere langlebige Kontexte benötigt, darf sie nicht bloß durch wiederholtes SAVE simulieren.

Auswahl und UIDVALIDITY begrenzen den Zustand

Nach erfolgreichem SELECT oder EXAMINE wird die Variable leer. Sendet der Server bei geöffneter Mailbox eine neue UIDVALIDITY, wird sie ebenfalls geleert. Sequenznummern gehören zur ausgewählten Mailbox; UIDs erhalten ihre fortdauernde Bedeutung nur zusammen mit Mailboxname und UIDVALIDITY.

EXPUNGE verändert den Slot ohne neue Suche. Das entfernte Mitglied scheidet aus. Speichert die Implementierung Sequenznummern, müssen die übrigen Nummern an die Verschiebung angepasst werden. Das Ergebnis ist damit kein unveränderlicher Snapshot.

Außerdem entscheidet der Verbraucher über den Nummernraum. Ein Resultat aus SEARCH darf in UID FETCH als UIDs aufgelöst werden; ein UID-SEARCH-Resultat kann in FETCH als Sequenznummern gelten. Die Schreibweise des Produzenten fixiert den späteren Typ nicht.

Für die Rekonstruktion braucht es Verbindung, ausgewählte Mailbox, UIDVALIDITY, Produzent, Kriterien und Optionen, Empfangsreihenfolge, EXPUNGE- und Auswahlereignisse sowie den genauen Verbraucher.

Fehler schließen den alten Zustand

Ein mit BAD beendetes SEARCH verändert die Variable nicht. Auch eine Suche ohne SAVE verändert sie weder bei Erfolg noch bei NO. Ein SAVE-SEARCH mit NO setzt sie dagegen auf leer.

Das verhindert einen gefährlichen Rückfall: Scheitert die Installation einer neuen Population, darf ein alter Satz nicht unbemerkt unter demselben Symbol weiterwirken. Das RFC-Beispiel mit einem nicht unterstützten Zeichensatz verlangt deshalb, die frühere Suche erneut auszuführen.

Auch Ressourcenknappheit kann SAVE verhindern. Der Server antwortet NO mit NOTSAVED und leert den Slot. Zusätzlicher Zustand kann Denial-of-Service-Druck verstärken; die Capability ist keine unbegrenzte Speicherzusage.

Ein generischer Retry, der danach sofort STORE $ sendet, verwendet nicht den vermeintlich sicheren alten Satz. Er arbeitet auf leerem Zustand. Der Workflow muss die Produktionskette neu aufbauen.

OK kann eine leere Wirkung bestätigen

Eine Suche kann null Treffer haben. SELECT, EXAMINE, UIDVALIDITY, ein SAVE-Fehler oder NOTSAVED können leeren. EXPUNGE kann das letzte Mitglied entfernen. Ein leeres $ bleibt ein gültiges, nicht passendes message-set.

Deshalb kann FETCH keine Datenantwort liefern und dennoch mit OK enden. COPY kann laut RFC erfolgreich sein und nichts kopieren. Das ist korrekte Befehlsausführung, aber kein Beweis für eine erfüllte Migration, Aufbewahrung oder Sicherheitsmaßnahme.

Vier Populationen müssen getrennt bleiben: vom Beschluss beabsichtigt, durch SEARCH berechnet, beim Verbrauch tatsächlich gespeichert und vom Verbraucher verändert. Das sichtbare Ergebnis bildet eine weitere Ebene. Eine grüne Statusquote misst nur den Transport dieser Befehle.

Ergebnisoptionen verändern den Inhalt

SAVE bedeutet nicht automatisch alle Treffer. SAVE MIN speichert nur das Minimum, SAVE MAX nur das Maximum, beide zusammen ein oder zwei Endpunkte. Mit ALL oder COUNT muss der Server dagegen sämtliche gefundenen Nachrichten im Slot halten.

RFC 9394 ergänzt PARTIAL: Ohne ALL enthält $ das angeforderte Fenster und gegebenenfalls MIN oder MAX. RFC 9738 verlangt bei MESSAGELIMIT die Speicherung des abgeschnittenen Ergebnisses; diese Vollständigkeitsgrenze besitzt bereits eine eigene BTW-Analyse. Hier zählt ein anderer Punkt: Schon bei fehlerfreier Ausführung bestimmen die Return-Optionen die Population.

Ein Auftragstitel wie „alte Nachrichten“ sagt nicht, ob alle, nur ein Endpunkt oder eine Seite gespeichert wurden. Die ausgeführte Syntax gehört in den Beleg.

Die Optimierung braucht eine lokale Beweisschicht

IANA registriert SEARCHRES; RFC 9051 übernimmt die Zustandsmaschine in IMAP4rev2. Das beweist eine gemeinsame Sprache, nicht Einsatz, korrekte Clientlogik, verfügbare Ressourcen oder einen Geschäftserfolg.

Vor irreversiblen Schritten sollte ein lokales Beweisobjekt entstehen: Entscheidungs-ID, Abfrage und Return-Optionen, Mailbox und UIDVALIDITY, Produzenten- und Verbrauchertags, Reihenfolge, Resets, EXPUNGE, Mengen und beobachtete Wirkung. Dann bleibt $ ein schneller Ausführungsweg.

Die Abschlussfrage lautet nicht, ob jeder Tag OK erhielt. Sie lautet, ob die Organisation erklären kann, warum jede betroffene Nachricht zum Auftrag gehörte und warum jede beabsichtigte, aber unberührte Nachricht fehlte. Ohne diese Antwort hat das Symbol die Entscheidung überlebt, die es nie gespeichert hat.

Quellen

  1. RFC 5182 — HTML
  2. RFC 5182 — Klartext
  3. Informationsseite des RFC Editor
  4. Dokumentseite im IETF Datatracker
  5. Historie im IETF Datatracker
  6. Referenzen im IETF Datatracker
  7. Errata zu RFC 5182
  8. RFC 9051 — IMAP4rev2
  9. Informationsseite zu RFC 9051
  10. RFC 4731 — ESEARCH
  11. RFC 4466 — zusammengeführte IMAP-ABNF
  12. RFC 4315 — UIDPLUS
  13. RFC 3501 — IMAP4rev1
  14. RFC 5267 — IMAP CONTEXT
  15. RFC 9738 — MESSAGELIMIT
  16. RFC 9394 — PARTIAL
  17. IANA-Register der IMAP-Capabilities
  18. Heng Lu — Realitätsebenen
  19. Heng Lu — minimale Anfangsspezifikation und freiwillige Übernahme
  20. Heng Lu — Vorrang des laufenden Codes