Zusammenfassung

  • RFC 5231 ergänzte geordnete :value-Vergleiche und :count-Tests zu den bestehenden Sieve-Tests address, envelope und header. Was :count misst, hängt davon ab, welcher Test die Nachricht untersucht.
  • Adresstests zählen Postfachelemente, Envelope-Tests Transportadressen und Header-Tests Feldvorkommen – nicht die darin genannten Adressen. envelope :count mit to zeigt absichtlich nur den aktuellen Nutzer.

„Wie viele Empfänger?“ ist nicht nur eine Frage

Ein Blick auf die To:-Zeile scheint für eine Empfängerzählung auszureichen. Zwei Postfachadressen, also zwei Empfänger. Doch ein Mailfilter arbeitet nicht mit dem optischen Eindruck einer Zeile. Er kann den Nachrichtenheader, den SMTP-Envelope und bereits geparste Adressstrukturen auswerten. Diese Oberflächen haben unterschiedliche Bedeutungen und Berechtigungsgrenzen.

Die im Januar 2008 veröffentlichte RFC 5231 führte relationale Vergleiche für die vorhandenen Sieve-Tests address, envelope und header ein. Ein Skript konnte nun nicht nur auf Gleichheit prüfen, sondern auch darauf, ob ein Wert größer, kleiner, gleich oder ungleich einem Vergleichswert ist. Die Erweiterung brachte zwei Match-Typen: :value vergleicht Werte anhand eines Comparators, der Sortierinformationen liefert; :count zählt ausgewählte Elemente und vergleicht anschließend die Zahl.

Die Operatoren lauten gt, ge, lt, le, eq und ne. Bei :value steht ein aus der Nachricht gewonnener Wert links, ein Wert aus der Schlüssel-Liste des Skripts rechts. Gibt es auf einer Seite mehrere Werte, genügt ein Wertepaar, das die Relation erfüllt. Die Sortierung ist keine allgemeingültige natürliche Sprachordnung, sondern richtet sich nach dem gewählten Comparator. Eine Implementierung muss i;ascii-numeric unterstützen, und zwar mindestens für vorzeichenlose 32-Bit-Zahlen. Negative Zahlen kann dieser Comparator nicht darstellen.

Besonders aufschlussreich ist :count. Angenommen, To: enthält zwei Postfachadressen und Cc: eine. Ein address :count über to und cc zählt drei Postfachelemente. Ein Gruppenname erhöht die Zahl nicht, die Postfächer innerhalb einer Gruppe schon. Ein header :count über to und cc zählt dagegen Headerfeld-Vorkommen. In einer gewöhnlichen RFC-2822-konformen Nachricht mit je einem To:- und Cc:-Feld ist das Ergebnis zwei, nicht drei Personen.

envelope :count misst wiederum etwas anderes: Adressen in den ausgewählten Teilen des Transport-Envelopes. Der Envelope-Teil to enthält immer genau einen Eintrag – die Adresse des Nutzers, dessen Sieve-Skript gerade läuft. Die Spezifikation verlangt diese Begrenzung, damit Nutzer nicht auf die Zustellung an andere Personen schließen können. from zählt null, wenn der SMTP-Befehl MAIL FROM leer ist, sonst eins. „Empfänger zählen“ kann also Postfächer im Header, für das Skript sichtbare Transportadressen oder Headerzeilen meinen. Der Testname allein legt das nicht fest.

Die Unterscheidung wirkt sich auch auf die Verknüpfung von Bedingungen aus. Ein gemeinsamer Adresstest über to und cc addiert beide Postfachzahlen. Soll die Regel „mindestens drei in To oder mindestens drei in Cc“ lauten, braucht es zwei Vergleiche in einem anyof. Ein gemeinsamer Zähler beantwortet stattdessen die Frage „mindestens drei über beide Felder hinweg?“. Das RFC-Beispiel zeigt: Zwei Adressen in To plus eine in Cc erfüllen zusammen den Wert drei, aber keine der getrennten Schwellen von jeweils drei.

RFC 5231 erfand relationale Sieve-Tests nicht neu. Bereits RFC 3431 von 2002 führte die Erweiterung und beide Match-Typen ein; RFC 5231 löste sie ab. Die Nachfolgefassung aktualisierte den Comparator-Verweis auf das Internet Application Protocol Collation Registry aus RFC 4790, korrigierte Beispiele, präzisierte die von COUNT gezählten Elemente nach RFC 2822 und entfernte eine eigene Pflicht zum Entfernen nachgestellter Leerzeichen, nachdem eine allgemeinere Regel in die Sieve-Grundnorm aufgenommen worden war. Bei der IANA ist relational als Erweiterung der RFC 5231 verzeichnet.

Doch die Erweiterung endet beim Test. Sie ändert weder das implizite KEEP noch Aktionen wie fileinto, redirect oder reject. Ein Prädikat kann den Zweig eines Skripts bestimmen, aber nicht belegen, was ein Server tatsächlich geparst hat, ob er den Zweig korrekt ausgeführt hat oder wohin die Nachricht schließlich zugestellt wurde. Der praktische Wert präziser Semantik hängt daher davon ab, Einheit, Comparator und Implementierungsebene auseinanderzuhalten.

Quellen