Zusammenfassung

  • RFC 9755 trennt die Serverankündigung von der ausdrücklichen Aktivierung durch einen authentisierten Client; keine davon beweist allein Identität, Mailstore, Index und Darstellung.
  • Abnahme endet mit einer kontrollierten Nachricht, die der vorgesehene Nutzer auflisten, suchen, abrufen, verstehen und verwenden kann.

Ein Test kann an der falschen Stelle erfolgreich sein. Eine Nachricht mit internationalisierten Kopfzeilen erhält beim APPEND ein OK. Der Empfänger findet sie dennoch nicht nach Absender, kann eine eingebettete Nachricht nicht öffnen oder sieht sie in einem unterstützten Client gar nicht. Das OK war korrekt. Nur die daraus gezogene Aussage war zu groß.

RFC 9755 erschien im März 2025 als Standards-Track-Dokument und ersetzt RFC 6855 für IMAP4rev1; IMAP4rev2 enthält bereits ähnliche Fähigkeiten. UTF8=ACCEPT kündigt internationalisierte Nachrichten und UTF-8-Mailboxnamen an. UTF8=ONLY umfasst dies und verwirft modified UTF-7.

Ankündigung ist keine Aktivierung

Der Client authentisiert sich und sendet ENABLE UTF8=ACCEPT. Auch bei UTF8=ONLY bleibt dieser Befehl richtig. Nach RFC 5161 dokumentiert ENABLED die tatsächlich aktivierten Erweiterungen; CAPABILITY ändert sich nicht und ist kein Sitzungsbeleg.

Die Abnahme benötigt Serverbuild und Protokollmodus sowie Befehl und Antwort jedes realen Clients. Ein losgelöster Konfigurationsbildschirm beweist beides nicht.

Syntax provisioniert kein Konto

LOGIN wird nicht für UTF-8-Zugangsdaten erweitert; dafür ist AUTHENTICATE nötig. RFC 9755 stellt zugleich klar, dass syntaktischer Transport nicht garantiert, dass das Identitätssystem dieses Konto zulässt. Separat zu prüfen sind autoritative Provisionierung, produktive Authentisierung, Zuordnung zur richtigen Mailbox und Berechtigung auf jedem Zugriffsweg.

APPEND beginnt den Speichernachweis

Nach ENABLE muss ein unterstützender Server UTF-8-Kopfzeilen in APPEND akzeptieren; vorher muss er 8-Bit-Kopfzeilen ablehnen. Dieser Positiv-/Negativtest ist wertvoll, bescheinigt aber weder Indexierung noch Anzeige.

Die neue Fassung entfernt das alte APPEND UTF8-Datenelement. IMAP4rev1, IMAP4rev2 und JMAP liefern keinen vertrauenswürdigen Hinweis je Nachricht auf dessen frühere Verwendung. Deshalb gehören Rohinput und Hash, Antwort, gegebenenfalls UID und späterer Abruf desselben Objekts zusammen.

Mailboxnamen brauchen eigene Vektoren. RFC 9755 verlangt Net-Unicode und schließt bestimmte Steuerzeichen aus. RFC 5198 erläutert NFC; RFC 6532 empfiehlt NFC für Kopfzeilen und warnt vor NFKC, wenn Schreibweisen verloren gehen. Gleiche Anzeige, gleiche Bytes und gleiche Suchtreffer sind verschiedene Zusagen.

Die aktuelle Dovecot-Dokumentation zeigt eine reale Nahtstelle: UTF-8-Speicherung von Mailboxnamen ist eine eigene Einstellung, deren Änderung vorhandene Nicht-ASCII-Namen beschädigen kann. Das ist ein Implementierungsbeispiel, keine Marktstudie. Ein Protokollupdate ist keine automatische Speichermigration.

BODYSTRUCTURE kann in zwei Formen korrekt sein

Unkundige Software kann message/global als unbekannten Anhang behandeln. Für aktiviertes IMAP4rev1 erlaubt RFC 9755 zwei BODYSTRUCTURE-Formen und verlangt, dass Clients beide akzeptieren; IMAP4rev2 folgt RFC 9051. Erratum 8697 korrigiert den Bezug auf message/rfc822.

Testdaten müssen beide rev1-Formen, rev2, verschachtelte internationale Kopfzeilen und den Rohabruf enthalten. Ein Anhangssymbol belegt keine korrekte Strukturinterpretation.

Abruf ist nicht Auffindbarkeit

Nach ENABLE darf SEARCH keinen charset-Parameter tragen; SORT und THREAD sollten UTF-8 nutzen. Ein älterer Client kann LIST und FETCH beherrschen, aber falsch suchen. Halten Sie Abfrage und UIDs für zusammengesetzte und zerlegte Formen, Kopfzeilen, Mailboxnamen und Text fest.

Derselbe Mailstore kann über IMAP, POP, Webmail und unterschiedliche Clients erreicht werden. Ablehnung, Hinweis, Verbergen oder standardisierter Surrogattext sind Richtlinien, keine Gleichwertigkeit. Die bereits veröffentlichte Frage nach der Verwahrung des Surrogat-Originals bleibt außerhalb dieses Beitrags; hier zählt das erklärte und beobachtete Ergebnis jedes unterstützten Wegs.

Der letzte Beleg liegt beim Nutzer: Sieht er die Mailbox, findet die Nachricht, erkennt die Beteiligten, öffnet die Teile und kann nach Richtlinie antworten? Die Quellen belegen Standardssemantik und eine Implementierungsnaht, keine Anbieterqualität. In Heng Lus Unterscheidung von symbolischer Darstellung und ausführbarer Realität ist die Fähigkeit Darstellung; die nutzbare Nachricht ist Realität. Zur Normenkette gehören außerdem SMTP-Internationalisierung, die dokumentierte Downgrade-Transformation, das zugehörige vereinfachte POP-Verhalten und die IMAP4rev2-Basis. Sie begrenzen Interoperabilitätsaussagen; sie machen aus einem erfolgreichen Pfad keine universelle Sichtbarkeit.