Zusammenfassung

  • RFC 5229 ergänzte set, String-Erweiterung und Match-Variablen, aber nur, wenn ein Skript die Fähigkeit variables ausdrücklich anforderte.
  • Dieser Speicher blieb eng begrenzt: Capture-Werte hingen vom tatsächlichen Kontrollfluss ab, galten nur für das laufende Skript und konnten an Implementierungsgrenzen abgeschnitten werden.

Ein Filter brauchte ein wenig Gedächtnis, keinen größeren Server

Im Januar 2008 hatte Sieve bereits eine klar umrissene Aufgabe: Nachrichten bei der endgültigen Zustellung filtern. Die Basisspezifikation beschrieb eine nützliche, bewusst eingeschränkte Sprache. Sie kannte keine Variablen oder Schleifen und konnte keine Shell-Befehle aufrufen. Das waren keine vergessenen Komfortfunktionen, die beliebig ergänzt werden sollten. Sie markierten die Grenze dessen, was ein nutzergeschriebener Filter vom Mailserver verlangen konnte.

RFC 5229 öffnete einen kleinen Teil dieser Grenze mit Bedacht. Ein Skript konnte require "variables" angeben, mit set eine benannte Zeichenfolge speichern, sie in eine andere Zeichenfolge einsetzen oder einen vom Skript erzeugten Text prüfen. Ein erfolgreicher Wildcard-Treffer konnte den gesamten Treffer unter ${0} und die erfassten Teilstücke unter ${1}, ${2} und weiteren Nummern bereitstellen. So ließ sich etwa ein Listenname aus einem Header in einen Postfachpfad übernehmen, statt denselben Text in mehreren Regeln zu wiederholen.

Das gab dem Filter jedoch kein dauerhaftes Gedächtnis. Die Spezifikation sagt, Variablen seien nur für das gerade laufende Skript sichtbar. Sie definiert weder einen Speicher für das gesamte Postfach noch ein Verzeichnis früherer Nachrichten oder einen Zustand, den mehrere Nutzer teilen. „Variable“ klingt nach einer großen Fähigkeit; der Standard beschreibt etwas Kleineres: einen Namen, der während dieses Skriptlaufs an Text gebunden ist.

Die ausdrückliche Anforderung gehörte zum Sicherheitsmodell

Vor dem Gebrauch musste das Skript die Fähigkeit anfordern. Ohne variables änderte sich die Bedeutung von Zeichenfolgen nicht stillschweigend. In einer erweiterbaren Sprache zählt das: Eine Fähigkeit besteht nicht nur aus einem neuen Vorgang, sondern auch aus einer ausdrücklichen Vereinbarung zwischen Skript und Interpreter, dass dieser Vorgang verfügbar ist.

Erweitert wurden Verweise, wenn die Ausführung die betreffende Anweisung erreichte, und zwar mit den dann aktuellen Werten. Die Ersetzung erfolgte genau einmal. Unbekannte Variablen ergaben eine leere Zeichenfolge; bei Namen wurde Groß- und Kleinschreibung nicht unterschieden. Das ist knapp, kann Fehler aber unsichtbar machen. Ein Tippfehler im Variablennamen kann Text verschwinden lassen, statt eine fehlende Angabe deutlich zu melden. Enthält der eingesetzte Wert einen weiteren Verweis der Form ${...}, wird dieser nicht in einer zweiten rekursiven Runde ausgewertet.

Die Erweiterung führte nur wenige Modifikatoren ein: ASCII-Groß- und Kleinschreibung, Änderung des ersten Buchstabens, Maskierung von Wildcards und Stringlänge. Hinzu kam ein string-Test. Arithmetik, Schleifen und beliebige Codeausführung gab es nicht. „Ausdrucksstärker“ bedeutete, einige Zeichenfolgen benennen und gezielt wiederverwenden zu können – nicht, unbegrenzt rechnen zu dürfen.

