Zusammenfassung

  • Die LANGUAGE-Erweiterung von RFC 5255 verändert feste, menschenlesbare Servertexte und die übersetzte Darstellung von NAMESPACE-Präfixen. Sie verändert weder den kanonischen Namensraum noch die Identität eines Postfachs.
  • Die aktive COMPARATOR-Auswahl wirkt dagegen auf SEARCH, SORT und THREAD. Ein belastbarer Ergebnisbeleg muss deshalb Dekodierung, Zeichensatzkonvertierung, Vergleichsregel und einen möglichen Rückfall auf i;octet enthalten.

Zwei Schalter, zwei Wirklichkeiten

Internationalisierung klingt oft wie eine einzelne Komfortfunktion. In einem IMAP-Client erscheint sie vielleicht sogar in demselben Einstellungsfenster. RFC 5255 trennt jedoch zwei grundverschiedene Entscheidungen. LANGUAGE bestimmt, in welcher Sprache der Server feste Erklärungen ausgibt und wie bestimmte Namensraumpräfixe dargestellt werden. I18NLEVEL und COMPARATOR bestimmen, wie Zeichenketten in Abfragen miteinander verglichen werden.

Der erste Schalter beeinflusst die Oberfläche. Der zweite kann die Mitgliedschaft und Reihenfolge einer Ergebnisliste beeinflussen. Beide lassen den gespeicherten Bestand unberührt. Trotzdem wäre es falsch, sie in einem einzigen Feld namens „Locale“ zusammenzufassen. Dann könnte ein späterer Prüfer nicht mehr erkennen, ob sich nur eine Beschriftung änderte, ob eine andere Vergleichsregel griff oder ob ein Fallback eine scheinbar eindeutige Suche rettete.

Die operative Lehre liegt gerade in dieser Trennung. Eine lesbare Oberfläche ist kein Nachweis für kanonische Identität. Eine plausible Trefferliste ist kein unmittelbares Abbild des Speichers. Beides sind erzeugte Ansichten mit eigenen Eingaben, Regeln und Gültigkeitszeiträumen.

Ein übersetzter Präfix bleibt eine Darstellung

RFC 5255 begrenzt die Autorität von LANGUAGE sorgfältig. Die Erweiterung gilt für feste Servertexte sowie für übersetzte Darstellungen von NAMESPACE-Präfixen. Lokalisierte Aliase gemeinsamer Postfächer gehören ausdrücklich nicht zu diesem Mechanismus. Damit bleibt eine wichtige Grenze erhalten: Übersetzung erzeugt keine neue Adresse.

Ein NAMESPACE-Präfix kann zusammen mit einem TRANSLATION-Wert geliefert werden. Der Client soll daraus eine nutzergerechte Ansicht bilden und bei Bedarf zwischen der kanonischen Form und der übersetzten Darstellung zurückführen können. Wer nur die sichtbare Zeichenkette speichert, verliert diese Umkehrbarkeit. Nach einem Sprachwechsel könnte dasselbe Postfach wie ein zweites Objekt aussehen; ein Cache könnte einen vermeintlichen Umzug erkennen; eine Zugriffsübersicht könnte zwei Namen fälschlich als zwei Berechtigungsziele behandeln.

Deshalb gehört zu jeder dargestellten Bezeichnung eine Bindung an Server, kanonischen Präfix, ausgewählten Sprach-Tag und Sitzungsgeneration. Die Anzeige darf in Lesezeichen, Migrationen oder Automatisierung nicht stillschweigend zum Primärschlüssel werden. Das ist keine ästhetische Forderung, sondern Schutz vor einer Verwechslung von Präsentation und Identität.

Auch die Antworten auf LANGUAGE unterscheiden sich semantisch. Eine erfolgreiche Auswahl nennt genau eine Sprache und wird unmittelbar nach der Antwort wirksam. Eine Antwort mit mehreren Tags listet verfügbare Sprachen auf und nimmt keine Auswahl vor. Ein Fehler lässt die bisherige Sprache bestehen. Eine Benutzeroberfläche mag alle drei Fälle in einem Menü zeigen; ein Protokoll muss sie als Auswahl, Enumeration und fehlgeschlagenen Übergang auseinanderhalten.

Der besondere Wert default ist ebenfalls kein dauerhaftes Nutzerattribut. Er verlangt die vom Administrator bevorzugte Sprache, wobei die Antwort vom aktuell angemeldeten Nutzer abhängen kann. „Standard“ ist hier das Ergebnis einer Richtlinie, nicht die Eigenschaft des Postfachs und nicht zwingend eine stabile Aussage über eine Person.

