Zusammenfassung

  • SMTPUTF8 erweiterte Mailboxnamen im Envelope und Headerwerte auf UTF-8, jedoch erst nach der Fähigkeitsanzeige jedes Servers; ein Anbieter musste zusätzlich 8BITMIME ankündigen.
  • Eine Domain ließ sich per IDNA als A-label darstellen, ein Nicht-ASCII-Local-Part besaß kein allgemeines Äquivalent. An einem unfähigen Weg blieben autorisierte Submission-Transformation, andere Route, Wiederholung oder Fehler — keine erfundene Mailbox.

Ein vertrauter Name war noch keine Adresse

MIME konnte Namen und Betreff außerhalb von ASCII zeigen. RFC 6530 trennt diese Anzeige jedoch vom SMTP-Envelope: Der sichtbare Name lenkt die Zustellung nicht.

IDNA internationalisierte die Domain rechts von @. Der Local-Part blieb ein vom finalen System verwalteter Name. Für Unicode-Domains gibt es eine DNS-taugliche A-label-Form; für Mailboxnamen keine universelle Transliteration. Ersatz kann ins Leere oder zu einer anderen Person führen.

Vollständige Internationalisierung brauchte deshalb einen Weg, der den Namen bewahrt, nicht bloß eine Oberfläche, die ihn darstellt.

Der Standards Track verwarf den Transit-Downgrade

RFC 6530 ersetzte RFC 4952 und erklärte experimentelle Zwischen-Downgrades für irrelevant. Ein Relay in der Mitte hatte keine Autorität, eine ASCII-Identität zu erfinden.

Die Dokumente vom Februar 2012 teilten Verantwortung: RFC 6531 definierte SMTP, RFC 6532 UTF-8-Header, RFC 6533 Benachrichtigungen, die den internationalen Empfänger erhalten. Das war keine Übersetzungstabelle, sondern eine Umgebung, in der Envelope, Nachricht und Fehlerbeleg dieselbe Adresse nannten.

SMTPUTF8 war ein vollständiges Versprechen

Der Server nennt SMTPUTF8 in EHLO. Das IANA-SMTP-Register führt es ohne Parameter. RFC 6531 verlangt vollständige Konformität sowie Unterstützung und Anzeige von 8BITMIME.

8BITMIME schützt Hochbit-Oktette im Body; SMTPUTF8 erweitert Envelope-Adressen und identitätstragende Header. Die zweite Erweiterung braucht die erste, ersetzt sie aber nicht.

Der Client kann den wertlosen Parameter SMTPUTF8 an MAIL FROM hängen. Damit erklärt er, dass Envelope, Nachricht oder Header die Erweiterung benötigen. SMTP-Trenner bleiben bestehen; das Zeichenrepertoire wächst.

Der Weg wurde Bedingung der Erreichbarkeit

Ohne Anzeige darf der Client weder internationale Adresse noch RFC-6532-Header übertragen, auch nicht verschachtelt in MIME. Dieselbe Mailbox kann über einen fähigen MX erreichbar und über einen anderen blockiert sein. Alternative MX oder Wiederholung suchen einen treuen Weg; sie ändern nicht den Namen.

Ein Submission Agent hat am nutzerkontrollierten Rand mehr Spielraum. Kennt er einen tatsächlich provisionierten ASCII-Alias, kann er eine gewöhnliche Nachricht bauen. RFC 6531 definiert diese Transformation nicht und gibt Transit-Relays keine Lizenz zur Improvisation.

Ohne legitime Wandlung oder Route soll das System ablehnen, benachrichtigen, neu einreihen oder einen anderen Host versuchen. Fehler trennt „Weg kann Namen nicht tragen“ von „Mailbox existiert nicht“.

UTF-8 kam in Werte, nicht in Feldnamen

RFC 6532 erlaubt direktes UTF-8 in Subject, Adressen, Zeichenketten und manchen Message-ID-Konstruktionen. Headernamen bleiben ASCII. Das harte Limit beträgt 998 Oktette; die Anzeigeempfehlung von 78 Einheiten bleibt zeichenbasiert.

Normalisierung erzeugt ebenfalls keine Identität. RFC 6532 empfiehlt NFC und warnt vor NFKC, wenn Schreibweisen verloren gehen. Der finale Zusteller interpretiert seinen Local-Part.

Fehlerberichte mussten den fehlgeschlagenen Namen bewahren

RFC 6533 definiert einen UTF-8-Adresstyp und Formen für ORCPT und DSN, darunter eine siebenbit-sichere Kodierung. Sie bewahrt die Originaladresse als Beweis, erschafft aber keine zustellbare ASCII-Mailbox.

Wer SMTPUTF8 und DSN gemeinsam anbietet, muss RFC 6533 implementieren. Ein Bericht ohne den betroffenen Namen wäre nicht korrelierbar.

Fähigkeit war kein Eigentum

SMTPUTF8 beweist Parsing- und Transportfähigkeit, nicht Existenz, Besitz, visuelle Gleichheit oder Zustellung. Domaininhaber verwalten DNS; finale Systeme ihre Mailboxen; Relays transportieren oder scheitern. Keiner darf eine Ersatzperson erfinden.

Quellen und Grenzen

Rahmen, Transport, Header und Benachrichtigungen stammen aus RFC 6530, RFC 6531, RFC 6532 und RFC 6533; den Eintrag liefert IANA. Keine Quelle misst heutige Unterstützung, Zustellbarkeit oder Eigentum.