Zum Hauptinhalt springen

RFC 6531 - SMTP-Erweiterung für internationalisierte E-Mail

  • Status: Proposed Standard
  • Veröffentlicht: February 2012
  • Stream: IETF
  • Ersetzt: RFC5336
  • Errata: Keine Errata

Document Information​

  • RFC Number: 6531
  • Title: SMTP Extension for Internationalized Email
  • Authors: J. Yao, W. Mao
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 5336
  • ISSN: 2070-1721

Abstract​

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Dieses Dokument spezifiziert eine SMTP-Erweiterung für den Transport und die Zustellung von E-Mail-Nachrichten mit internationalisierten E-Mail-Adressen oder Header-Informationen.

Status of This Memo​

This is an Internet Standards Track document. Dies ist ein Internet Standards Track-Dokument.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es repräsentiert den Konsens der IETF-Gemeinschaft. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internet-Standards finden Sie in Abschnitt 2 von RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6531. Informationen zum aktuellen Status dieses Dokuments, etwaige Errata und Hinweise zur Abgabe von Feedback finden Sie unter http://www.rfc-editor.org/info/rfc6531.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Copyright (c) 2012 IETF Trust und die als Autoren des Dokuments identifizierten Personen. Alle Rechte vorbehalten.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (http://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gelten. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Code-Komponenten, die aus diesem Dokument extrahiert werden, müssen den Text der vereinfachten BSD-Lizenz enthalten, wie in Abschnitt 4.e der rechtlichen Bestimmungen des Trust beschrieben, und werden ohne Gewährleistung bereitgestellt, wie in der vereinfachten BSD-Lizenz beschrieben.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Dieses Dokument kann Material aus IETF-Dokumenten oder IETF-Beiträgen enthalten, die vor dem 10. November 2008 veröffentlicht oder öffentlich zugänglich gemacht wurden. Die Person(en), die das Urheberrecht an einem Teil dieses Materials kontrollieren, haben dem IETF Trust möglicherweise nicht das Recht eingeräumt, Änderungen an diesem Material außerhalb des IETF-Standardisierungsprozesses zu gestatten. Ohne eine angemessene Lizenz von der/den Person(en) zu erhalten, die das Urheberrecht an solchen Materialien kontrollieren, darf dieses Dokument nicht außerhalb des IETF-Standardisierungsprozesses geändert werden, und es dürfen keine abgeleiteten Werke davon außerhalb des IETF-Standardisierungsprozesses erstellt werden, außer um es für die Veröffentlichung als RFC zu formatieren oder es in andere Sprachen als Englisch zu übersetzen.

Table of Contents​

  1. Introduction
  2. Overview of Operation
  3. Mail Transport-Level Protocol
  4. IANA Considerations
  5. Security Considerations
  6. Acknowledgements
  7. References

1. Introduction​

The document defines a Simple Mail Transfer Protocol [RFC5321] extension so servers can advertise the ability to accept and process internationalized email addresses (see Section 1.1) and internationalized email headers [RFC6532]. Dieses Dokument definiert eine Erweiterung des Simple Mail Transfer Protocol [RFC5321], damit Server die Fähigkeit ankündigen können, internationalisierte E-Mail-Adressen (siehe Abschnitt 1.1) und internationalisierte E-Mail-Header [RFC6532] zu akzeptieren und zu verarbeiten.

An extended overview of the extension model for internationalized email addresses and the email header appears in RFC 6530 [RFC6530], referred to as "the framework document" in this specification. A thorough understanding of the information in that document and in the base Internet email specifications [RFC5321] [RFC5322] is necessary to understand and implement this specification. Ein erweiterter Überblick über das Erweiterungsmodell für internationalisierte E-Mail-Adressen und den E-Mail-Header findet sich in RFC 6530 [RFC6530], das in dieser Spezifikation als "das Rahmenwerk-Dokument" bezeichnet wird. Ein gründliches Verständnis der Informationen in diesem Dokument und in den grundlegenden Internet-E-Mail-Spezifikationen [RFC5321] [RFC5322] ist notwendig, um diese Spezifikation zu verstehen und zu implementieren.

1.1. Terminology​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in RFC 2119 [RFC2119] beschrieben.

The terms "UTF-8 string" or "UTF-8 character" are used to refer to Unicode characters, which may or may not be members of the ASCII subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All other specialized terms used in this specification are defined in the framework document or in the base Internet email specifications. In particular, the terms "ASCII address", "internationalized email address", "non-ASCII address", "SMTPUTF8", "internationalized message", and "message" are used in this document according to the definitions in the framework document [RFC6530]. Die Begriffe "UTF-8-Zeichenkette" oder "UTF-8-Zeichen" werden verwendet, um auf Unicode-Zeichen zu verweisen, die Mitglieder der ASCII-Teilmenge sein können oder auch nicht, in UTF-8 [RFC3629], einer Standard-Unicode-Kodierungsform. Alle anderen spezialisierten Begriffe, die in dieser Spezifikation verwendet werden, sind im Rahmenwerk-Dokument oder in den grundlegenden Internet-E-Mail-Spezifikationen definiert. Insbesondere werden die Begriffe "ASCII-Adresse", "internationalisierte E-Mail-Adresse", "Nicht-ASCII-Adresse", "SMTPUTF8", "internationalisierte Nachricht" und "Nachricht" in diesem Dokument gemäß den Definitionen im Rahmenwerk-Dokument [RFC6530] verwendet.

Strings referred to in this document, including ASCII strings, MUST be expressed in UTF-8. Zeichenketten, auf die in diesem Dokument verwiesen wird, einschließlich ASCII-Zeichenketten, MÜSSEN in UTF-8 ausgedrückt werden.

This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some basic rules in this document are identified in Section 3.3 as being defined (under the same names) in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532]. Diese Spezifikation verwendet Regeln der erweiterten Backus-Naur-Form (ABNF) [RFC5234]. Einige grundlegende Regeln in diesem Dokument werden in Abschnitt 3.3 als (unter denselben Namen) definiert in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890] oder RFC 6532 [RFC6532] identifiziert.

1.2. Changes Made to Other Specifications​

