Zusammenfassung

  • RFC 3028 machte Mailfilterung zu einer begrenzten Aktionssprache und führte das implizite Behalten als Schutz ein, wenn keine zustellungswirksame Aktion ausgeführt wurde.
  • keep, fileinto, redirect, discard und Ablehnung bezeichneten Entscheidungen des Interpreters; sie waren kein Nachweis für dauerhafte Ablage, entfernte Annahme oder endgültige Zustellung.

Serverseitige Filterung verband im Jahr 2001 einen alltäglichen Wunsch mit einem heiklen Kontrollproblem. Nutzer wollten Nachrichten vor dem Lesen sortieren, weiterleiten oder zurückweisen. Betreiber konnten ihnen dafür aber keine allgemeine Programmiersprache auf dem Zustellserver öffnen. Schleifen, externe Programme und unbeschränkter Ressourcenverbrauch hätten eine persönliche Regel in ein Risiko für die gemeinsame Infrastruktur verwandelt.

Sieve löste das Problem durch Weglassen. RFC 3028 kannte keine Schleifen, Funktionen oder Shell-Aufrufe. Tests durften keine Nebenwirkungen haben. Kontrollbefehle wählten Blöcke, Aktionsbefehle veränderten die Behandlung der Nachricht. Die Begrenzung war Teil des Sicherheitsmodells und machte die möglichen Folgen prüfbar.

Eine ausgelassene Regel durfte keine Nachricht vernichten

Filter übersehen Fälle. Absender wechseln Adressen, Listen ändern Header, Bedingungen werden falsch formuliert. Würde das Durchfallen durch alle Zweige eine Nachricht beseitigen, würde jede Lücke zum Datenverlust. Deshalb definierte RFC 3028 ein implizites Behalten: Solange keine Aktion es aufhob, galt die normale Zustellung des Systems, gewöhnlich in das Hauptpostfach.

Das war keine zusätzliche Kopie nach jeder Regel. keep, fileinto, redirect und discard hoben das implizite Behalten auf. Der Interpreter berechnete ein zusammenhängendes Aktionsverhältnis. Spätere Erweiterungen mit bloßen Nebeneffekten mussten erklären, ob die Standardsicherung bestehen blieb.

Gerade discard zeigt die Präzision. Der Befehl hob das implizite Behalten lautlos auf, löschte aber nicht jede andere kompatible Aktion. fileinto zusammen mit discard behielt die Ablage im gewählten Ordner und verhinderte nur eine weitere Standardkopie. Das alltägliche Wort klang endgültig; die normative Wirkung war eng umrissen.

Aktionsnamen waren keine Ergebnisquittungen

keep verlangte die gewöhnliche Standardbehandlung der Implementierung. Das Skript musste weder den physischen Namen des Hauptpostfachs noch dessen Speichertechnik kennen. Diese Abstraktion schuf Portabilität, bedeutete aber auch: Eine erfolgreich gewählte Aktion bewies weder Speicherplatz noch Berechtigung oder Commit.

fileinto benannte einen Ordner. RFC 3028 empfahl die Unterstützung, erkannte aber Umgebungen an, in denen sie unmöglich war. Der Ordnername war ein Auftrag an den Zustellagenten, kein Beleg für Existenz und dauerhafte Speicherung.

redirect ersetzte den Envelope-Empfänger und startete eine MTA-artige Weiterleitung. Danach entschied ein entfernter Server über die Annahme. Auch Schleifenerkennung blieb Aufgabe der Implementierung. Der lokale Beschluss eröffnete einen neuen Transportabschnitt; er schloss ihn nicht ab.

discard musste still bleiben und durfte keine Nichtzustellungsnachricht erzeugen. Für den Absender fehlte damit bewusst eine sichtbare Quittung. Falls Nachvollziehbarkeit erforderlich war, musste der Betreiber eine angemessene, inhaltsschonende Ausführungsspur führen.

Aktionskombinationen regelten Nebenwirkungen

Mehrere Aktionen für dieselbe Nachricht konnten sich ergänzen oder widersprechen. RFC 3028 verpflichtete Erweiterungen, ihre Wechselwirkung mit dem Kern zu beschreiben. Standorte durften Anzahl und Kombination begrenzen. Selbst eine doppelte Anweisung zur Ablage in dasselbe Postfach sollte nicht zu doppelter Zustellung führen.

Damit wurden Verstärkung und Täuschung begrenzt. Viele Weiterleitungen konnten eine Mailbombe erzeugen. Ablehnung und Zustellung zugleich konnten dem Absender einen Fehlschlag melden, obwohl eine Kopie erhalten blieb. Unabhängige Abarbeitung jedes Verbs hätte die Gesamtentscheidung zerstört.

RFC 5228 ersetzte RFC 3028, behielt aber implizites Behalten und die Grundaktionen bei und präzisierte Fehler sowie Erweiterungsregeln. RFC 9122 führte später ein IANA-Register für Sieve-Aktionen ein. Es verzeichnet unter anderem Wechselwirkungen und die Aufhebung des impliziten Behaltens. Das Register dokumentiert Verträge, keine Einzelerfolge.

Die Ablehnung legte den falschen Zeitpunkt offen

Die ursprüngliche reject-Erweiterung von RFC 3028 verwarf eine Nachricht und sandte dem Envelope-Absender eine Dispositionsmeldung. Das empfangende System konnte die Nachricht jedoch bereits angenommen haben. Bei gefälschten Absendern traf die Rückmeldung Unbeteiligte und erzeugte Backscatter.

RFC 5429 ergänzte ereject, das nach Möglichkeit während SMTP oder LMTP ablehnt. Es stellte außerdem klar, dass Ablehnung das implizite Behalten aufhebt, nur einmal erfolgen darf und gewöhnlich nicht mit Zustellaktionen kombiniert werden soll. Ein System darf dem Absender nicht Nichtzustellung melden und zugleich die Nachricht ablegen oder weiterleiten.

„Abgelehnt“ verbarg somit verschiedene Tatsachen: Das Skript wählte die Aktion; die ausführende Komponente konnte oder konnte nicht auf Protokollebene ablehnen; der Absender sah eine sofortige Antwort, eine spätere Meldung oder nichts. Ohne Ebene und Evidenz blieb der Status unvollständig.

ManageSieve nach RFC 5804 standardisierte einen anderen Kontrollbereich: Skripte hochladen, prüfen, auflisten und aktivieren. Ein aktives Skript ist noch keine Auswertung einer bestimmten Nachricht; eine gewählte Aktion noch kein beobachtetes Ergebnis. Verwaltung, Entscheidung und Wirkung brauchen getrennte Nachweise.

Quellen

Lu Heng hat RFC 3028, RFC 5228 und RFC 5429 weder verfasst noch gebilligt. Seine Essays dienen hier als offengelegte analytische Perspektiven.