Zusammenfassung

  • draft-ietf-mailmaint-smtputf8-syntax-05 wurde am 10. September 2026 eingestellt. Die Revision ersetzt eine Aufzählung zulässiger Zeichenklassen durch die PRECIS-IdentifierClass und verlangt die jeweils einschlägige Kontextprüfung.
  • Neu sind zwei ausdrückliche Negativbeispiele: U+3164 HANGUL FILLER kann ohne sichtbare Spur dargestellt werden; U+0640 ARABIC TATWEEL verlängert den vorherigen Buchstaben und ermöglicht viele optische Schreibweisen.
  • Ein positives Syntaxurteil belegt weder die Existenz noch die Kontrolle eines Postfachs. Es sagt auch nichts über Identität, einen vollständigen SMTPUTF8-Pfad oder die Zustellung aus.
  • Der Wortlaut enthält weiterhin eine Unklarheit zwischen einem in Anführungszeichen stehenden Leerzeichen und der in Adressen verwendeten Zeichensetzung. Implementierungen sollten sie nicht stillschweigend als geklärt behandeln.

Der Unterschied, den das Supportfenster nicht zeigt

Zwei Kontodatensätze erscheinen in der Supportkonsole identisch. Trotzdem findet die Anmeldung nur einen davon. In der einen Eingabe steht vor einem Trenner der Codepunkt U+3164. Die verwendete Schrift gibt dem HANGUL FILLER keine sichtbare Fläche, die UTF-8-Folge behält ihn jedoch bei.

Damit können Formular, Datenbank, Suchindex und Wiederherstellungsdienst zu unterschiedlichen Ergebnissen gelangen. Der eine speichert, der nächste normalisiert, der dritte verwirft. Ein Bildschirmfoto bewahrt nur die Darstellung und vernichtet ausgerechnet den Unterschied, um den es bei der Untersuchung geht.

Revision 05 von SMTPUTF8 Email Addresses nimmt U+3164 als unzulässiges Beispiel auf. Hinzu kommt U+0640 ARABIC TATWEEL. Unicode zählt es zur Kategorie der Buchstaben; seine grafische Funktion besteht aber darin, den vorangehenden arabischen Buchstaben zu dehnen. Wiederholungen erzeugen zahlreiche Bytefolgen mit verwandter Erscheinung.

Der Datatracker-Eintrag führt das Dokument als aktiven Internet-Draft der Mail Maintenance Working Group mit dem Ziel Proposed Standard. Die Historie datiert Revision 05 auf den 10. September. Daraus folgen weder RFC-Status noch IETF-Zustimmung, Produktkonformität oder ein beobachteter Angriff.

Aus der kopierten Liste wird eine referenzierte Entscheidung

Revision 04 führte in ihrer zweiten Regel die Kategorien A, H und K sowie ausgewählte F-Zeichen aus RFC 8264 und die Adresszeichen auf. Revision 05 verweist stattdessen auf die IdentifierClass: Nur dort gültige Codepunkte sind zulässig; verlangt die Klasse eine Kontextregel, muss diese erfüllt sein.

Die Verschiebung ist mehr als redaktionelle Kürzung. Eine kopierte Liste kann veralten oder ein bedingtes Zeichen in eine pauschale Erlaubnis verwandeln. RFC 8264 kennt vier Verfügungen: gültig, Kontextregel erforderlich, unzulässig und nicht zugewiesen. Bei Join Controls gehört die Umgebung zur Entscheidung.

IdentifierClass ist für Protokollzeichenfolgen gedacht, die eine Netzentität identifizieren oder adressieren. Sie priorisiert Sicherheit gegenüber Ausdrucksbreite. Traditionelle Buchstaben und Ziffern sowie druckbares ASCII sind innerhalb der Regeln gültig. Alte Hangul-Jamo, Steuerzeichen, ignorierbare Eigenschaften, Leerraum, Kompatibilitätsformen und weitere Gruppen werden ausgeschlossen.

PRECIS nimmt der Anwendung nicht alle Entscheidungen ab. Ein Profil muss Breitenabbildung, zusätzliche Abbildungen, Groß- und Kleinschreibung, Normalisierung und Schreibrichtung festlegen. Die gemeinsame Klasse begrenzt lokale Politik; sie ersetzt sie nicht.

Warum „Buchstabe“ für U+0640 nicht reicht