This specification extends some syntax rules defined in RFC 5321 and permits internationalized email addresses in the envelope and in trace fields, but it does not modify RFC 5321. It permits data formats defined in RFC 6532 [RFC6532], but it does not modify RFC 5322. It does require that the 8BITMIME extension [RFC6152] be announced by the SMTPUTF8-aware SMTP server and used with "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not modify the 8BITMIME specification in any way. Diese Spezifikation erweitert einige in RFC 5321 definierte Syntaxregeln und erlaubt internationalisierte E-Mail-Adressen im Umschlag und in Trace-Feldern, modifiziert jedoch nicht RFC 5321. Sie erlaubt in RFC 6532 [RFC6532] definierte Datenformate, modifiziert jedoch nicht RFC 5322. Sie erfordert, dass die 8BITMIME-Erweiterung [RFC6152] vom SMTPUTF8-fähigen SMTP-Server angekündigt und vom SMTPUTF8-fähigen SMTP-Client mit "BODY=8BITMIME" verwendet wird, modifiziert jedoch die 8BITMIME-Spezifikation in keiner Weise.

This specification replaces an earlier, experimental, approach to the same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this specification. Anyone trying to convert an implementation from the experimental specification to the specification in this document will need to review those changes carefully. Diese Spezifikation ersetzt einen früheren, experimentellen Ansatz für dasselbe Problem [RFC5336]. Abschnitt 6 von RFC 6530 [RFC6530] beschreibt die Änderungen im Ansatz zwischen RFC 5336 [RFC5336] und dieser Spezifikation. Jeder, der versucht, eine Implementierung von der experimentellen Spezifikation auf die Spezifikation in diesem Dokument umzustellen, muss diese Änderungen sorgfältig prüfen.

2. Overview of Operation​

This document specifies an element of the email internationalization work, specifically the definition of an SMTP extension for internationalized email. The extension is identified with the token "SMTPUTF8". Dieses Dokument spezifiziert ein Element der Arbeit zur E-Mail-Internationalisierung, insbesondere die Definition einer SMTP-Erweiterung für internationalisierte E-Mail. Die Erweiterung wird mit dem Token "SMTPUTF8" identifiziert.

The internationalized email headers specification [RFC6532] provides the details of email header features enabled by this extension. Die Spezifikation für internationalisierte E-Mail-Header [RFC6532] liefert die Details der E-Mail-Header-Funktionen, die durch diese Erweiterung ermöglicht werden.

3. Mail Transport-Level Protocol​

3.1. Framework for the Internationalization Extension​

The following service extension is defined: Die folgende Diensterweiterung wird definiert:

  1. The name of the SMTP service extension is "Internationalized Email".

  2. Der Name der SMTP-Diensterweiterung ist "Internationalized Email".

  3. The EHLO keyword value associated with this extension is "SMTPUTF8".

  4. Der mit dieser Erweiterung verbundene EHLO-Schlüsselwortwert ist "SMTPUTF8".

  5. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The SMTPUTF8-aware SMTP client MUST ignore any parameters if they appear for this keyword; that is, the SMTPUTF8-aware SMTP client MUST behave as if the parameters do not appear. If an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification.

  6. Für diesen EHLO-Schlüsselwortwert sind keine Parameterwerte definiert. Um zukünftige (wenn auch nicht vorhergesehene) Erweiterungen zu ermöglichen, DARF die EHLO-Antwort KEINE Parameter für dieses Schlüsselwort enthalten. Der SMTPUTF8-fähige SMTP-Client MUSS alle Parameter ignorieren, wenn sie für dieses Schlüsselwort erscheinen; das heißt, der SMTPUTF8-fähige SMTP-Client MUSS sich so verhalten, als ob die Parameter nicht erscheinen würden. Wenn ein SMTP-Server SMTPUTF8 in seine EHLO-Antwort aufnimmt, MUSS er vollständig konform mit dieser Version dieser Spezifikation sein.

  7. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. The parameter does not accept a value. If this parameter is set in the MAIL command, it indicates that the SMTP client is SMTPUTF8-aware. Its presence also asserts that the envelope includes the non-ASCII address, the message being sent is an internationalized message, or the message being sent needs the SMTPUTF8 support.

  8. Ein OPTIONALER Parameter, SMTPUTF8, wird zum MAIL-Befehl hinzugefügt. Der Parameter akzeptiert keinen Wert. Wenn dieser Parameter im MAIL-Befehl gesetzt ist, zeigt er an, dass der SMTP-Client SMTPUTF8-fähig ist. Seine Anwesenheit bestätigt auch, dass der Umschlag die Nicht-ASCII-Adresse enthält, die gesendete Nachricht eine internationalisierte Nachricht ist oder die gesendete Nachricht die SMTPUTF8-Unterstützung benötigt.

  9. The maximum length of a MAIL command line is increased by 10 characters to accommodate the possible addition of the SMTPUTF8 parameter.

  10. Die maximale Länge einer MAIL-Befehlszeile wird um 10 Zeichen erhöht, um die mögliche Hinzufügung des SMTPUTF8-Parameters zu berücksichtigen.

  11. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not accept a value. The parameter indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands.

  12. Ein OPTIONALER Parameter, SMTPUTF8, wird zu den Befehlen VERIFY (VRFY) und EXPAND (EXPN) hinzugefügt. Der SMTPUTF8-Parameter akzeptiert keinen Wert. Der Parameter zeigt an, dass der SMTP-Client Unicode-Zeichen in UTF-8-Kodierung in Antworten auf die VRFY- und EXPN-Befehle akzeptieren kann.

  13. No additional SMTP verbs are defined by this extension.

  14. Es werden keine zusätzlichen SMTP-Verben durch diese Erweiterung definiert.

  15. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152].

  16. Server, die diese Erweiterung anbieten, MÜSSEN Unterstützung für die 8BITMIME-Erweiterung [RFC6152] bieten und diese ankündigen.

  17. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended to allow Unicode characters encoded in UTF-8 in mailbox names (addresses).

  18. Der Reverse-Path und Forward-Path der SMTP MAIL- und RCPT-Befehle werden erweitert, um Unicode-Zeichen, die in UTF-8 kodiert sind, in Mailbox-Namen (Adressen) zuzulassen.

  19. The mail message body is extended as specified in RFC 6532 [RFC6532].

  20. Der E-Mail-Nachrichtenkörper wird wie in RFC 6532 [RFC6532] spezifiziert erweitert.

  21. The SMTPUTF8 extension is valid on the submission port [RFC6409]. It may also be used with the Local Mail Transfer Protocol (LMTP) [RFC2033]. When these protocols are used, their use should be reflected in the trace field WITH keywords as appropriate [RFC3848].

  22. Die SMTPUTF8-Erweiterung ist auf dem Submission-Port [RFC6409] gültig. Sie kann auch mit dem Local Mail Transfer Protocol (LMTP) [RFC2033] verwendet werden. Wenn diese Protokolle verwendet werden, sollte ihre Verwendung in den Trace-Feld-WITH-Schlüsselwörtern entsprechend widergespiegelt werden [RFC3848].

