Zusammenfassung

  • RFC 5183 trennt standardisierte Environment-Items von herstellerspezifischen vnd.-Namen. Die Registrierung koordiniert das Vokabular, nicht die Semantik einer Migration.
  • Auch Standardwerte wie remote-host, location und phase bleiben begrenzte Laufzeitbeobachtungen. Insbesondere kann ein PTR-basierter Hostname aus einer nicht vertrauenswürdigen Quelle stammen.

Die alte Plattform stellte vnd.alpha.cluster=trusted-blue bereit. Ein Sieve-Zweig nutzte den Wert, um Nachrichten ohne zusätzliche Prüfung weiterzuleiten. Bei der Migration sollte der Name unverändert bleiben, damit kein Skript angepasst werden musste.

Die neue Plattform kannte das Item nicht. Ein Kompatibilitätsadapter erfand denselben String aus einer anderen Konfiguration. Der Test war wieder grün, doch Fehlerdomäne, Betreiber und Aktualisierungszeitpunkt hinter dem Wert hatten gewechselt.

Das Beispiel ist analytisch. Es zeigt den Unterschied zwischen syntaktischer Kontinuität und belegter Bedeutung. Ein registrierter Name verhindert Doppelbelegung; er macht aus einer lokalen Behauptung keine Internet-weite Wahrheit.

Das Item stammt aus der Laufzeit

Mit der Fähigkeit environment fragt ein Skript einen Namen ab und vergleicht den zurückgegebenen Wert mit Schlüsseln. Ohne weitere Argumente gelten :is und i;ascii-casemap. Nicht die aktuelle Nachricht liefert den Wert direkt, sondern die Betriebsumgebung des Interpreters.

Damit können Skripte auf Host, Domäne, Diensttyp, Lieferphase, Produkt oder entfernte Verbindung reagieren. Die Flexibilität ist real. Ihre Beweiskraft hängt jedoch davon ab, welcher Prozess den Wert wie erzeugt hat.

Die Standardliste enthält domain, host, location, name, phase, remote-host, remote-ip und version. location unterscheidet MTA, MDA, MUA und Message Store. phase unterscheidet vor, während und nach der finalen Zustellung. version ist ausdrücklich produktspezifisch und nur zusammen mit name sinnvoll.

Kein Feld identifiziert automatisch einen signierten Build, einen Mitarbeiter, eine Organisation, eine abgeschlossene Speichertransaktion oder eine sichtbare Mailbox. Solche Aussagen benötigen lokale Nachweise.

Unbekannt ist ein vorgesehener Zustand

Existiert ein Item nicht, muss der Test falsch werden, ohne das Skript mit einem Fehler zu beenden. Das ermöglicht Portabilität. Ein unbekannter Herstellername ist daher kein Protokollfehler, sondern ein Pfad, den die Politik entwerfen muss.

Mit :contains und leerem Schlüssel lässt sich feststellen, ob das Item bekannt ist. Das beweist keinen Inhalt. remote-host liefert eine leere Zeichenfolge, wenn der Name nicht ermittelt werden kann. RFC 5231 zählt eine leere Information als null und eine nicht leere als eins.

Für Migrationen ergeben sich vier Zustände: Item fehlt, Item existiert leer, Item hat einen unbestätigten Wert, Item ist für den konkreten Zweck verifiziert. Ein Adapter, der die ersten drei auf den alten privilegierten String abbildet, beseitigt genau die Unsicherheit, die das Protokoll sichtbar macht.

RFC 5463 ergänzt mit ihave eine Prüfung auf verfügbare Fähigkeiten. Fähigkeit, Item-Existenz, Wert und Vertrauen bleiben verschiedene Ebenen. Auch ManageSieve-Verwaltungszustand belegt nicht, welcher Laufzeitprozess einen Einzelentscheid traf.

Der PTR-Hinweis gilt auch für Standardnamen

Nicht nur Herstellerfelder brauchen Provenienz. RFC 5183 erlaubt unterschiedliche Verfahren zur Ermittlung von remote-host und warnt vor variierender Vertrauenswürdigkeit. Ein übliches Verfahren ist die PTR-Abfrage zur Client-IP.

Wer die Reverse-Zone kontrolliert, kann auf eine selbst gewählte Domäne verweisen. Daher ist *.example.com kein guter Test dafür, dass eine Nachricht nicht von außen kam. Der Wert kann formal korrekt sein, ohne die organisatorische Zugehörigkeit zu tragen, die das Skript daraus ableitet.

Eine belastbare Entscheidung speichert Peer-IP, beobachteten Hop, Reverse-Abfrage, Resolver, Antwort, Cache-Alter, Validierung und Forward-Confirmation-Policy. Selbst authentische DNS-Daten belegen zunächst eine Veröffentlichung unter einer DNS-Hierarchie, nicht die Geschäftsrolle des Senders.

