3. Protokoll auf Mail-Transportebene

3.1. Rahmen für die Internationalisierungserweiterung

Die folgende Diensterweiterung wird definiert:

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

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

3. 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.

4. 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.

5. 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.

6. 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.

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

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

9. 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.

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

11. 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. Die SMTPUTF8-Erweiterung

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.

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.

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:

• 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.

• 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.

• 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.

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.

Wenn ein SMTPUTF8-fähiger SMTP-Server die Delivery Status Notification (DSN) [RFC3461]-Erweiterung ankündigt, MUSS er RFC 6533 [RFC6533] implementieren.

3.3. Erweiterte Mailbox-Adresssyntax

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.

Die wichtigsten Änderungen, die durch diese Spezifikation vorgenommen wurden, umfassen:

• 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.

• 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.

• 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.

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>

Die folgende ABNF-Regel wird direkt aus RFC 6532, Abschnitt 3.1, importiert:

• <UTF8-non-ascii>

Die folgende ABNF-Regel wird direkt aus RFC 5234, Anhang B.1, importiert:

• <DQUOTE>

Die folgende ABNF-Regel wird direkt aus RFC 5890, Abschnitt 2.3.2.1, importiert:

• <U-label>

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. Verwendung der MAIL-Kommando-Parameter

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.

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. Nicht-ASCII-Adressen und Antwortcodes

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.

Die in diesem Abschnitt verwendeten dreistelligen Antwortcodes basieren auf ihren Bedeutungen, wie in RFC 5321 definiert.

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.

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.

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".

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 und SMTP-Erweiterungen

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.

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):

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

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

3.7. Zusätzliche ESMTP-Änderungen und Klarstellungen

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.

Die folgenden Unterabschnitte listen alle relevanten Fälle auf und diskutieren sie.

3.7.1. Der anfängliche SMTP-Austausch

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 eXchanger (MX)

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-Informationen

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.

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.

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.

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-Zeichenketten in Antworten

3.7.4.1. MAIL-Kommando

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- und EXPN-Kommandos und der SMTPUTF8-Parameter

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.

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.

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

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.

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.

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".

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.

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.