Zusammenfassung

  • Sieve bevorzugt ein persönliches Postfach mit dem angeforderten Special-Use-Attribut gegenüber dem ausdrücklich benannten Standardpostfach. Fehlt ein passendes Ziel, gilt wieder das gewöhnliche namensbasierte Verhalten.
  • Scheitert die Zustellung in das ausgewählte Postfach aus einem Grund, der nicht dessen Existenz betrifft, darf der Interpreter anschließend nicht auf das Standardpostfach ausweichen.
  • Zuordnungen und Auswahlregeln gehören zum wirksamen Zustand eines Filters. Ein unverändertes Skript beweist weder einen unveränderten Ablageort noch ausreichende Kapazität für die nächste Nachricht.

Der Fehler sollte nicht den Ablageplan schreiben

Eine Organisation erwartet, dass bestimmte Nachrichten in ihrem vorgesehenen Archiv landen. Ob der Speicherdienst am Dienstagmorgen stärker ausgelastet ist als am Montagnachmittag, soll an diesem Plan nichts ändern.

Man stelle sich nun vor, dass das ausgewählte Archivpostfach seine Quote erreicht hat. Ein zweiter Ordner bietet noch Platz. Sein Name steht ebenfalls im Filter. Aus Sicht einer Betriebsanzeige wäre die naheliegende Lösung, die Nachricht dort abzulegen und die Verarbeitung als erfolgreich zu verbuchen.

Das ist ein konstruiertes Beispiel, kein Bericht über ein untersuchtes Produkt. Es macht eine Grenze sichtbar, die RFC 8579 ausdrücklich zieht. Wenn die Zustellung in das gewählte Special-Use-Postfach aus einem Grund scheitert, der nicht mit dessen Existenz zusammenhängt, darf Sieve anschließend keine Zustellung in das angegebene Standardpostfach versuchen.

Der Standardordner löst ein Auswahlproblem. Er ist nicht automatisch für jedes spätere Verarbeitungsproblem freigegeben.

Die Begründung ist praktisch: Vorübergehende oder wechselnde Zustellfehler sollen Nachrichten nicht unerwartet auf zwei Postfächer verteilen. Andernfalls würde die Störung selbst zum Sortierkriterium. Nachrichten aus störungsfreien Phasen wären an einem Ort, solche aus der Fehlerphase an einem anderen.

Verwendungszweck statt Namensraten

Mailprogramme können aus Ordnernamen nur begrenzt auf deren Funktion schließen. Nutzer benennen ihr Archiv unterschiedlich, arbeiten in verschiedenen Sprachen oder verlagern eine Funktion in eine andere Ordnerstruktur. Umgekehrt muss ein Ordner namens Archiv nicht der aktuell vorgesehene Archivspeicher sein.

Die IMAP-Erweiterung RFC 6154 führte dafür Attribute wie \Archive, \Drafts und \Junk ein. Sie kennzeichnen einen besonderen Verwendungszweck und erleichtern Clients die Konfiguration.

RFC 8579 macht diese Information für Sieve unmittelbar nutzbar. Das Argument :specialuse ergänzt die Ablageaktion um eine Suche nach dem gewünschten Attribut im persönlichen Namensraum des Nutzers. Ein passendes Postfach wird dem gewöhnlich per Name angegebenen Ziel vorgezogen.

Gibt es kein entsprechendes Postfach oder kennt die Implementierung das Attribut nicht, verhält sich die Aktion wie ohne dieses Zusatzargument. Dann gelten für den benannten Standardordner die normalen Regeln.

Damit kann ein Filter einer Funktion folgen, ohne jeden aktuellen Ordnernamen festzuschreiben. Die Bequemlichkeit hat jedoch eine Konsequenz: Änderungen der Funktionszuordnung können künftige Ablagen verändern, obwohl das Skript selbst unverändert bleibt.

Ein Vergleich von Konfigurationsdateien beantwortet deshalb nicht allein die Frage, warum eine Nachricht an einem anderen Ort gelandet ist. Die vom Skript gelesenen Zuordnungen sind Teil seines Verhaltens.

Nicht gefunden ist etwas anderes als nicht geschrieben

Drei Zustände verdienen getrennte Namen. Es gibt kein Postfach mit dem verlangten Attribut. Es gibt ein passendes Postfach, aber die Ablage scheitert etwa an der Quote. Oder mehrere Postfächer tragen das Attribut, sodass noch eine Auswahl nötig ist.

Im ersten Fall kann die namensbasierte Behandlung des Standardziels greifen. Im zweiten ist das Ziel bereits bestimmt; mangelnde Kapazität macht es nicht zu einem nicht existierenden Postfach. Im dritten müssen die Regeln für mehrere Kandidaten angewendet werden, statt die Suche als erfolglos zu behandeln.