remote-ip vermeidet die Namensableitung, kann aber einen Relay, Proxy, NAT-Ausgang oder gemeinsamen Submission-Dienst repräsentieren. Die lokale Vertrauenskarte muss sagen, welchen Principal der Hop vertreten darf.

Gleiches location bedeutet nicht gleiche Commit-Grenze

Bei einer Migration wirken Standardwerte sicherer. Doch auch location=MS bezeichnet nur die Dienstklasse Message Store. Es nennt weder Worker noch Replikat, Transaktion oder geladenen Skriptstand. phase=post lokalisiert die Verarbeitung relativ zur finalen Zustellung, bestätigt aber keine Indexierung oder Nutzeransicht.

RFC 6785 verwendet diese Werte für IMAP-Ereignisse und ergänzt imap.user, imap.email, imap.cause, imap.mailbox sowie imap.changedflags. Die Details demonstrieren die Grenzen.

imap.mailbox bleibt vom Skriptstart an fest und ändert sich nicht durch fileinto. Es beschreibt den Ausgangskontext, nicht das spätere Ziel. imap.changedflags nennt veränderte Flags, aber nicht, ob sie gesetzt oder entfernt wurden. Der aktuelle Zustand wird gesondert getestet.

Eine Migrationsmatrix muss deshalb nicht nur Wert zu Wert abbilden, sondern Beobachtungspunkt zu Beobachtungspunkt. Wo entsteht der Wert? Wann wird er stabil? Welche Ereignisse kann er nicht sehen? Welcher downstream receipt bestätigt die Wirkung?

IANA registriert Koordination, keine Zertifizierung

Standardisierte interoperable Items werden in Standards-Track- oder Experimental-RFCs definiert. Andere Items brauchen das Präfix vnd.. Der aktuelle IANA-Bestand zeigt die ursprünglichen Werte, spätere IMAP-Werte und einen Herstellerbereich.

Das ist eine schmale gemeinsame Spezifikation mit Raum für lokale Entscheidungen. Hersteller können neue Beobachtungen bereitstellen, ohne eine zentrale Stelle zur Architekturbehörde zu machen. Betreiber können entscheiden, welche Erweiterungen sie verstehen und übernehmen.

Die Registrierungsnummer prüft jedoch keine Implementierung und attestiert keine Genauigkeit. Sie sagt nicht, wie oft ein Wert aktualisiert wird, wer ihn kontrolliert oder ob er für Autorisierung geeignet ist. Ein Name kann kollisionsfrei und dennoch für den neuen Zweck falsch sein.

Freiwillige Übernahme verlangt daher eine echte Ablehnungsmöglichkeit. Erkennt die neue Plattform die Semantik nicht, muss der privilegierte Zweig geschlossen bleiben, bis ein überprüfbarer Adapter existiert. Ein erzwungener Fallback auf „trusted“ wäre keine Kompatibilität, sondern Mandatswäsche.

Der Migrationsvertrag gehört außerhalb des Strings

Für jedes relevante Item braucht die Organisation eine lokale Spezifikation: Datentyp, Erzeuger, Aktualisierungsereignis, Gültigkeitsdauer, Vertrauensquelle, erlaubte Entscheidungen und Verhalten bei Abwesenheit. Dazu kommen Skript-Hash, Interpreter-Build und Deployment-Generation.

Bei jeder Nachricht speichert der Receipt Itemname, Rohwert, Provenienz, location, phase, Vergleich und genommenen Zweig. Danach folgen Sieve-Aktion, Transport- oder Speicherantwort und beobachteter Endzustand.

Diese Struktur macht Änderungen sichtbar. Ein Anbieterwechsel kann den alten Namen aufgeben und trotzdem dieselbe nachweisbare Politik erfüllen. Umgekehrt darf ein identischer String nicht verbergen, dass sein Erzeuger und seine Autorität gewechselt haben.

Die Abschlussfrage lautet: Können beide Plattformen denselben überprüfbaren Sachverhalt liefern, oder haben sie nur dieselbe Zeichenfolge? RFC 5183 löst das Namensproblem. Die Bedeutung bleibt Aufgabe des laufenden Systems.

Quellen

  1. RFC 5183 — HTML
  2. RFC 5183 — Klartext
  3. Informationsseite des RFC Editor
  4. Dokumentseite im IETF Datatracker
  5. Historie im IETF Datatracker
  6. Referenzen im IETF Datatracker
  7. Errata zu RFC 5183
  8. RFC 5228 — Sieve-Basisspezifikation
  9. Informationsseite zu RFC 5228
  10. RFC 5231 — relationale Erweiterung
  11. RFC 5598 — Internet Mail Architecture
  12. RFC 6785 — IMAP-Ereignisse in Sieve
  13. Informationsseite zu RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — Sieve-ihave-Erweiterung
  16. IANA-Register der Sieve Extensions
  17. IANA-Register der Sieve Environment Items
  18. Heng Lu — Realitätsebenen
  19. Heng Lu — minimale Spezifikation und freiwillige Übernahme
  20. Heng Lu — Vorrang des laufenden Codes