3.2. The SMTPUTF8 Extension​

An SMTP server that announces the SMTPUTF8 extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a <mailbox> can appear. Although the characters in the <local-part> are permitted to contain non-ASCII characters, the actual parsing of the <local-part> and the delimiters used are unchanged from the base email specification [RFC5321]. Any domain name to be looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully-qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890]. Ein SMTP-Server, der die SMTPUTF8-Erweiterung ankündigt, MUSS bereit sein, eine UTF-8-Zeichenkette [RFC3629] an jeder Position zu akzeptieren, an der RFC 5321 angibt, dass eine <mailbox> erscheinen kann. Obwohl die Zeichen im <local-part> Nicht-ASCII-Zeichen enthalten dürfen, bleiben das eigentliche Parsen des <local-part> und die verwendeten Trennzeichen gegenüber der grundlegenden E-Mail-Spezifikation [RFC5321] unverändert. Jeder Domänenname, der im DNS nachgeschlagen werden soll, MUSS den Spezifikationen für Internationalizing Domain Names in Applications (IDNA) [RFC5890] entsprechen und gemäß diesen verarbeitet werden. Beim Durchführen von Nachschlagevorgängen MUSS der SMTPUTF8-fähige SMTP-Client oder -Server entweder eine Unicode-fähige DNS-Bibliothek verwenden oder den internationalisierten Domänennamen in die A-Label-Form (d. h. einen vollqualifizierten Domänennamen, der ein oder mehrere A-Labels, aber keine U-Labels enthält) transformieren, wie in RFC 5890 [RFC5890] spezifiziert.

An SMTP client that receives the SMTPUTF8 extension keyword in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form. It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321. Ein SMTP-Client, der das SMTPUTF8-Erweiterungsschlüsselwort als Antwort auf den EHLO-Befehl erhält, KANN Mailbox-Namen innerhalb von SMTP-Befehlen als internationalisierte Zeichenketten in UTF-8-Form übertragen. Er KANN einen UTF-8-Header [RFC6532] senden (der auch Mailbox-Namen in UTF-8 enthalten kann). Er KANN die Domänenteile von Mailbox-Namen innerhalb von SMTP-Befehlen oder dem Nachrichten-Header als A-Labels oder U-Labels übertragen [RFC5890]. Das Vorhandensein der SMTPUTF8-Erweiterung ändert nicht die in RFC 5321 beschriebenen Server-Relay-Verhaltensweisen.

If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address and MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045]. (For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) Instead, if an SMTPUTF8-aware SMTP client (sender) attempts to transfer an internationalized message and encounters an SMTP server that does not support the extension, the best action for it to take depends on other conditions. In particular: Wenn die SMTPUTF8-SMTP-Erweiterung nicht vom SMTP-Server angeboten wird, DARF der SMTPUTF8-fähige SMTP-Client KEINE internationalisierte E-Mail-Adresse übertragen und DARF KEINE E-Mail-Nachricht übertragen, die internationalisierte E-Mail-Header wie in RFC 6532 [RFC6532] beschrieben auf irgendeiner Ebene innerhalb ihrer MIME-Struktur enthält [RFC2045]. (Für diesen Absatz wird der internationalisierte Domänenname in A-Label-Form, wie in den IDNA-Definitionen [RFC5890] spezifiziert, nicht als "internationalisiert" betrachtet.) Stattdessen hängt die beste Vorgehensweise für einen SMTPUTF8-fähigen SMTP-Client (Absender), der versucht, eine internationalisierte Nachricht zu übertragen und auf einen SMTP-Server stößt, der die Erweiterung nicht unterstützt, von anderen Bedingungen ab. Insbesondere:

  • If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document.

  • Wenn es sich um einen Message Submission Agent (MSA) [RFC6409] [RFC5598] handelt, KANN er seinen eigenen Weg wählen, um mit diesem Szenario umzugehen, indem er den weiten Spielraum für das Ändern von Adressen oder das anderweitige Reparieren und Transformieren von Nachrichten nutzt, der durch RFC 6409 erlaubt ist. Solange die resultierende Nachricht den Anforderungen von RFC 5321 entspricht (d. h. ohne die SMTPUTF8-Erweiterung), liegen die Details dieser Transformation außerhalb des Geltungsbereichs dieses Dokuments.

  • If it is not an MSA or is an MSA and does not choose to transform the message to one that does not require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmitting a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533].

  • Wenn es kein MSA ist oder ein MSA ist und sich nicht entscheidet, die Nachricht in eine zu transformieren, die die SMTPUTF8-Erweiterung nicht erfordert, SOLLTE er die Nachricht ablehnen. Wie üblich kann dies entweder durch Erzeugen einer entsprechenden Antwort während der SMTP-Transaktion oder durch Akzeptieren der Nachricht und anschließendes Erzeugen und Übertragen einer Unzustellbarkeitsbenachrichtigung erfolgen. Wenn die letztere Wahl getroffen wird, MUSS der Benachrichtigungsprozess den Anforderungen von RFC 5321, RFC 3464 [RFC3464] und RFC 6533 [RFC6533] entsprechen.

  • As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section.

  • Wie in Abschnitt 2.2.3 von RFC 5321 spezifiziert, KANN ein SMTP-Client mit zusätzlichen Informationen und/oder Kenntnissen über besondere Umstände wählen, die Nachricht erneut in die Warteschlange zu stellen und es später erneut zu versuchen und/oder einen alternativen MX-Host zu versuchen, wie in diesem Abschnitt spezifiziert.