Wer all dies unter „Ziel nicht verfügbar“ zusammenfasst, verliert die Voraussetzung für eine korrekte Reaktion. Ein belegter Ausweichversuch kann entweder zur erlaubten Standardauswahl gehören oder eine nachträgliche Umleitung nach einem Speicherfehler sein.

RFC 8579 schreibt für den verbleibenden Fehler nicht pauschal eine Warteschlange, Rücksendung oder Löschung vor. Es gilt das normale Fehlerverhalten der Ablageaktion. Die Erweiterung begrenzt einen konkreten Ausweichschritt; sie ersetzt keine vollständige Betriebsrichtlinie.

Diese Genauigkeit ist wichtig, weil eine missverstandene Beschränkung sonst zum Vorwand für Untätigkeit werden könnte. Dass der Filter nicht still in einen anderen Ordner schreiben darf, entbindet niemanden davon, die Störung zu bearbeiten und den tatsächlichen Ausgang zu klären.

Warum erfolgreiche Speicherung trotzdem ein Problem sein kann

Eine Nachricht irgendwo im Konto abzulegen, kann im Einzelfall besser erscheinen als eine Verzögerung. Nutzer können einen solchen Notbetrieb ausdrücklich wünschen. Der Einwand gegen das Verbot ist daher ernst zu nehmen.

Doch mit dem Ablageort ändern sich möglicherweise die Erwartungen anderer Beteiligter. Ein Client zeigt weiterhin das über das Attribut gefundene Archiv. Ein nachgelagerter Prozess beobachtet nur dieses Postfach. Ein Mensch bewertet fehlende Korrespondenz dort als Hinweis, dass sie nicht eingetroffen sei.

Die automatische Ausweichablage erfüllt dann die Erfolgsbedingung des schreibenden Dienstes, aber nicht unbedingt die des gesamten Dienstangebots. Eine globale Suche kann Nachrichten wiederfinden, ohne die ursprüngliche Arbeitsweise oder die ausgelösten Folgeprozesse wiederherzustellen.

Ein bewusst gewählter Ersatzbetrieb muss deshalb festlegen, wer den neuen Ort autorisiert, wie er sichtbar wird und wer die währenddessen entstandene Verteilung bereinigt. Der Standardname im Sieve-Argument beinhaltet diese zusätzlichen Entscheidungen nicht.

Das Verbot schützt die Konsistenz des Ablageplans gerade dadurch, dass es einen Fehler nicht durch eine stillschweigende Erweiterung des Auftrags verschwinden lässt.

Ein positiver Test ist keine Speicherzusage

Der Test specialuse_exists prüft mehr als die bloße Schreibweise eines Attributs, aber weniger als den erfolgreichen Abschluss der nächsten Zustellung.

Ohne ausdrücklich genanntes Postfach muss für jedes angeforderte Attribut mindestens ein passendes persönliches Postfach vorhanden sein, in das im Nutzerkontext des Skripts zugestellt werden darf. Unterschiedliche Attribute können dabei durch unterschiedliche Postfächer erfüllt werden. Wird ein Postfach genannt, muss genau dieses existieren, die Zustellung erlauben und sämtliche genannten Attribute besitzen.

Für die Bedeutung dieser Zustellmöglichkeit verweist RFC 8579 auf RFC 5490. Dort wird ausdrücklich davor gewarnt, einen erfolgreichen Existenztest mit einer garantierten späteren Ablage gleichzusetzen. Die Nachricht kann beispielsweise die Nutzerquote überschreiten.

Der Test reserviert keinen Speicherplatz. Er hält auch die übrigen Bedingungen bis zur Ausführung nicht fest. Existenz und Berechtigung sind Voraussetzungen, keine bereits erbrachte Speicherleistung.

Eine aussagekräftige Untersuchung braucht daher Nutzerkontext, beobachtete Zuordnungen, ausgewähltes Postfach und tatsächliches Ergebnis. Eine einzige grüne Vorprüfung lässt nicht erkennen, an welcher dieser Grenzen die Verarbeitung später scheiterte.

Mehrere Archive, eine lokale Auswahl

Special-Use bedeutet nicht zwingend Eindeutigkeit. Mehrere persönliche Postfächer können dasselbe Attribut tragen. Gehört das ausdrücklich benannte Standardpostfach zu dieser Menge, muss es gewählt werden.

Andernfalls ist die Wahl implementierungsabhängig. RFC 8579 empfiehlt eine konsistente Auswahl, solange die relevanten Zuordnungen unverändert bleiben. Wenn sich diese ändern, darf sich auch das gewählte Postfach ändern.

Die Vorschrift definiert damit keinen herstellerübergreifenden Sortieralgorithmus für mehrdeutige Zuordnungen. Zwei Systeme können denselben Funktionsbegriff korrekt verstehen und dennoch unterschiedliche Kandidaten wählen.

