Zum Hauptinhalt springen

7. Überblick über Protokollerweiterungen und -änderungen

7.1. SMTP-Erweiterung für internationalisierte E-Mail-Adressen​

Eine SMTP-Erweiterung, "SMTPUTF8", wird wie folgt spezifiziert:

  • Erlaubt die Verwendung von UTF-8-Zeichenketten in E-Mail-Adressen, sowohl in lokalen Teilen als auch in Domänennamen.

  • Erlaubt die selektive Verwendung von UTF-8-Zeichenketten in E-Mail-Nachrichtenheadern (siehe Abschnitt 7.2).

  • Erfordert, dass der Server die 8BITMIME-Erweiterung [RFC6152] ankündigt und dass der Client 8-Bit-Übertragung unterstützt, damit Header-Informationen ohne Verwendung einer speziellen content-transfer-encoding übertragen werden können.

Einige allgemeine Prinzipien beeinflussen die Entwicklungsentscheidungen, die dieser Arbeit zugrunde liegen.

  1. E-Mail-Adressen gelangen in Subsysteme (wie eine Benutzeroberfläche), die Zeichensatzkonvertierungen oder andere Kodierungsänderungen vornehmen können. Wenn der lokale Teil der Adresse Zeichen außerhalb des ASCII-Zeichenrepertoires enthält, wird die Verwendung von ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] im Domänenteil abgeraten, um eine konsistente Verarbeitung von Zeichen in der gesamten Adresse zu fördern.

  2. Ein SMTP-Relay muss (MUST)

    • entweder das Format explizit erkennen und dem über eine ESMTP-Option zustimmen, oder
    • die Nachricht ablehnen oder, falls erforderlich, eine Unzustellbarkeitsbenachrichtigung zurückgeben, damit der Absender einen anderen Plan machen kann.

  3. Wenn die Nachricht nicht weitergeleitet werden kann, weil das Next-Hop-System die Erweiterung nicht akzeptieren kann, muss sie (MUST) abgelehnt werden oder es muss (MUST) eine Unzustellbarkeitsnachricht generiert und gesendet werden.

  4. Im Interesse der Interoperabilität sind andere Zeichensätze als UTF-8 in E-Mail-Adressen und Nachrichtenheadern, die über das Internet übertragen werden, verboten. Es gibt keine praktische Möglichkeit, mehrere Zeichensätze mit einer ähnlichen Erweiterung wie dieser ordnungsgemäß zu identifizieren, ohne große Komplexität einzuführen.

Die Konformität mit der hier spezifizierten Gruppe von Standards für E-Mail-Transport und -Zustellung erfordert die Implementierung der SMTP-Erweiterungsspezifikation und der UTF-8-Header-Spezifikation. Wenn das System IMAP oder POP implementiert, muss es (MUST) konform zu den internationalisierten IMAP- [RFC5738bis-IMAP] bzw. POP- [RFC5721bis-POP3] Spezifikationen sein.

7.2. Übertragung von E-Mail-Header-Feldern in UTF-8-Kodierung​

Es gibt viele Stellen in MUAs oder in einer Benutzerdarstellung, an denen E-Mail-Adressen oder Domänennamen erscheinen. Beispiele sind die konventionellen Header-Felder "From:", "To:" oder "Cc:"; die Header-Felder "Message-ID:" und "In-Reply-To:", die normalerweise Domänennamen enthalten (aber ein Sonderfall sein können); und in Nachrichtentexten. Jede davon muss aus einer Internationalisierungsperspektive untersucht werden. Der Benutzer wird erwarten, Postfach- und Domänennamen in lokalen Zeichen zu sehen, und zwar konsistent. Wenn nicht offensichtliche Kodierungen wie protokollspezifische ACE-Varianten verwendet werden, wird der Benutzer sie unweigerlich, wenn auch nur gelegentlich, anstelle von "nativen" Zeichen sehen und dies als befremdlich oder erstaunlich empfinden. Ebenso wird der Benutzer besonders wahrscheinlich überrascht sein, wenn für Mail-Transport und Nachrichtentexte unterschiedliche Kodierungen verwendet werden, sei es auch nur als Folge des seit langem etablierten Prinzips "things leak". Die einzige praktische Möglichkeit, diese Quellen der Unannehmlichkeit sowohl mittel- als auch längerfristig zu vermeiden, besteht darin, dass die im Transport verwendeten Kodierungen den im Nachrichtenheader und im Nachrichtentext verwendeten Kodierungen so ähnlich wie möglich sind.

Wenn lokale E-Mail-Teile internationalisiert werden, sollten (SHOULD) sie von Vorkehrungen begleitet werden, dass die Nachrichtenheader in der vollständig internationalisierten Form vorliegen. Diese Form sollte (SHOULD) UTF-8 anstelle von ASCII als Basiszeichensatz für die Inhalte von Header-Feldern verwenden (Protokollelemente wie die Header-Feldnamen selbst sind unverändert und bleiben vollständig in ASCII). Für Übergangszwecke und Kompatibilität mit Legacy-Systemen kann dies durch Erweiterung der traditionellen MIME-Kodierungsmodelle für non-ASCII-Zeichen in Headern [RFC2045] [RFC2231] erfolgen, aber selbst diese sollten nach Möglichkeit auf UTF-8 statt auf anderen Kodierungen basieren [RFC6055]. Das Ziel sind jedoch vollständig internationalisierte Nachrichtenheader, wie in [RFC6532] diskutiert, und kein erweiterter und schmerzhafter Übergang.

7.3. SMTP-Diensterweiterung für DSNs​

Die bestehende Spezifikation für Delivery Status Notifications (DSNs) [RFC3461], die ein Draft Standard ist, ist auf ASCII-Text in den maschinenlesbaren Teilen des Protokolls beschränkt. "International Delivery and Disposition Notifications" [RFC6533] fügt einen neuen Adresstyp für internationale E-Mail-Adressen hinzu, sodass eine ursprüngliche Empfängeradresse mit non-ASCII-Zeichen auch nach einem Downgrading korrekt erhalten werden kann. Wenn ein SMTP-Server sowohl die SMTPUTF8- als auch die DSN-Erweiterung ankündigt, muss (MUST) dieser Server internationalisierte DSNs implementieren, einschließlich der Unterstützung für den in RFC 3461 [RFC3461] spezifizierten Parameter ORCPT.