This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. For all other cases, and for addresses and messages that do not require an SMTPUTF8 extension, SMTPUTF8-aware SMTP clients and servers do not change the behavior specified in RFC 5321 [RFC5321]. Dieses Dokument gilt, wenn ein SMTPUTF8-fähiger SMTP-Client oder -Server die SMTPUTF8-Erweiterung unterstützt. Für alle anderen Fälle und für Adressen und Nachrichten, die keine SMTPUTF8-Erweiterung erfordern, ändern SMTPUTF8-fähige SMTP-Clients und -Server das in RFC 5321 [RFC5321] spezifizierte Verhalten nicht.

If an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533]. Wenn ein SMTPUTF8-fähiger SMTP-Server die Delivery Status Notification (DSN) [RFC3461]-Erweiterung ankündigt, MUSS er RFC 6533 [RFC6533] implementieren.

3.3. Extended Mailbox Address Syntax​

RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. This document extends <Mailbox> to add support of non-ASCII characters. RFC 5321, Abschnitt 4.1.2, definiert die Syntax einer <Mailbox> vollständig in Bezug auf ASCII-Zeichen. Dieses Dokument erweitert <Mailbox>, um die Unterstützung von Nicht-ASCII-Zeichen hinzuzufügen.

The key changes made by this specification include: Die wichtigsten Änderungen, die durch diese Spezifikation vorgenommen wurden, umfassen:

  • The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. Other related rules are imported from RFC 5321, RFC 5234, RFC 5890, and RFC 6532, or are extended in this document.

  • Die ABNF-Regel <Mailbox> wird aus RFC 5321 importiert und aktualisiert, um die internationalisierte E-Mail-Adresse zu unterstützen. Andere verwandte Regeln werden aus RFC 5321, RFC 5234, RFC 5890 und RFC 6532 importiert oder in diesem Dokument erweitert.

  • The definition of <sub-domain> is extended to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that conforms with IDNA definitions [RFC5890].

  • Die Definition von <sub-domain> wird erweitert, um sowohl die RFC 5321-Definition als auch eine UTF-8-Zeichenkette in einem DNS-Label zu erlauben, das den IDNA-Definitionen [RFC5890] entspricht.

  • The definition of <atext> is extended to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or control characters.

  • Die Definition von <atext> wird erweitert, um sowohl die RFC 5321-Definition als auch eine UTF-8-Zeichenkette zu erlauben. Diese Zeichenkette DARF KEINE der ASCII-Grafik- oder Steuerzeichen enthalten.

The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document: Die folgenden ABNF-Regeln, die aus RFC 5321, Abschnitt 4.1.2, importiert wurden, werden direkt oder indirekt durch dieses Dokument aktualisiert:

  • <Mailbox>
  • <Local-part>
  • <Dot-string>
  • <Quoted-string>
  • <QcontentSMTP>
  • <Domain>
  • <Atom>

The following ABNF rule will be imported from RFC 6532, Section 3.1, directly: Die folgende ABNF-Regel wird direkt aus RFC 6532, Abschnitt 3.1, importiert:

  • <UTF8-non-ascii>

The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly: Die folgende ABNF-Regel wird direkt aus RFC 5234, Anhang B.1, importiert:

  • <DQUOTE>

The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly: Die folgende ABNF-Regel wird direkt aus RFC 5890, Abschnitt 2.3.2.1, importiert:

  • <U-label>

The following rules are extended in ABNF [RFC5234] as follows. Die folgenden Regeln werden in ABNF [RFC5234] wie folgt erweitert.

sub-domain   =/  U-label
 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

atext   =/  UTF8-non-ascii
 ; extend the implicit definition of atext in
 ; RFC 5321, Section 4.1.2, which ultimately points to
 ; the actual definition in RFC 5322, Section 3.2.3

qtextSMTP  =/ UTF8-non-ascii
 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

esmtp-value  =/ UTF8-non-ascii
 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. MAIL Command Parameter Usage​

If the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If this parameter is provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP client is aware that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command. Wenn der Umschlag oder die gesendete Nachricht die Fähigkeiten der SMTPUTF8-Erweiterung erfordert, MUSS der SMTPUTF8-fähige SMTP-Client den SMTPUTF8-Parameter mit dem MAIL-Befehl liefern. Wenn dieser Parameter bereitgestellt wird, DARF er keinen Wert akzeptieren. Wenn dem SMTPUTF8-fähigen SMTP-Client bekannt ist, dass weder der Umschlag noch die gesendete Nachricht eine der SMTPUTF8-Erweiterungsfähigkeiten erfordert, SOLLTE er den SMTPUTF8-Parameter NICHT mit dem MAIL-Befehl liefern.

Because there is no guarantee that a next-hop SMTP server will support the SMTPUTF8 extension, use of the SMTPUTF8 extension always carries a risk of transmission failure. In fact, during the early stages of deployment for the SMTPUTF8 extension, the risk will be quite high. Hence, there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments. Da es keine Garantie gibt, dass ein Next-Hop-SMTP-Server die SMTPUTF8-Erweiterung unterstützt, birgt die Verwendung der SMTPUTF8-Erweiterung immer ein Risiko eines Übertragungsfehlers. Tatsächlich wird das Risiko in den frühen Phasen der Bereitstellung der SMTPUTF8-Erweiterung recht hoch sein. Daher gibt es einen deutlichen kurzfristigen Vorteil für reine ASCII-Nachrichten, ohne Verwendung dieser Erweiterung gesendet zu werden. Der langfristige Vorteil der Umwandlung von ASCII [ASCII]-Zeichen (0x7f und darunter) in die UTF-8-Form besteht darin, dass sie reine Unicode-Umgebungen ermöglicht.

3.5. Non-ASCII Addresses and Reply-Codes​

An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. If the SMTP server does not support this option, then the SMTPUTF8-aware SMTP client has three choices according to Section 3.2 of this specification. Ein SMTPUTF8-fähiger SMTP-Client DARF KEINE internationalisierte Nachricht an einen SMTP-Server senden, der SMTPUTF8 nicht unterstützt. Wenn der SMTP-Server diese Option nicht unterstützt, hat der SMTPUTF8-fähige SMTP-Client drei Möglichkeiten gemäß Abschnitt 3.2 dieser Spezifikation.