Bei einer Migration ist folglich nicht nur zu prüfen, ob Attribute übertragen wurden. Zu prüfen ist auch, welchen Ort die Filter unter dem neuen Zustand tatsächlich wählen. Portabilität des Vokabulars ist nicht automatisch Portabilität des Ergebnisses.

Auch der Inhalt des Funktionsbegriffs bleibt begrenzt. RFC 6154 überlässt die konkrete Bedeutung eines Archivpostfachs dem Server. Das Attribut belegt weder eine bestimmte Aufbewahrungsdauer noch Unveränderbarkeit oder eine konkrete rechtliche Archivpflicht. Solche Eigenschaften benötigen eine gesonderte Grundlage.

Die erste Zuordnung entsteht nicht von selbst

Die Attribute von RFC 6154 sind optional. Ein Server muss nicht jede Funktion anbieten. Das Anlegen eines Postfachs mit besonderem Verwendungszweck setzt die gesonderte optionale Fähigkeit CREATE-SPECIAL-USE voraus. Änderungen über Metadaten hängen ebenfalls von Unterstützung und Validierung durch den Server ab.

Ein Eintrag in den Errata zu RFC 6154 zeigt die Lücke zwischen Funktionsunterstützung und Einrichtung. Erratum 4422 beschreibt einen informellen Interoperabilitätstest vom 19. Juli 2015: Ein Server erwartete die anfängliche Zuordnung durch den Client, während ein Client diese Aufgabe beim Server sah.

Der Eintrag hat den Status Held for Document Update. Seine Verbesserungsvorschläge sind keine bereits geltenden neuen Pflichtvorgaben. Er belegt auch keine heutige Störung eines bestimmten Anbieters. Er dokumentiert, dass zwei grundsätzlich passende Implementierungen an einer nicht zugewiesenen Vorbereitungsaufgabe scheitern können.

Fehlen sowohl Special-Use- als auch Standardpostfach, gilt das normale Verhalten für ein nicht vorhandenes Ziel. Mit :create wird ausdrücklich verlangt, das benannte Postfach bei Bedarf anzulegen. Unterstützt der Server CREATE-SPECIAL-USE, empfiehlt RFC 8579, dem neuen Postfach das angeforderte Attribut zuzuweisen. Eine Empfehlung ist keine ausnahmslose Zusicherung aller Implementierungen.

Erfolgreiche Ablage nach Namen kann deshalb eine unvollständige Einrichtung verdecken. Die Nachrichten kommen an einem Ort an, doch die erwartete Auswahl über die Funktion war womöglich nie aktiv.

Der Suchraum entscheidet mit über die Kontrolle

Die Erweiterung beschränkt die attributbasierte Auswahl auf den persönlichen Namensraum. Eine Suche im gesamten Mailbestand würde nicht nur mehr Arbeit erzeugen. Sie könnte Nachrichten auch unerwartet oder böswillig in gemeinsam genutzte Postfächer lenken.

Wer eine Funktion an einem gemeinsam genutzten Ort vergeben kann, sollte dadurch nicht ohne Weiteres Einfluss auf die Ablage eines anderen Nutzers erhalten. Suchumfang und Befugnis zur Attributvergabe wirken zusammen.

Die Einschränkung besagt nicht, dass ein persönliches Postfach niemals geteilt werden kann. Sie unterwirft auch nicht automatisch jedes ausdrücklich benannte Standardziel derselben Suche. RFC 6154 warnt gesondert davor, dass bestimmte Funktionszuordnungen automatische Aktionen auslösen und private Nachrichten an einem geteilten Ort offenlegen können.

Die konkrete Grenze ist nützlicher als die größere, aber unbelegte Behauptung, der Begriff persönlich garantiere Vertraulichkeit.

Quellen statt Produktvermutungen

Für diese Analyse wurde kein Nutzerkonto, Anbieterbetrieb oder Vorfall untersucht. Das verifizierte technische Erratum 5877 zu RFC 8579 korrigiert einen Vergleichsoperator in einem späteren Beispiel, nicht die hier behandelte Trennung von Auswahl und Zustellfehler. Die Protokollbeispiele wurden nicht ausgeführt.

Lu Hengs Betrachtung des Prinzipal-Agent-Problems liefert eine passende Frage: Trägt der Entscheider die Kosten, die seine Entscheidung erzeugt? Ein Dienst kann seine eigene Erfolgsquote verbessern, während Nutzer und Support die Folgen verteilter Ablage tragen.

Seine Beschreibung der Aufgabe von BTW verlangt eine Darstellung der Struktur statt einer Kampagne. Hier lautet diese Struktur: Freie Kapazität ist eine Ressource. Das Recht, sie als neuen Ablageort zu verwenden, ist eine andere Sache.