doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6531.txt b/doc/rfc/rfc6531.txt
new file mode 100644
index 0000000..ff3f324
--- /dev/null
+++ b/doc/rfc/rfc6531.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            J. Yao
+Request for Comments: 6531                                        W. Mao
+Obsoletes: 5336                                                    CNNIC
+Category: Standards Track                                  February 2012
+ISSN: 2070-1721
+
+
+               SMTP Extension for Internationalized Email
+
+Abstract
+
+   This document specifies an SMTP extension for transport and delivery
+   of email messages with internationalized email addresses or header
+   information.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+   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
+
+
+
+Yao & Mao                    Standards Track                    [Page 1]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Changes Made to Other Specifications . . . . . . . . . . .  3
+   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
+   3.  Mail Transport-Level Protocol  . . . . . . . . . . . . . . . .  4
+     3.1.  Framework for the Internationalization Extension . . . . .  4
+     3.2.  The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . .  5
+     3.3.  Extended Mailbox Address Syntax  . . . . . . . . . . . . .  7
+     3.4.  MAIL Command Parameter Usage . . . . . . . . . . . . . . .  8
+     3.5.  Non-ASCII Addresses and Reply-Codes  . . . . . . . . . . .  9
+     3.6.  Body Parts and SMTP Extensions . . . . . . . . . . . . . .  9
+     3.7.  Additional ESMTP Changes and Clarifications  . . . . . . . 10
+       3.7.1.  The Initial SMTP Exchange  . . . . . . . . . . . . . . 10
+       3.7.2.  Mail eXchangers  . . . . . . . . . . . . . . . . . . . 10
+       3.7.3.  Trace Information  . . . . . . . . . . . . . . . . . . 11
+       3.7.4.  UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+     4.1.  SMTP Service Extensions Registry . . . . . . . . . . . . . 13
+     4.2.  SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
+     4.3.  WITH Protocol Types Sub-Registry of the Mail
+           Transmission Types Registry  . . . . . . . . . . . . . . . 15
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 2]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+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].
+
+   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.
+
+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].
+
+   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].
+
+   Strings referred to in this document, including ASCII strings, MUST
+   be expressed in UTF-8.
+
+   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].
+
+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.
+
+
+
+Yao & Mao                    Standards Track                    [Page 3]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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.
+
+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".
+
+   The internationalized email headers specification [RFC6532] provides
+   the details of email header features enabled by this extension.
+
+3.  Mail Transport-Level Protocol
+
+3.1.  Framework for the Internationalization Extension
+
+   The following service extension is defined:
+
+   1.   The name of the SMTP service extension is "Internationalized
+        Email".
+
+   2.   The EHLO keyword value associated with this extension is
+        "SMTPUTF8".
+
+   3.   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.
+
+   4.   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.
+
+
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 4]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   5.   The maximum length of a MAIL command line is increased by 10
+        characters to accommodate the possible addition of the SMTPUTF8
+        parameter.
+
+   6.   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.
+
+   7.   No additional SMTP verbs are defined by this extension.
+
+   8.   Servers offering this extension MUST provide support for, and
+        announce, the 8BITMIME extension [RFC6152].
+
+   9.   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).
+
+   10.  The mail message body is extended as specified in RFC 6532
+        [RFC6532].
+
+   11.  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].
+
+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].
+
+   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
+
+
+
+Yao & Mao                    Standards Track                    [Page 5]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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.
+
+   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:
+
+   o  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.
+
+   o  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].
+
+   o  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.
+
+   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].
+
+
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 6]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   If an SMTPUTF8-aware SMTP server advertises the Delivery Status
+   Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533
+   [RFC6533].
+
+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.
+
+   The key changes made by this specification include:
+
+   o  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.
+
+   o  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].
+
+   o  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.
+
+   The following ABNF rules imported from RFC 5321, Section 4.1.2, are
+   updated directly or indirectly by this document:
+
+   o  <Mailbox>
+
+   o  <Local-part>
+
+   o  <Dot-string>
+
+   o  <Quoted-string>
+
+   o  <QcontentSMTP>
+
+   o  <Domain>
+
+   o  <Atom>
+
+   The following ABNF rule will be imported from RFC 6532, Section 3.1,
+   directly:
+
+   o  <UTF8-non-ascii>
+
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 7]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   The following ABNF rule will be imported from RFC 5234, Appendix B.1,
+   directly:
+
+   o  <DQUOTE>
+
+   The following ABNF rule will be imported from RFC 5890, Section
+   2.3.2.1, directly:
+
+   o  <U-label>
+
+   The following rules are extended in ABNF [RFC5234] as follows.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 8]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+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.
+
+   The three-digit reply-codes used in this section are based on their
+   meanings as defined in RFC 5321.
+
+   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".
+
+   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.
+
+   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".
+
+   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.
+
+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
+
+
+
+
+Yao & Mao                    Standards Track                    [Page 9]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   header fields [RFC2045] in the message body.  However, this
+   specification does not require that the SMTPUTF8-aware SMTP client or
+   server inspects the message.
+
+   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):
+
+   -  with the BODY=8BITMIME parameter [RFC6152], or
+
+   -  with the BODY=BINARYMIME parameter, if the SMTP server advertises
+      BINARYMIME [RFC3030].
+
+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.
+
+   The following subsections list and discuss all of the relevant cases.
+
+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.
+
+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
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 10]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   extension.  Otherwise, unexpected rejections can happen during
+   temporary or permanent failures, which users might perceive as
+   serious reliability issues.
+
+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.
+
+   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.
+
+   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.
+
+   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.
+
+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.
+
+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
+
+
+
+Yao & Mao                    Standards Track                   [Page 11]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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.
+
+   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.
+
+   VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
+
+   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.
+
+   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:
+
+   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.
+
+
+
+Yao & Mao                    Standards Track                   [Page 12]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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".
+
+   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.
+
+   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.
+
+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:
+
+        +----------+---------------------------------+-----------+
+        | Keywords | Description                     | Reference |
+        +----------+---------------------------------+-----------+
+        | SMTPUTF8 | Internationalized 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:
+
+
+
+
+
+
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 13]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+    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: ima@ietf.org
+
+
+    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: ima@ietf.org
+
+
+    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: ima@ietf.org
+
+
+    Code:        X.6.10
+    Description: This is a duplicate of X.6.8 and is thus deprecated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 14]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+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.
+
+   +--------------+------------------------------+---------------------+
+   | WITH         | Description                  | Reference           |
+   | protocol     |                              |                     |
+   | types        |                              |                     |
+   +--------------+------------------------------+---------------------+
+   | UTF8SMTP     | ESMTP with SMTPUTF8          | [RFC6531]           |
+   | UTF8SMTPA    | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
+   | UTF8SMTPS    | ESMTP with SMTPUTF8 and      | [RFC3207] [RFC6531] |
+   |              | STARTTLS                     |                     |
+   | UTF8SMTPSA   | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
+   |              | STARTTLS and AUTH            | [RFC6531]           |
+   | UTF8LMTP     | LMTP with SMTPUTF8           | [RFC6531]           |
+   | UTF8LMTPA    | LMTP with SMTPUTF8 and AUTH  | [RFC4954] [RFC6531] |
+   | UTF8LMTPS    | LMTP with SMTPUTF8 and       | [RFC3207] [RFC6531] |
+   |              | STARTTLS                     |                     |
+   | UTF8LMTPSA   | LMTP with SMTPUTF8 and both  | [RFC3207] [RFC4954] |
+   |              | STARTTLS and AUTH            | [RFC6531]           |
+   +--------------+------------------------------+---------------------+
+
+5.  Security Considerations
+
+   The extended security considerations discussion in the framework
+   document [RFC6530] applies here.
+
+   More security considerations are discussed below:
+
+   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:
+
+   o  the logging systems of SMTP transactions and other logs to monitor
+      the email systems;
+
+   o  the trouble ticket systems used by security teams to manage
+      security incidents, when an email address is involved;
+
+   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.
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 15]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   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.
+
+   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.
+
+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.
+
+   Thanks a lot to Dave Crocker for his comments and helping with ABNF
+   refinement.
+
+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.
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 16]
+
+RFC 6531               SMTP Extension for SMTPUTF8         February 2012
+
+
+   [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.
+
+
+
+Yao & Mao                    Standards Track                   [Page 17]
+
+RFC 6531               SMTP Extension for SMTPUTF8         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: yaojk@cnnic.cn
+
+
+   Wei MAO
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   China
+
+   Phone: +86 10 58812230
+   EMail: maowei_ietf@cnnic.cn
+
+
+
+
+
+
+Yao & Mao                    Standards Track                   [Page 18]
+