The three-digit reply-codes used in this section are based on their meanings as defined in RFC 5321. Die in diesem Abschnitt verwendeten dreistelligen Antwortcodes basieren auf ihren Bedeutungen, wie in RFC 5321 definiert.

When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII addresses not permitted for that sender/recipient". Wenn Nachrichten abgelehnt werden, weil der RCPT-Befehl eine ASCII-Adresse erfordert, wird der Antwortcode 553 mit der Bedeutung "Mailbox-Name nicht erlaubt" zurückgegeben. Wenn Nachrichten abgelehnt werden, weil der MAIL-Befehl eine ASCII-Adresse erfordert, wird der Antwortcode 550 mit der Bedeutung "Mailbox nicht verfügbar" zurückgegeben. Wenn der SMTPUTF8-fähige SMTP-Server erweiterte E-Mail-Systemstatuscodes [RFC3463] unterstützt, wird der Antwortcode "X.6.7" [RFC5248] (siehe Abschnitt 4) verwendet, was "Nicht-ASCII-Adressen für diesen Absender/Empfänger nicht zulässig" bedeutet.

When messages are rejected for other reasons, the server follows the model of the base email specification in RFC 5321; this extension does not change those circumstances or reply messages. Wenn Nachrichten aus anderen Gründen abgelehnt werden, folgt der Server dem Modell der grundlegenden E-Mail-Spezifikation in RFC 5321; diese Erweiterung ändert diese Umstände oder Antwortnachrichten nicht.

If a message is rejected after the final "." of the DATA command because one or more recipients are unable to accept and process a message with internationalized email headers, the reply-code "554" is used with the meaning "Transaction failed". If the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this condition, meaning "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected". Wenn eine Nachricht nach dem abschließenden "." des DATA-Befehls abgelehnt wird, weil ein oder mehrere Empfänger nicht in der Lage sind, eine Nachricht mit internationalisierten E-Mail-Headern zu akzeptieren und zu verarbeiten, wird der Antwortcode "554" mit der Bedeutung "Transaktion fehlgeschlagen" verwendet. Wenn der SMTPUTF8-fähige SMTP-Server erweiterte E-Mail-Systemstatuscodes [RFC3463] unterstützt, wird der Antwortcode "X.6.9" [RFC5248] (siehe Abschnitt 4) verwendet, um diesen Zustand anzuzeigen, was bedeutet "UTF-8-Header-Nachricht kann nicht an einen oder mehrere Empfänger übertragen werden, daher muss die Nachricht abgelehnt werden".

The SMTPUTF8-aware SMTP servers are encouraged to detect that recipients cannot accept internationalized messages and generate an error after the RCPT command rather than waiting until after the DATA command to issue an error. Die SMTPUTF8-fähigen SMTP-Server werden ermutigt, zu erkennen, dass Empfänger keine internationalisierten Nachrichten akzeptieren können, und einen Fehler nach dem RCPT-Befehl zu generieren, anstatt bis nach dem DATA-Befehl zu warten, um einen Fehler auszugeben.

3.6. Body Parts and SMTP Extensions​

The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or the message being sent needs the SMTPUTF8 support. There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. An SMTPUTF8-aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME header fields [RFC2045] in the message body. However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message. Der MAIL-Befehlsparameter SMTPUTF8 bestätigt, dass eine Nachricht eine internationalisierte Nachricht ist oder dass die gesendete Nachricht die SMTPUTF8-Unterstützung benötigt. Es besteht immer noch die Möglichkeit, dass eine Nachricht, die über den MAIL-Befehl mit dem SMTPUTF8-Parameter gesendet wird, keine internationalisierte Nachricht ist. Ein SMTPUTF8-fähiger SMTP-Client oder -Server, der eine genaue Kenntnis darüber benötigt, ob eine Nachricht internationalisiert ist, muss alle Nachrichten-Header-Felder und MIME-Header-Felder [RFC2045] im Nachrichtenkörper parsen. Diese Spezifikation erfordert jedoch nicht, dass der SMTPUTF8-fähige SMTP-Client oder -Server die Nachricht inspiziert.

Although this specification requires that SMTPUTF8-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data, it does not require non-ASCII body parts in the MIME message as specified in RFC 2045. The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content): Obwohl diese Spezifikation erfordert, dass SMTPUTF8-fähige SMTP-Server die 8BITMIME-Erweiterung [RFC6152] unterstützen, um sicherzustellen, dass Server über eine angemessene Handhabungskapazität für 8-Bit-Daten verfügen, erfordert sie keine Nicht-ASCII-Körperteile in der MIME-Nachricht, wie in RFC 2045 spezifiziert. Die SMTPUTF8-Erweiterung KANN wie folgt verwendet werden (vorausgesetzt, dies ist angesichts des Körperinhalts angemessen):

  • with the BODY=8BITMIME parameter [RFC6152], or

  • mit dem BODY=8BITMIME-Parameter [RFC6152], oder

  • with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030].

  • mit dem BODY=BINARYMIME-Parameter, wenn der SMTP-Server BINARYMIME [RFC3030] ankündigt.

3.7. Additional ESMTP Changes and Clarifications​

The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that, when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string. When RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form. Die im E-Mail-Transportprozess übertragenen Informationen umfassen Adressen ("Mailboxen") und Domänennamen in verschiedenen Kontexten zusätzlich zu den MAIL- und RCPT-Befehlen und deren erweiterten Alternativen. Im Allgemeinen gilt die Regel, dass, wenn RFC 5321 eine Mailbox spezifiziert, diese SMTP-Erweiterung die Verwendung der UTF-8-Form für die gesamte Zeichenkette erfordert. Wenn RFC 5321 einen Domänennamen spezifiziert, SOLLTE der internationalisierte Domänenname in U-Label-Form vorliegen, wenn die SMTPUTF8-Erweiterung unterstützt wird; andernfalls SOLLTE er in A-Label-Form vorliegen.

The following subsections list and discuss all of the relevant cases. Die folgenden Unterabschnitte listen alle relevanten Fälle auf und diskutieren sie.

3.7.1. The Initial SMTP Exchange​

