Zusammenfassung

  • RFC 9661 trennt das Hochladen des Inhalts, die Validierung, das Speichern des SieveScript-Objekts und die Aktivierung genau eines Skripts pro Konto.
  • Eine erfolgreiche SieveScript/set-Antwort mit isActive=true belegt den Objektzustand, nicht das Laden des Blobs in allen Zustell-Workern und nicht die Wirkung auf eine bestimmte Nachricht.
  • Ein belastbarer Nachweis verbindet Blob-Hash, Fähigkeiten, bedingten Zustand, Aktivierungsantwort, Rücklesen über beide Schnittstellen, Worker-Generation, Nachrichtenspur und Ergebnis.

Formal ist die Änderung abgeschlossen: Blob hochgeladen, Inhalt validiert, Objekt angelegt, neues Skript aktiviert, altes deaktiviert. Operativ bleibt dennoch eine Lücke. Die erste Prüfnachricht landet dort, wo die alte Regel sie abgelegt hätte.

Diese Beobachtungen widersprechen sich nur, wenn man Kontrollzustand und Ausführung für denselben Sachverhalt hält.

RFC 9661 definiert ein JMAP-Datenmodell für Sieve-Skripte. Ein SieveScript besitzt eine serverseitige id, einen eindeutigen Namen, eine blobId und das serverseitige Merkmal isActive. Pro Konto kann höchstens ein Skript aktiv sein. Der Standard präzisiert die Verwaltung; er normiert nicht, wie ein Dienst diesen Zustand in seine Zustellprozesse verteilt.

Vier abgeschlossene Schritte mit vier Reichweiten

Der Upload quittiert Bytebesitz. SieveScript/validate prüft den Inhalt, ohne ihn als Skript zu speichern. Syntax und geforderte Erweiterungen können stimmen, obwohl später ein Laufzeitfehler entsteht. RFC 5228 unterscheidet ausdrücklich zwischen früh erkennbaren Fehlern und Fehlern, die erst bei der Ausführung auftreten.

Die Objektänderung folgt den allgemeinen JMAP-Regeln aus RFC 8620. Mit ifInState lässt sich eine Änderung abbrechen, wenn sich der Bestand seit der letzten Beobachtung verändert hat. Das schützt vor konkurrierenden Überschreibungen. Der undurchsichtige Zustandswert bescheinigt aber nicht, welcher kompilierte Code in einem Worker liegt.

Die Aktivierung kann an den Erfolg aller gewünschten Änderungen gebunden werden. Die Antwort muss aktiviertes und deaktiviertes Objekt ausweisen. Damit ist die JMAP-Transaktion atomar. Replikationsverzug, verzögerte Invalidierung, Prozess-Caches oder gestaffelte Rollouts liegen außerhalb dieser Zusage.

Ein konsistenter Verwaltungsspeicher ist noch kein konsistenter Betrieb

JMAP und ManageSieve sollen auf denselben Skriptbestand zugreifen. Nach der Aktivierung sollten Name und Inhalt deshalb über beide Wege zurückgelesen werden. Eine Abweichung ist ein klarer Fehler.

Übereinstimmung sagt jedoch zunächst nur, dass beide Schnittstellen dieselbe Quelle sehen. Zustell-Worker können periodisch aktualisieren, Ereignisse verpassen, aus einer verzögerten Replik lesen oder kompilierte Regeln im Speicher halten. Der beweisfähige Datensatz braucht daher Konto, Skript-id, Blob-Hash, aktive Generation, Worker, Nachrichtenkennung und getroffene Aktion.

Auch die Aktion darf nicht aus Abwesenheit geraten werden. Eine nicht auffindbare Nachricht kann verworfen worden sein; sie kann ebenso vorher abgelehnt, verzögert, als Spam behandelt, fehlgeleitet oder wegen eines Speicherfehlers verloren sein. Ein synthetischer Test muss über den echten Eingang laufen, eine eindeutige Kennung tragen, die Annahme festhalten und Zustell-Worker sowie Ergebnis erfassen.

VacationResponse macht Schreibhoheit sichtbar

RFC 8621 definiert VacationResponse. Wird sie als Sieve-Skript umgesetzt, darf JMAP Sieve sie lesen und aktivieren, aber nicht über SieveScript/set inhaltlich ändern oder löschen. Die Schreibhoheit bleibt bei VacationResponse/set.

Das trennt Sichtbarkeit von Autorität. Zu jedem Blob gehört deshalb Herkunft: Sieve-Editor, Urlaubsgenerator, Wiederherstellung, ManageSieve oder Automatisierung. Ein inhaltlich korrektes Objekt kann aus dem falschen Berechtigungspfad stammen und damit einen Governance-Verstoß darstellen.

RFC 9404 erweitert die Blob-Verwaltung, RFC 9425 macht Quoten sichtbar, und das IANA-JMAP-Register koordiniert Namen und Fehler. Keine dieser Ebenen beobachtet die Ausführung einer einzelnen Nachricht.

Vom Ergebnis rückwärts prüfen

Für eine Prüfnachricht werden erwartete Aktion, ausführender Worker und geladene Generation festgehalten. Diese Generation wird auf aktive id und exakten Blob-Hash zurückgeführt. Danach folgen Aktivierungsantwort, alter und neuer JMAP-Zustand, ifInState, Validierung und damalige Fähigkeiten. Der Inhalt wird über JMAP und ManageSieve zurückgelesen.

Negativtests gehören dazu: Eine nicht vorhandene id darf das aktive Skript nicht ändern. Das Löschen des aktiven Skripts muss sieveIsActive liefern. Ein syntaktisch korrektes Testskript mit kontrolliertem Laufzeitfehler muss klassifizierbar sein. Ein von VacationResponse besessenes Skript muss die falsche Schreibschnittstelle abweisen.

Heng Lus Minimum Initial Specification setzt die richtige Grenze: gemeinsamer Vertrag klein und prüfbar, lokale Architektur beweispflichtig. Die Reality Layers verhindern, dass „aktiv“ die Bedeutung von „ausgeführt“ übernimmt. Running-Code Primacy legt die letzte Entscheidung an den Ort, an dem die Nachricht tatsächlich verändert wurde.

RFC 9661 schließt die Verwaltungstransaktion. Die Organisation muss die Ausführungskette schließen.

Quellen