Zusammenfassung

  • RFC 5232 lässt Sieve für die gerade bearbeitete Nachricht eine Flag-Menge bilden und prüfen und sie der durch keep oder fileinto zugestellten Kopie mitgeben.
  • Daraus wird keine allgemeine Bearbeitungsfunktion für den IMAP-Speicher: Dauerhaft nicht speicherbare Flags muss der Interpreter ignorieren, ohne allein deshalb einen Laufzeitfehler des Skripts auszulösen.

Die Markierung ging mit der Zustellung auf die Reise

Eine eingehende Nachricht wird geprüft, weitergeleitet und schließlich in einem Postfach abgelegt. Ein IMAP-Flag ist dagegen ein Zustand, der einer gespeicherten Nachricht zugeordnet ist. RFC 5232 verband Sieve im Januar 2008 mit diesem Zustand, hielt aber den Unterschied aufrecht: Eine Regel kann die Zustellung der gerade bearbeiteten Nachricht steuern; sie darf nicht damit gleichgesetzt werden, ein ganzes Postfach umzuschreiben.

Die Erweiterung imap4flags verlangt vier Aktionen beziehungsweise Tests: setflag, addflag, removeflag und hasflag. Zusätzlich erhält keep und fileinto das Argument :flags. Die ersten drei verändern eine Flag-Menge, der Test prüft Namen in dieser Menge. Das Zustellargument übergibt Flags an die gespeicherte Kopie der aktuellen Nachricht.

Diese Menge ist ein lokaler Zustand während eines Sieve-Laufs. Zu Beginn ist die interne Variable leer. setflag ersetzt ihren Inhalt, addflag fügt Flags hinzu und removeflag entfernt sie; hasflag kann die aktuelle Menge prüfen. Unterstützt der Interpreter auch die separate Variables-Erweiterung, kann ein Skript benannte Mengen führen. Ohne sie führt ein expliziter Variablenname zu einem Fehler. Flag-Namen werden ohne Beachtung der Groß- und Kleinschreibung verglichen; Skripte dürfen weder Reihenfolge noch Schreibweise oder die Behandlung von Duplikaten voraussetzen.

Entscheidend ist die Übergabe bei der Zustellung. Enthält keep oder fileinto ein :flags-Argument, gilt dessen Liste für die gespeicherte Kopie. Fehlt es, wird der aktuelle Inhalt der internen Variablen verwendet. Derselbe Standard gilt für implizites Keep — also den vorgesehenen Verbleib, wenn keine explizite Zustellaktion ihn ersetzt. Eine Regel kann in einem Zweig eine Markierung ergänzen und sie später mitgeben lassen; sie kann aber auch bei der Ablage eine andere Liste festlegen.

Der Anwendungsbereich bleibt die Nachricht, die der aktuelle Sieve-Lauf bearbeitet. RFC 5232 erlaubt es nicht, eine andere, bereits im Postfach liegende Nachricht auszuwählen und deren Flags zu ändern. Auch eine separate Nachricht, die als Nebenwirkung einer anderen Aktion entsteht, bleibt außerhalb dieses Umfangs. Das ist ein Zustell-Haken, keine allgemeine Schnittstelle zum Verändern des IMAP-Speichers.

Das Zielpostfach setzt eine weitere Grenze. :flags beschreibt den gewünschten Zustand der zugestellten Kopie, garantiert aber keine dauerhafte Speicherung jedes Flags in jedem Postfach. Der Interpreter muss Flags ignorieren, die sich nicht permanent speichern lassen, und darf daraus nicht allein einen Sieve-Laufzeitfehler machen. Laut RFC ist fileinto :flags "\\Deleted" einem fileinto ohne dieses Flag gleichgestellt, falls das Postfach es nicht speichern kann. Im IMAP markiert \\Deleted eine Nachricht für ein späteres Expunge; es bescheinigt keine physische Löschung.

Die Aussage „die Regel hat das Flag gesetzt“ kann deshalb mehrere Stufen verdecken: Wurde ein Zweig genommen? Hat der Interpreter eine Liste gebildet? Hat die Zustellaktion sie angefordert? Welche Flags hat das Postfach dauerhaft übernommen? Was zeigte ein Client anschließend an? Das sind getrennte Befunde. RFC 5232 legt außerdem nicht fest, ob ein Interpreter als IMAP-Client arbeitet oder direkt auf den Nachrichtenspeicher zugreift. Die Architektur kann variieren, der Gegenstand der Erweiterung bleibt dennoch die aktuelle Nachricht.

Für zusammengeführte Zustellaktionen gibt es eine Prioritätsregel: Wenn die Duplikaterkennung mehrere keep- oder fileinto-Aktionen zu einer Nachricht zusammenfasst, muss die zuletzt angegebene Flag-Liste gelten. Die verbleibende Kopie muss also nicht alle Absichten früherer Zweige vereinen. Wer den Endzustand ermitteln will, muss Aktionsreihenfolge und Zustellmechanismus verfolgen, statt alle addflag-Aufrufe zusammenzuzählen.

RFC 5232 steht neben der Sieve-Grundsprache RFC 5228, der Variablen-Erweiterung RFC 5229 und den relationalen Tests aus RFC 5231. Diese Nachbarstandards beschreiben Parsing und Werte, verschieben aber nicht die Zustellgrenze. RFC 9051 unterscheidet später dauerhaft speicherbare von sitzungsgebundenen Flags und stuft \\Recent als veraltet ein. Eine angeforderte Markierung ist also nicht automatisch ein dauerhafter Zustand. Der Standard dokumentiert ein Protokollversprechen, nicht die Implementierung durch einen bestimmten Server, die erfolgreiche Zustellung einer Nachricht oder ihre Anzeige in einem Client.

Quellen