When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client cannot know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels. Wenn eine SMTP-Verbindung geöffnet wird, sendet der SMTP-Server eine "Begrüßungs"-Antwort, die aus dem Antwortcode 220 und einigen Informationen besteht. Der SMTP-Client sendet dann den EHLO-Befehl. Da der SMTP-Client nicht wissen kann, ob der SMTP-Server SMTPUTF8 unterstützt, bis er die Antwort auf das EHLO erhält, MUSS der SMTPUTF8-fähige SMTP-Client im EHLO-Befehl nur ASCII-Domänen (LDH-Label oder A-Label [RFC5890]) senden. Wenn der SMTPUTF8-fähige SMTP-Server Domänennamen in der EHLO-Antwort bereitstellt, MÜSSEN diese in Form von LDH-Labels oder A-Labels vorliegen.

3.7.2. Mail eXchangers​

If multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8 extension. Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues. Wenn mehrere DNS-MX-Einträge verwendet werden, um mehrere Server für eine Domäne zu spezifizieren (wie in Abschnitt 5 von RFC 5321 [RFC5321] beschrieben), wird dringend empfohlen, dass alle oder keiner von ihnen die SMTPUTF8-Erweiterung unterstützen SOLLTE. Andernfalls können unerwartete Ablehnungen während vorübergehender oder dauerhafter Ausfälle auftreten, die Benutzer als schwerwiegende Zuverlässigkeitsprobleme wahrnehmen könnten.

3.7.3. Trace Information​

The trace information <Return-path-line>, <Time-stamp-line>, and their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. This document updates <Mailbox> and <Domain> to support non-ASCII characters. When the SMTPUTF8 extension is used, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name that uses the U-label form. Also, the 'Stamp' clause of the Time-stamp-line may include an internationalized domain name that uses the U-label form. Die Trace-Informationen <Return-path-line>, <Time-stamp-line> und ihre zugehörigen Regeln sind in Abschnitt 4.4 von RFC 5321 [RFC5321] definiert. Dieses Dokument aktualisiert <Mailbox> und <Domain>, um Nicht-ASCII-Zeichen zu unterstützen. Wenn die SMTPUTF8-Erweiterung verwendet wird, kann die 'Reverse-path'-Klausel der Return-path-line einen internationalisierten Domänennamen enthalten, der die U-Label-Form verwendet. Außerdem kann die 'Stamp'-Klausel der Time-stamp-line einen internationalisierten Domänennamen enthalten, der die U-Label-Form verwendet.

If the messages that include trace fields are sent by an SMTPUTF8-aware SMTP client or relay server without the SMTPUTF8 parameter included in the MAIL commands, trace field values must conform to RFC 5321 regardless of the SMTP server's capability. Wenn die Nachrichten, die Trace-Felder enthalten, von einem SMTPUTF8-fähigen SMTP-Client oder Relay-Server gesendet werden, ohne dass der SMTPUTF8-Parameter in den MAIL-Befehlen enthalten ist, müssen die Trace-Feldwerte unabhängig von der Fähigkeit des SMTP-Servers RFC 5321 entsprechen.

When an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be transmitted with the SMTPUTF8 parameter included in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field. Wenn ein SMTPUTF8-fähiger SMTP-Server ein Trace-Feld zu einer Nachricht hinzufügt, die mit dem in den MAIL-Befehlen enthaltenen SMTPUTF8-Parameter übertragen wurde oder wird, SOLLTE dieser Server die U-Label-Form für internationalisierte Domänennamen im neuen Trace-Feld verwenden.

The protocol value of the 'WITH' clause when this extension is used is one of the SMTPUTF8 values specified in the "IANA Considerations" section of this document. Der Protokollwert der 'WITH'-Klausel, wenn diese Erweiterung verwendet wird, ist einer der SMTPUTF8-Werte, die im Abschnitt "IANA Considerations" dieses Dokuments spezifiziert sind.

3.7.4. UTF-8 Strings in Replies​

3.7.4.1. MAIL Command​

If an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them. If a given MAIL command does not include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain non-ASCII addresses. Wenn ein SMTP-Client dieser Spezifikation folgt und MAIL-Befehle sendet, die den SMTPUTF8-Parameter enthalten, darf der SMTPUTF8-fähige SMTP-Server UTF-8-Zeichen in der E-Mail-Adresse verwenden, die mit den Antwortcodes 251 und 551 verbunden ist, und der SMTP-Client MUSS in der Lage sein, diese zu akzeptieren und zu verarbeiten. Wenn ein bestimmter MAIL-Befehl den SMTPUTF8-Parameter nicht enthält, DARF der SMTPUTF8-fähige SMTP-Server KEINE 251- oder 551-Antwort zurückgeben, die eine Nicht-ASCII-Mailbox enthält. Stattdessen MUSS er solche Antworten in 250- oder 550-Antworten transformieren, die keine Nicht-ASCII-Adressen enthalten.

3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter​

If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN commands, it indicates that the SMTP client can accept UTF-8 strings in replies to those commands. The parameter with the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware SMTP server to use UTF-8 strings in mailbox names and full names that occur in replies, without concern that the SMTP client might be confused by them. An SMTP client that conforms to this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client does not specifically allow such replies by transmitting this parameter with the VRFY and EXPN commands. Wenn der SMTPUTF8-Parameter mit den VRFY- und EXPN-Befehlen übertragen wird, zeigt dies an, dass der SMTP-Client UTF-8-Zeichenketten in Antworten auf diese Befehle akzeptieren kann. Der Parameter mit den VRFY- und EXPN-Befehlen SOLLTE erst verwendet werden, nachdem der SMTP-Client die EHLO-Antwort mit dem SMTPUTF8-Schlüsselwort gesehen hat. Dies ermöglicht es einem SMTPUTF8-fähigen SMTP-Server, UTF-8-Zeichenketten in Mailbox-Namen und vollständigen Namen zu verwenden, die in Antworten vorkommen, ohne Bedenken, dass der SMTP-Client durch sie verwirrt werden könnte. Ein SMTP-Client, der dieser Spezifikation entspricht, MUSS Antworten auf die VRFY- und EXPN-Befehle, die UTF-8-Zeichenketten enthalten, akzeptieren und korrekt verarbeiten. Ein SMTPUTF8-fähiger SMTP-Server DARF jedoch KEINE UTF-8-Zeichenketten in Antworten verwenden, wenn der SMTP-Client solche Antworten nicht ausdrücklich durch Übertragung dieses Parameters mit den VRFY- und EXPN-Befehlen zulässt.