RFC 5892 führt U+0640 in einer ausdrücklichen Ausnahmetabelle als DISALLOWED. Ohne diese Ausnahme würde die allgemeine Eigenschaftsberechnung PVALID liefern. Ein Diagnoseeintrag, der nur die Unicode-Hauptkategorie nennt, hat den normativen Pfad somit nicht vollständig festgehalten.

Die öffentlichen Tests der Autoren prüfen zusätzlich Bidirektionalitäts-Steuerzeichen, vollbreite Kompatibilitätsbuchstaben, kombinierbare alte Hangul-Jamo und die entsprechende vorkomponierte Silbe. Sie machen die vorgeschlagene Grenze reproduzierbar. Sie beweisen nicht, dass Registrierung, Anmeldung, Wiederherstellung, Export und SMTP dieselbe Bibliothek ausführen.

Die dritte Entwurfsregel verbietet mehr als ein Nicht-ASCII-Schriftsystem in einer Adresse, wobei ASCII bei der Zählung außer Betracht bleibt. Unicode Standard Annex #24 definiert die dafür verwendete Script-Eigenschaft. Das ist eine Interoperabilitätsregel für Kennungen, kein Urteil über mehrsprachige Menschen.

Das Leerzeichen in Anführungszeichen bleibt offen

Der aktuelle Satz lässt sich wörtlich so lesen, dass neben IdentifierClass-gültigen Codepunkten ein in Anführungszeichen stehendes Leerzeichen erlaubt sei. Direkt danach nennen die Beispiele Punkt, Schrägstrich und At-Zeichen. Auch die öffentliche Autorenvorlage enthält diese Formulierung.

Ob es sich um einen Satzfehler, eine vorausgesetzte mailbox-Grammatik oder noch unfertigen Text handelt, ist aus dem veröffentlichten Material nicht zu entscheiden. Zeichensetzung strukturiert Lokalteil und Domain; Repertoire und Grammatik sind daher getrennte Prüfschichten.

Wer für eine Implementierung eine Lesart wählen muss, sollte Entwurfsversion, Annahme und Test festhalten. Eine heimliche Berichtigung kann funktionsfähigen Code ergeben, aber keine gemeinsame Konformitätsaussage.

Zulässigkeit ist weder Identität noch Zustellung

RFC 6532 ermöglicht direktes UTF-8 in internationalisierten Mail-Kopfzeilen und Adressen. Der neue Entwurf schränkt ein, welche Zeichenfolgen daraus interoperabel sein sollen. Beide Ebenen bleiben von Authentifizierung getrennt.

Eine zulässige Adresse kann zu keinem Postfach führen. Eine beantwortete Nachricht kann zeitweilige Kontrolle zeigen, nicht die bürgerliche Person oder Vertretungsmacht. Eine Anwendung kann den Wert annehmen und beim Export verändern. Ein SMTPUTF8-fähiger erster Hop ist kein Beleg für die gesamte Route. Auch eine verbotene Eingabe beweist keine Absicht; sie kann unbemerkt kopiert worden sein.

Die frühere BTW-Geschichte über SMTPUTF8 behandelte die unverfälschte Weitergabe des internationalisierten Lokalteils und die fehlende allgemeine Herabstufung. Diese Nachricht untersucht das vorgelagerte Zulassungsprädikat. Beide Kontrollen können unabhängig scheitern.

Ein Zulassungsbeleg statt eines bloßen Ja oder Nein

Der Beleg beginnt mit den UTF-8-Bytes und der geordneten Codepunktfolge. Er verknüpft jedes Nicht-ASCII-Zeichen mit seiner IdentifierClass-Verfügung, einer Kontextregel samt Ergebnis und der Script-Berechnung. Dazu gehören die grammatische Position sowie angewandte Abbildungs-, Groß-/Kleinschreibungs-, Normalisierungs- und Bidi-Regeln.

Anschließend nennt er Unicode/PRECIS-Datenversion, Validator-Build, aufrufende Oberfläche, Zeit, Aktion und Korrekturweg. In einer Konsole sollte neben der lesbaren Form eine sichere Escape-Darstellung stehen; die Rohfassung ist geschützte Evidenz.

Dieser Beleg ist ein redaktioneller Vorschlag von Daniel Kade, keine IETF-Vorgabe. Er vereinheitlicht nicht die Kontopolitik. Er ermöglicht zu erklären, ob mehrere Dienste dasselbe Eingabeobjekt nach derselben Version beurteilt haben.

Quellen