Ein Capture hängt davon ab, welcher Test tatsächlich lief

Mit Match-Variablen wird der Kontrollfluss Teil der Datenquelle. RFC 5229 verlangt die Auswertung von links nach rechts und das frühzeitige Beenden, sobald ein boolesches Ergebnis feststeht. Bei anyof (true, header :matches ...) wird der Header-Test beispielsweise übersprungen, weil true bereits genügt. Er erzeugt also keine Capture-Werte. Ein späterer erfolgreicher :matches-Test kann die vorherige Trefferliste ersetzen; ein fehlgeschlagener Test liefert keine neuen Teilstücke. Wer ${1} in einer komplexen Regel verwendet, muss wissen, welcher Test wirklich ausgeführt wurde.

Auch Match-Typen späterer Erweiterungen übernehmen Capture-Nebeneffekte nicht automatisch. RFC 5173, drei Monate nach RFC 5229 veröffentlicht, zieht eine aufschlussreiche Grenze: Ist variables aktiv, werden Variablenverweise in den Suchschlüsseln des body-Tests expandiert; Wildcard-Treffer dieses Tests dürfen dagegen keine Match-Variablen setzen. Die Standards erlauben also bestimmte Kombinationen und lehnen zugleich die Annahme ab, oberflächlich ähnliche Vorgänge müssten identisch wirken.

Die Mindestanforderungen machen die Begrenzung konkret. Eine Implementierung musste mindestens 128 Variablen, Namen mit mindestens 32 Zeichen, Werte mit mindestens 4.000 Zeichen sowie ${1} bis ${9} unterstützen. Überschritt ein Wert die Kapazität einer konkreten Implementierung, sollte das möglichst schon beim Kompilieren erkannt werden. Wurde es erst zur Laufzeit sichtbar, sollte der Wert abgeschnitten und dies nicht als Fehler behandelt werden. Der Sicherheitsteil rät deshalb davon ab, große sicherheitsrelevante Strukturen in Variablen abzulegen, und weist darauf hin, dass Absender den erfassten Text beliebig beeinflussen können.

Eine lange Entwurfsgeschichte belegt keine Verbreitung

Die Datatracker-Historie reicht bis zu einem individuellen Entwurf vom März 2003 zurück. Arbeitsgruppenversionen der Sieve-Gruppe erschienen ab Ende 2004, weitere Fassungen folgten 2005. Die IESG-Vorlage bezeichnet das Dokument als Arbeit der Sieve Mail Filtering Language Working Group. Die Genehmigung 2006 und die Veröffentlichung von RFC 5229 im Januar 2008 sind getrennte Stationen. Aus der Chronologie lässt sich weder der Grund für die lange Bearbeitungszeit noch die Zahl der späteren Implementierungen ableiten.

Heng Lus Notiz „Minimum Initial Specification“ bietet eine analytische Perspektive: require lässt eine kleine Basis bestehen und ermöglicht zugleich lokal aktivierte Zukunftsfunktionen. „Running-Code Primacy“ erinnert daran, dass eine standardisierte Fähigkeit nicht beweist, dass ein bestimmter Server sie implementiert oder freischaltet. Der Blick auf „Reality Layers“ trennt die Erklärung im Skript, den Zustand des Interpreters, das Verhalten des Servers und das letztliche Erlebnis im Postfach. Das sind spätere Deutungsrahmen, keine Belege für die Absichten der RFC-Autoren.

Der Filter konnte nun festhalten, was ein Treffer erfasst hatte, und einige benannte Zeichenfolgen weiterverwenden. Daraus folgt weder, dass er frühere Nachrichten speichert, noch dass er den Absender authentifiziert oder den endgültigen Zustellort bestätigt. Die historische Leistung von RFC 5229 war nicht, Sieve seiner Grenzen zu berauben, sondern eine ausdrücklich freigeschaltete Schnittstelle nützlicher zu machen.

Quellen