Most replies do not require that a mailbox name be included in the returned text, and therefore a UTF-8 string is not needed in them. Some replies, notably those resulting from successful execution of the VRFY and EXPN commands, do include the mailbox. Die meisten Antworten erfordern nicht, dass ein Mailbox-Name im zurückgegebenen Text enthalten ist, und daher ist eine UTF-8-Zeichenkette in ihnen nicht erforderlich. Einige Antworten, insbesondere solche, die aus der erfolgreichen Ausführung der VRFY- und EXPN-Befehle resultieren, enthalten die Mailbox.

VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: Die Syntaxen der Befehle VERIFY (VRFY) und EXPAND (EXPN) werden geändert zu:

vrfy = "VRFY" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

expn = "EXPN" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

The SMTPUTF8 parameter does not accept a value. If the reply to a VRFY or EXPN command requires a UTF-8 string, but the SMTP client did not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550. Reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". Reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code as specified below is used. Using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only. Der SMTPUTF8-Parameter akzeptiert keinen Wert. Wenn die Antwort auf einen VRFY- oder EXPN-Befehl eine UTF-8-Zeichenkette erfordert, der SMTP-Client jedoch den SMTPUTF8-Parameter nicht verwendet hat, MUSS der SMTPUTF8-fähige SMTP-Server entweder den Antwortcode 252 oder 550 verwenden. Der in RFC 5321 [RFC5321] definierte Antwortcode 252 bedeutet "Kann Benutzer nicht VRFYen, wird die Nachricht aber akzeptieren und die Zustellung versuchen". Der ebenfalls in RFC 5321 [RFC5321] definierte Antwortcode 550 bedeutet "Angeforderte Aktion nicht ausgeführt: Mailbox nicht verfügbar". Wenn der SMTPUTF8-fähige SMTP-Server erweiterte E-Mail-Systemstatuscodes [RFC3463] unterstützt, wird der unten spezifizierte erweiterte Antwortcode verwendet. Die Verwendung des SMTPUTF8-Parameters mit einem VRFY- oder EXPN-Befehl ermöglicht UTF-8-Antworten nur für diesen Befehl.

If a normal success response (i.e., 250) is returned, the response MAY include the full name of the user and MUST include the mailbox of the user. It MUST be in either of the following forms: Wenn eine normale Erfolgsantwort (d. h. 250) zurückgegeben wird, KANN die Antwort den vollständigen Namen des Benutzers enthalten und MUSS die Mailbox des Benutzers enthalten. Sie MUSS in einer der folgenden Formen vorliegen:

User Name <Mailbox>
 ; Mailbox is defined in Section 3.3 of this document.
 ; User Name can contain non-ASCII characters.

Mailbox
 ; Mailbox is defined in Section 3.3 of this document.

If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not allowed in the reply, and the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], the enhanced reply-code is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client". Wenn die SMTP-Antwort UTF-8-Zeichenketten erfordert, eine UTF-8-Zeichenkette in der Antwort jedoch nicht zulässig ist und der SMTPUTF8-fähige SMTP-Server erweiterte E-Mail-Systemstatuscodes [RFC3463] unterstützt, ist der erweiterte Antwortcode "X.6.8" [RFC5248] (siehe Abschnitt 4), was bedeutet "Eine Antwort, die eine UTF-8-Zeichenkette enthält, ist erforderlich, um den Mailbox-Namen anzuzeigen, aber diese Form der Antwort ist vom SMTP-Client nicht zulässig".

If the SMTP client does not support the SMTPUTF8 extension, but receives a UTF-8 string in a reply, it may not be able to properly report the reply to the user, and some clients might mishandle that reply. Internationalized messages in replies are only allowed in the commands under the situations described above. Wenn der SMTP-Client die SMTPUTF8-Erweiterung nicht unterstützt, aber eine UTF-8-Zeichenkette in einer Antwort erhält, kann er die Antwort möglicherweise nicht ordnungsgemäß an den Benutzer melden, und einige Clients könnten diese Antwort falsch behandeln. Internationalisierte Nachrichten in Antworten sind in den Befehlen nur in den oben beschriebenen Situationen zulässig.

Although UTF-8 strings are needed to represent email addresses in responses under the rules specified in this section, this extension does not permit the use of UTF-8 strings for any other purposes. SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies except in the limited cases specifically permitted in this section. Obwohl UTF-8-Zeichenketten benötigt werden, um E-Mail-Adressen in Antworten gemäß den in diesem Abschnitt spezifizierten Regeln darzustellen, erlaubt diese Erweiterung nicht die Verwendung von UTF-8-Zeichenketten für andere Zwecke. SMTPUTF8-fähige SMTP-Server DÜRFEN KEINE Nicht-ASCII-Zeichen in Antworten aufnehmen, außer in den begrenzten Fällen, die in diesem Abschnitt ausdrücklich zulässig sind.

4. IANA Considerations​

4.1. SMTP Service Extensions Registry​

IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, according to the following data: Die IANA hat einen neuen Wert "SMTPUTF8" zum Register "SMTP Service Extension" des Registers "Mail Parameters" hinzugefügt, gemäß den folgenden Daten:

KeywordsDescriptionReference
SMTPUTF8Internationalized email address[RFC6531]

4.2. SMTP Enhanced Status Code Registry​

The code definitions in this document replace those specified in RFC 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this document, and based on RFC 5248 [RFC5248]. IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data: Die Code-Definitionen in diesem Dokument ersetzen diejenigen, die in RFC 5336 spezifiziert sind, gemäß den Anweisungen in den Abschnitten 3.5 und 3.7.4.2 dieses Dokuments und basierend auf RFC 5248 [RFC5248]. Die IANA hat das "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" mit den folgenden Daten aktualisiert:

Code: X.6.7 Sample Text: Non-ASCII addresses not permitted for that sender/recipient Associated basic status code: 550, 553 Description: This indicates the reception of a MAIL or RCPT command that non-ASCII addresses are not permitted. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.8 Sample Text: UTF-8 string reply is required, but not permitted by the SMTP client Associated basic status code: 252, 550, 553 Description: This indicates that a reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.9 Sample Text: UTF-8 header message cannot be transferred to one or more recipients, so the message must be rejected Associated basic status code: 550 Description: This indicates that transaction failed after the final "." of the DATA command. Defined: RFC 6531 (Standards Track) Submitter: Jiankang YAO Change controller: [email protected]

Code: X.6.10 Description: This is a duplicate of X.6.8 and is thus deprecated.

4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry​

IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry. Die IANA hat die folgenden Einträge im Unterregister "WITH protocol types" unter dem Register "Mail Transmission Types" geändert oder hinzugefügt.

WITH protocol typesDescriptionReference
UTF8SMTPESMTP with SMTPUTF8[RFC6531]
UTF8SMTPAESMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8SMTPSESMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8SMTPSAESMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]
UTF8LMTPLMTP with SMTPUTF8[RFC6531]
UTF8LMTPALMTP with SMTPUTF8 and AUTH[RFC4954] [RFC6531]
UTF8LMTPSLMTP with SMTPUTF8 and STARTTLS[RFC3207] [RFC6531]
UTF8LMTPSALMTP with SMTPUTF8 and both STARTTLS and AUTH[RFC3207] [RFC4954] [RFC6531]

5. Security Considerations​

The extended security considerations discussion in the framework document [RFC6530] applies here. Die erweiterte Diskussion der Sicherheitsüberlegungen im Rahmenwerk-Dokument [RFC6530] gilt hier.

More security considerations are discussed below: Weitere Sicherheitsüberlegungen werden unten diskutiert:

Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other cases, in particular: Jenseits der Verwendung innerhalb des globalen E-Mail-Systems (in SMTP-Umschlägen und Nachrichten-Headern) werden internationalisierte E-Mail-Adressen auch in anderen Fällen auftauchen, insbesondere:

  • the logging systems of SMTP transactions and other logs to monitor the email systems;

  • die Protokollierungssysteme von SMTP-Transaktionen und andere Protokolle zur Überwachung der E-Mail-Systeme;

  • the trouble ticket systems used by security teams to manage security incidents, when an email address is involved;

  • die Trouble-Ticket-Systeme, die von Sicherheitsteams zur Verwaltung von Sicherheitsvorfällen verwendet werden, wenn eine E-Mail-Adresse beteiligt ist;

In order to avoid problems that could cause loss of data, this will likely require extending these systems to support full UTF-8, or require providing an adequate mechanism for mapping non-ASCII strings to ASCII. Um Probleme zu vermeiden, die zu Datenverlust führen könnten, wird dies wahrscheinlich eine Erweiterung dieser Systeme erfordern, um vollständiges UTF-8 zu unterstützen, oder die Bereitstellung eines angemessenen Mechanismus zum Abbilden von Nicht-ASCII-Zeichenketten auf ASCII erfordern.

Another security aspect to be considered is related to the ability by security team members to quickly understand, read, and identify email addresses from the logs, when they are tracking an incident. Mechanisms to automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that cannot easily read non-ASCII information. Ein weiterer zu berücksichtigender Sicherheitsaspekt bezieht sich auf die Fähigkeit von Mitgliedern des Sicherheitsteams, E-Mail-Adressen aus den Protokollen schnell zu verstehen, zu lesen und zu identifizieren, wenn sie einen Vorfall verfolgen. Mechanismen zur automatischen und schnellen Bereitstellung der Herkunft oder des Eigentums einer internationalisierten E-Mail-Adresse MÜSSEN implementiert werden, um von Protokollesern verwendet zu werden, die Nicht-ASCII-Informationen nicht leicht lesen können.

The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of use and possible behaviors. Implementation of internationalized addresses can also affect logs and actions by these tools. Die SMTP-Befehle VRFY und EXPN werden manchmal in SMTP-Transaktionen verwendet, bei denen keine Nachricht übertragen werden soll (von Tools, die verwendet werden, um automatisierte Aktionen zu ergreifen, falls potenzielle Spam-Nachrichten identifiziert werden). Die Abschnitte 3.5 und 7.3 von RFC 5321 geben detaillierte Beschreibungen der Verwendung und möglicher Verhaltensweisen. Die Implementierung von internationalisierten Adressen kann auch Protokolle und Aktionen dieser Tools beeinflussen.

6. Acknowledgements​

This document revises RFC 5336 [RFC5336] based on the result of the Email Address Internationalization (EAI) working group's discussion. Many EAI working group members did tests and implementations to move this document to the Standards Track. Significant comments and suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA, and other members of JET and were incorporated into the specification. Additional important comments and suggestions, and often specific text, were contributed by many members of the working group and design team. Those contributions include material from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars Eggert. Of course, none of the individuals are necessarily responsible for the combination of ideas represented here. Dieses Dokument überarbeitet RFC 5336 [RFC5336] basierend auf dem Ergebnis der Diskussion der Arbeitsgruppe Email Address Internationalization (EAI). Viele Mitglieder der EAI-Arbeitsgruppe führten Tests und Implementierungen durch, um dieses Dokument auf den Standards Track zu bringen. Signifikante Kommentare und Vorschläge wurden von Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA und anderen Mitgliedern von JET empfangen und in die Spezifikation aufgenommen. Zusätzliche wichtige Kommentare und Vorschläge sowie oft spezifischer Text wurden von vielen Mitgliedern der Arbeitsgruppe und des Designteams beigesteuert. Diese Beiträge umfassen Material von John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee und Lars Eggert. Natürlich ist keine der Einzelpersonen notwendigerweise für die Kombination der hier vertretenen Ideen verantwortlich.

Thanks a lot to Dave Crocker for his comments and helping with ABNF refinement. Vielen Dank an Dave Crocker für seine Kommentare und seine Hilfe bei der Verfeinerung der ABNF.

7. References​

7.1. Normative References​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.

  • [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.

  • [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5890] Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

7.2. Informative References​

  • [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.

  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

  • [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

Authors' Addresses

Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58813007 EMail: [email protected]

Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58812230 EMail: [email protected]

Letztes Update am