Nach TLS oder SASL beginnt eine neue Sprachgeneration

LANGUAGE darf bereits vor der Authentisierung verwendet werden. Das hat einen guten Grund: Ein Mensch kann Hinweise zu einer abgelaufenen Berechtigung oder einem fehlgeschlagenen Sicherheitsvorgang nur dann sinnvoll nutzen, wenn er sie versteht. Genau deshalb liegt die erste Aushandlung aber auf einer noch ungeschützten Fläche.

Ein aktiver Angreifer könnte eine frühe LANGUAGE-Anfrage unterdrücken oder verändern. Spätere Fehlertexte würden dann möglicherweise in einer unerwarteten Sprache erscheinen und die Beurteilung eines Anmeldefehlers erschweren. RFC 5255 verlangt daher, LANGUAGE nach Einrichtung der TLS- oder SASL-Sicherheitsschicht erneut zu senden.

Diese Wiederholung ist mehr als eine erneute kosmetische Präferenz. Sie setzt den Geltungsbereich neu. Ein aussagekräftiger Sitzungsbeleg hält fest, ob die Wahl vor oder nach dem Sicherheitsübergang erfolgte, welche Schicht aktiv war, welche Anfrage gestellt wurde, welche Antwort kam und ab welchem Protokollpunkt die Wahl galt. Eine vor der Absicherung beobachtete Auswahl darf nicht ohne Herkunftsvermerk in die geschützte Phase fortgeschrieben werden.

Die erneute Wahl beglaubigt den übersetzten Text nicht und ersetzt keine maschinenlesbaren Statuscodes. Sie beweist weder Serveridentität noch gültige Zugangsdaten. Sie sorgt nur dafür, dass die Sprachentscheidung für spätere Vorgänge innerhalb der geschützten Generation getroffen wurde. Authentisierung, Protokollstatus und menschenlesbare Erklärung bleiben getrennte Beweisstücke.

Der Comparator ist ausführbare Abfragepolitik

RFC 5255 unterscheidet den Standard-Comparator von dem in der Sitzung aktiven Comparator. I18NLEVEL=1 verlangt i;unicode-casemap. I18NLEVEL=2 erlaubt zusätzlich, unterstützte Vergleichsregeln zu ermitteln und mit COMPARATOR eine aktive Regel zu wählen.

Eine solche Auswahl ist keine beiläufige Metadatenangabe. Sie verändert die Bedeutung der Abfrage. Der aktive Comparator wird bei den dafür definierten SEARCH-Feldern eingesetzt, darunter Betreff, Absender, Header und Nachrichtentext. Er wirkt auch auf einschlägige SORT-Schlüssel und auf Betreffvergleiche für THREAD. Dieselbe sichtbare Suchzeichenkette kann damit eine andere Treffermenge oder Reihenfolge ergeben, ohne dass eine einzige Nachricht geändert wurde.

Nach der Authentisierung muss der Standard-Comparator für die Verbindung stabil bleiben. Diese Stabilität gibt der impliziten Ausgangsregel eine nachvollziehbare Generation. Ein Client kann den aktiven Comparator weiterhin ausdrücklich wechseln. Der Beleg einer Abfrage muss daher beide Rollen nennen: die stabile Vorgabe und die tatsächlich wirksame Auswahl.

Außerdem muss die Regel die verlangte Operation beherrschen. SEARCH benötigt Teilzeichenkettenvergleich. SORT benötigt Ordnung, die wiederum Gleichheit voraussetzt. Fehlt dem aktiven Comparator eine erforderliche Operation, ist ein Fehler vorgeschrieben; der Server darf nicht still irgendeine ähnliche Semantik einsetzen. Eine bestätigte COMPARATOR-Auswahl garantiert folglich noch nicht, dass jeder nachfolgende Befehl ausführbar ist.

Das Ergebnis entsteht vor dem eigentlichen Vergleich

Bevor ein Comparator Text sieht, haben bereits andere Schritte stattgefunden. MIME-Transfer- und Headerkodierungen werden entfernt. Danach wird der dekodierte Text in den vom Comparator erwarteten Zeichensatz überführt. Erst dann wird verglichen.

Jede dieser Stufen kann scheitern oder eine Mehrdeutigkeit erzeugen. RFC 5255 lässt bestimmte Fehler bei der MIME-Dekodierung implementierungsabhängig. Eine Zeichensatzkonvertierung kann fehlschlagen. Eine Vergleichsregel kann Eingaben für ungültig erklären oder kein definiertes Ergebnis liefern. Darum beschreibt das Protokoll Ersatzwege, statt eine makellose Textwelt vorzutäuschen.

Bei Teilzeichenketten führt eine gescheiterte Konvertierung zum Vergleich mit i;octet; auch ein undefiniertes Comparator-Ergebnis kann diesen Rückfall auslösen. Bei einer Sortierung werden erfolgreich konvertierte, gültige Zeichenketten mit dem aktiven Comparator geordnet. Fehlerhafte oder ungültige Werte bilden eine zweite Gruppe, die unter i;octet geordnet und hinter der gültigen Gruppe angefügt wird.

Die resultierende Liste sieht trotzdem geschlossen und ordentlich aus. Ihr erster Teil kann aber nach sprachlicher Kollation und ihr zweiter Teil nach Bytefolge entstanden sein. Ebenso kann ein Suchtreffer nur deshalb erscheinen, weil der linguistische Pfad nicht verfügbar war und der Oktettvergleich anschlug. Sichtbarkeit allein verrät diese Herkunft nicht.

Ein reproduzierbarer Beleg sollte deshalb Nachrichtengeneration, betroffenes Feld, MIME-Dekodierung, deklarierten Zeichensatz, Konvertierungsergebnis, angeforderten und ausgewählten Comparator, Fallback-Entscheidung sowie die exakte Treffermenge oder Reihenfolge sichern. Ein bloßes „SEARCH erfolgreich“ ist dafür zu arm.

Gleicher Speicher bedeutet nicht gleiche Antwort

Zwei konforme Server können dieselben Nachrichten halten und dennoch unterschiedliche Zeichensätze, Comparatoren oder Fehlerpfade unterstützen. Auch ein Upgrade derselben Installation kann die Dekoder- oder Kollationsbibliothek ändern. Dann verschiebt sich eine Ergebnisliste, obwohl der Inhalt unverändert blieb.

Das ist keine Beliebigkeit des Standards. Es zeigt, dass die Abfragezeichenkette allein für Wiederholbarkeit nicht genügt. Benötigt werden Server- und Richtliniengeneration, beworbene Fähigkeiten, Sicherheitsgeneration der Sitzung, aktive Vergleichsregel, Dekodierpfad und Bestandsgeneration. Erst diese Verknüpfung kann unterscheiden, ob eine Nachricht fehlte oder ob der Vergleichspfad ihren Text nicht in derselben Weise verstand.

Das aktuelle IANA-Verzeichnis führt LANGUAGE, I18NLEVEL=1 und I18NLEVEL=2 weiterhin mit dem Verweis auf RFC 5255. Das belegt die Registrierung von Namen und Referenzen. Es beweist weder Verbreitung noch korrekte Umsetzung noch identische Bibliotheksversionen auf zwei produktiven Servern.

UTF-8 hebt die Zuständigkeitsgrenze nicht auf

RFC 5255 behauptet nicht, alle IMAP-Identifikatoren zu internationalisieren. Der Text weist ausdrücklich darauf hin, dass die Erweiterungen UTF-8 verwenden, jedoch nicht für Identifikatoren. RFC 6855 erweiterte später IMAP um UTF-8 für Nutzernamen, Mailadressen, Header und Postfachnamen; RFC 9051 ersetzte danach IMAP4rev1 als Basisspezifikation.

Die spätere Entwicklung macht die ältere Grenze deutlicher. Eine übersetzte Antwort, ein angezeigter Namensraumpräfix, ein UTF-8-Postfachname und ein für den Comparator normalisierter Suchterm können dieselbe Schrift verwenden und dennoch vier verschiedene Autoritätsbereiche darstellen. Gleiche Zeichen sind nicht automatisch gleiche Identität.

Ein Dienst sollte deshalb Präsentationssprache, kanonische Adressierung, Vergleichssemantik und Sicherheitszustand nicht über ein einziges Locale-Attribut steuern. Jede Entscheidung braucht einen eng definierten Zweck, einen Aussteller und eine Generation. Die Verknüpfung muss umkehrbar bleiben, damit ein späterer Prüfer rekonstruieren kann, was der Nutzer sah, ohne diese Ansicht zum kanonischen Datensatz zu erklären.

Lu Hengs Arbeit über laufenden Code und Wirklichkeitsebenen liefert dafür die Führungsregel. Die lokalisierte Anzeige ist in ihrer Darstellungsebene real. Das Postfach ist in der Namensraumebene real. Die Trefferliste ist für eine bestimmte Vergleichs- und Dekodiergeneration real. Der Sicherheitskanal begründet wiederum eine andere Geltung. Probleme entstehen, wenn eine Ebene ohne Beleg die andere zertifiziert.

Quellen