draft-ietf-eai-rfc5336bis-01.txt   draft-ietf-eai-rfc5336bis-02.txt 
Network Working Group J. Yao, Ed. Network Working Group Jiankang. Yao
Internet-Draft W. Mao, Ed. Internet-Draft Wei. Mao
Obsoletes: RFC5336 CNNIC Obsoletes: RFC5336 CNNIC
(if approved) August 11, 2010 (if approved) August 19, 2010
Updates: RFC5321 and 5322 Updates: RFC5321 and 5322
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 12, 2011 Expires: February 20, 2011
SMTP Extension for Internationalized Email Address SMTP Extension for Internationalized Email Address
draft-ietf-eai-rfc5336bis-01.txt draft-ietf-eai-rfc5336bis-02.txt
Abstract Abstract
This document specifies an SMTP extension for transport and delivery This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header of email messages with internationalized email addresses or header
information. Communication with systems that do not implement this information. Communication with systems that do not implement this
specification is specified in another document. This document specification is specified in another document. This document
updates some syntaxes and rules defined in RFC 5321 and RFC 5322. updates some syntaxes and rules defined in RFC 5321 and RFC 5322.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2011. This Internet-Draft will expire on February 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5
3.1. Framework for the Internationalization Extension . . . . . 5 3.1. Framework for the Internationalization Extension . . . . . 5
3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. UTF8 addresses and Response Codes . . . . . . . . . . . . 8 3.4. UTF8 addresses and Response Codes . . . . . . . . . . . . 8
3.5. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 8 3.5. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 8
3.6. Additional ESMTP Changes and Clarifications . . . . . . . 9 3.6. Additional ESMTP Changes and Clarifications . . . . . . . 9
3.6.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 9 3.6.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 9
3.6.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 3.6.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 9
3.6.3. Trace Information . . . . . . . . . . . . . . . . . . 10 3.6.3. Trace Information . . . . . . . . . . . . . . . . . . 10
3.6.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 3.6.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 15 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 15
7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 15 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 15
7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 15 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 15
7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Additional Material . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
A.1. Conventional Message and Internationalized Message . . . . 17
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 18
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
An internationalized email address includes two parts, the local part An internationalized email address includes two parts, the local part
and the domain part. The ways email addresses are used by protocols and the domain part. The ways email addresses are used by protocols
are different from the ways domain names are used. The most critical are different from the ways domain names are used. The most critical
difference is that emails are delivered through a chain of clients difference is that emails are delivered through a chain of clients
and servers, while domain names are resolved by name servers looking and servers, while domain names are resolved by name servers looking
up those names in their own tables. In addition to this, the Simple up those names in their own tables. In addition to this, the Simple
Mail Transfer Protocol [RFC5321] provides a negotiation mechanism Mail Transfer Protocol [RFC5321] provides a negotiation mechanism
skipping to change at page 4, line 41 skipping to change at page 4, line 41
This document specifies an element of the email internationalization This document specifies an element of the email internationalization
work, specifically the definition of an SMTP extension [RFC5321] for work, specifically the definition of an SMTP extension [RFC5321] for
internationalized email address transport delivery. internationalized email address transport delivery.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms "conventional message" and "internationalized message" are The terms "UTF-8 string" or "UTF-8 character" are used informally to
defined in an appendix to this specification. The terms "UTF-8 refer to Unicode characters encoded in UTF-8 [RFC3629]. All other
string" or "UTF-8 character" are used informally to refer to Unicode specialized terms used in this specification are defined in the
characters encoded in UTF-8 [RFC3629]. All other specialized terms framework document [RFC4952bis]or in the base Internet email
used in this specification are defined in the framework document or specifications [RFC5321] [RFC5322]. In particular, the terms "ASCII
in the base Internet email specifications [RFC5321] [RFC5322]. In address", "internationalized email address", "non-ASCII address",
particular, the terms "ASCII address", "internationalized email "i18mail address", "UTF8SMTPbis","conventional message",
address", "non-ASCII address", "i18mail address", "UTF8SMTPbis", "internationalized message", "message", and "mailing list" are used
"message", and "mailing list" are used in this document according to in this document according to the definitions in the framework
the definitions in the framework document. document [RFC4952bis].
This specification defines only those Augmented BNF (ABNF) [RFC5234] This specification defines only those Augmented BNF (ABNF) [RFC5234]
syntax rules that are different from those of the base email syntax rules that are different from those of the base email
specifications [RFC5321][RFC5322] and, where the earlier rules are specifications [RFC5321][RFC5322] and, where the earlier rules are
upgraded or extended, gives them new names. When the new rule is a upgraded or extended, gives them new names. When the new rule is a
small modification to the older one, it is typically given a name small modification to the older one, it is typically given a name
starting with "u". Rules that are undefined here may be found in the starting with "u". Rules that are undefined here may be found in the
base email specifications under the same names. base email specifications under the same names.
2. Overview of Operation 2. Overview of Operation
skipping to change at page 6, line 38 skipping to change at page 6, line 38
in [RFC5890]. Any domain names that are to be compared to local in [RFC5890]. Any domain names that are to be compared to local
strings SHOULD be checked for validity and then MUST be compared as strings SHOULD be checked for validity and then MUST be compared as
specified in section 3 of [RFC5891]. specified in section 3 of [RFC5891].
An SMTP client that receives the UTF8SMTPbis extension keyword in An SMTP client that receives the UTF8SMTPbis extension keyword in
response to the EHLO command MAY transmit mailbox names within SMTP response to the EHLO command MAY transmit mailbox names within SMTP
commands as internationalized strings in UTF-8 form. It MAY send a commands as internationalized strings in UTF-8 form. It MAY send a
UTF-8 header [RFC5335bis] (which may also include mailbox names in UTF-8 header [RFC5335bis] (which may also include mailbox names in
UTF-8). It MAY transmit the domain parts of mailbox names within UTF-8). It MAY transmit the domain parts of mailbox names within
SMTP commands or the message header as either ACE (ASCII Compatible SMTP commands or the message header as either ACE (ASCII Compatible
Encoding) labels (as specified in IDNA [RFC5890]) or UTF-8 strings. Encoding) labels (as specified in IDNA definitions [RFC5890]) or
All labels in domain parts of mailbox names which are IDNs (either UTF-8 strings. All labels in domain parts of mailbox names which are
UTF-8 or ACE strings) MUST be valid. If the original client submits IDNs (either UTF-8 or ACE strings) MUST be valid. If the original
a message to a Message Submission Server ("MSA") [RFC4409], it is the client submits a message to a Message Submission Server ("MSA")
responsibility of the MSA that all domain labels are valid; [RFC4409], it is the responsibility of the MSA that all domain labels
otherwise, it is the original client's responsibility. The presence are valid; otherwise, it is the original client's responsibility.
of the UTF8SMTPbis extension does not change the requirement of RFC The presence of the UTF8SMTPbis extension does not change the
5321 that servers relaying mail MUST NOT attempt to parse, evaluate, requirement of RFC 5321 that servers relaying mail MUST NOT attempt
or transform the local part in any way. to parse, evaluate, or transform the local part in any way.
If the UTF8SMTPbis SMTP extension is not offered by the Server, the If the UTF8SMTPbis SMTP extension is not offered by the Server, the
SMTP client MUST NOT transmit an internationalized address and MUST SMTP client MUST NOT transmit an internationalized address and MUST
NOT transmit a mail message containing internationalized mail headers NOT transmit a mail message containing internationalized mail headers
as described in [RFC5335bis] at any level within its MIME structure. as described in [RFC5335bis] at any level within its MIME structure.
(For this paragraph, the internationalized domain name in the form of (For this paragraph, the internationalized domain name in the form of
ACE labels as specified in IDNA [RFC5890] is not considered as ACE labels as specified in IDNA definitions [RFC5890] is not
"internationalized".) Instead, if an SMTP client (SMTP sender) considered as "internationalized".) Instead, if an SMTP client (SMTP
attempts to transfer an internationalized message and encounters a sender) attempts to transfer an internationalized message and
server that does not support the extension, it MUST make one of the encounters a server that does not support the extension, it MUST make
following three choices: one of the following three choices:
1. If and only if the SMTP client (sender) is a Message Submission 1. If and only if the SMTP client (sender) is a Message Submission
Server ("MSA") [RFC4409], it MAY, consistent with the general Server ("MSA") [RFC4409], it MAY, consistent with the general
provisions for changes by such servers, rewrite the envelope, provisions for changes by such servers, rewrite the envelope,
headers, or message material to make them entirely ASCII and headers, or message material to make them entirely ASCII and
consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322 consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322
[RFC5322]. [RFC5322].
2. It may either reject the message during the SMTP transaction or 2. It may either reject the message during the SMTP transaction or
accept the message and then generate and transmit a notification accept the message and then generate and transmit a notification
of non-deliverability. Such notification MUST be done as of non-deliverability. Such notification MUST be done as
specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI
delivery status notification (DSN) specification [RFC5337bis]. delivery status notification (DSN) specification [RFC5337bis].
3. It may find an alternate route to the destination that permits 3. It may find an alternate route to the destination that permits
UTF8SMTPbis. That route may be discovered by trying alternate UTF8SMTPbis. That route may be discovered by trying alternate
Mail eXchanger (MX) hosts (using preference rules as specified in Mail eXchanger (MX) hosts (using preference rules as specified in
RFC 5321) or using other means available to the SMTP-sender. RFC 5321) or using other means available to the SMTP-sender.
If a server advertises UTF8SMTP and the client does not recognize the This document applies only when an UTF8SMTPbis-aware client is trying
extension, the client may send a regular message [RFC5321] and to send an internationalized message to a server which requires the
[RFC5322]. In this case, the client may continue to use the UTF8SMTPbis extensions to handle it. For all other cases, and for
[RFC5890] to transform the domain portion of an address to A-label addresses and messages that do not require an UTF8SMTPbis extension,
[RFC5890]. If the email address is in the format of ASCII@non-ASCII, SMTP clients and servers are expected to behave exactly as specified
the legacy SMTP servers MUST reject the message with the in [RFC5321].
ASCII@non-ASCII if the non-ASCII domain part is not transformed into
the format of A-label by the client. UTF8SMTPbis servers MUST A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321]
recognize and decode the ACE label(s) as appropriate. and [RFC5322] MAY convert the ASCII@non-ASCII addresse into the
format of ASCII@A-label [RFC5890] if the email address is in the
format of ASCII@non-ASCII.
3.3. Extended Mailbox Address Syntax 3.3. Extended Mailbox Address Syntax
RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in
terms of ASCII characters, using the production for a mailbox and terms of ASCII characters, using the production for a mailbox and
those productions on which it depends. those productions on which it depends.
The key changes made by this specification are, informally, to The key changes made by this specification are, informally, to
o Change the definition of "sub-domain" to permit either the o Change the definition of "Domain" to permit either the definition
definition above or a UTF-8 string representing a DNS label that above or a UTF-8 string representing a DNS label that is
is conformant with IDNA [RFC5890]. conformant with IDNA definitions [RFC5890].
o Change the definition of "Atom" to permit either the definition o Change the definition of "Local-part" to permit either the
above or a UTF-8 string. That string MUST NOT contain any of the definition above or a UTF-8 string. That string MUST NOT contain
ASCII characters (either graphics or controls) that are not any of the ASCII characters (either graphics or controls) that are
permitted in "atext"; it is otherwise unrestricted. not permitted in "atext"; it is otherwise unrestricted.
According to the description above, the syntax of an According to the description above, the syntax of an
internationalized email mailbox name (address) is defined in ABNF internationalized email mailbox name (address) is defined in ABNF
[RFC5234] as follows. [RFC5234] as follows.
uMailbox = uLocal-part "@" uDomain uMailbox = uLocal-part "@" uDomain
; uLocal-part and uDomain defined ; uLocal-part and uDomain defined
; in RFC 5335bis, Section 4. ; in RFC 5335bis, Section 4.
The value of "uDomain" SHOULD be verified by IDNA [RFC5890]. If that The value of "uDomain" SHOULD be verified by IDNA definitions
verification fails, the email address with that uDomain MUST NOT be [RFC5890]. If that verification fails, the email address with that
regarded as a valid email address. uDomain MUST NOT be regarded as a valid email address.
3.4. UTF8 addresses and Response Codes 3.4. UTF8 addresses and Response Codes
An "internationalized message" as defined in the appendix of this An "internationalized message" as defined in the appendix of this
specification MUST NOT be sent to an SMTP server that does not specification MUST NOT be sent to an SMTP server that does not
support UTF8SMTPbis. Such a message should be rejected by a server support UTF8SMTPbis. Such a message should be rejected by a server
if it lacks the support of UTF8SMTPbis. if it lacks the support of UTF8SMTPbis.
The three-digit reply codes used in this section are consistent with The three-digit reply codes used in this section are consistent with
their meanings as defined in RFC 5321. their meanings as defined in RFC 5321.
skipping to change at page 9, line 14 skipping to change at page 9, line 15
capability for 8-bit data and to avoid a number of complex encoding capability for 8-bit data and to avoid a number of complex encoding
problems, the use of internationalized addresses obviously does not problems, the use of internationalized addresses obviously does not
require non-ASCII body parts in the MIME message. The UTF8SMTPbis require non-ASCII body parts in the MIME message. The UTF8SMTPbis
extension MAY be used with the BODY=8BITMIME parameter if that is extension MAY be used with the BODY=8BITMIME parameter if that is
appropriate given the body content or, with the BODY=BINARYMIME appropriate given the body content or, with the BODY=BINARYMIME
parameter, if the server advertises BINARYMIME [RFC3030] and that is parameter, if the server advertises BINARYMIME [RFC3030] and that is
appropriate. appropriate.
Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and
receives at least one non-ASCII address, the precise interpretation receives at least one non-ASCII address, the precise interpretation
of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the of "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is:
MAIL command is: 1. If a BODY=8BITMIME parameter is present, the header contains
1. If there is no BODY parameter, the header contains UTF-8
characters, but all the body parts are in ASCII (possibly as the
result of a content-transfer-encoding).
2. If a BODY=8BITMIME parameter is present, the header contains
UTF-8 characters, and some or all of the body parts contain 8-bit UTF-8 characters, and some or all of the body parts contain 8-bit
line-oriented data. line-oriented data.
3. If a BODY=BINARYMIME parameter is present, the header contains 2. If a BODY=BINARYMIME parameter is present, the header contains
UTF-8 characters, and some or all body parts contain binary data UTF-8 characters, and some or all body parts contain binary data
without restriction as to line lengths or delimiters. without restriction as to line lengths or delimiters.
3.6. Additional ESMTP Changes and Clarifications 3.6. Additional ESMTP Changes and Clarifications
The information carried in the mail transport process involves The information carried in the mail transport process involves
addresses ("mailboxes") and domain names in various contexts in addresses ("mailboxes") and domain names in various contexts in
addition to the MAIL and RCPT commands and extended alternatives to addition to the MAIL and RCPT commands and extended alternatives to
them. In general, the rule is that, when RFC 5321 specifies a them. In general, the rule is that, when RFC 5321 specifies a
mailbox, this specification expects UTF-8 to be used for the entire mailbox, this specification expects UTF-8 to be used for the entire
skipping to change at page 15, line 7 skipping to change at page 14, line 40
| | STARTTLS and SMTP AUTH | [RFCXXXX] | | | STARTTLS and SMTP AUTH | [RFCXXXX] |
+---------------+-----------------------------+---------------------+ +---------------+-----------------------------+---------------------+
5. Security Considerations 5. Security Considerations
See the extended security considerations discussion in the framework See the extended security considerations discussion in the framework
document [RFC4952bis]. document [RFC4952bis].
6. Acknowledgements 6. Acknowledgements
Much of the text in the initial version of this specification was This document revises the [RFC5336]document based on the EAI WG's
derived or copied from [Emailaddr] with the permission of the author. discussion result. Many EAI WG members do some tests and
implementations to move this document to the Standard Track document.
Significant comments and suggestions were received from Xiaodong LEE, Significant comments and suggestions were received from Xiaodong LEE,
Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET
team and were incorporated into the specification. Additional team and were incorporated into the specification. Additional
important comments and suggestions, and often specific text, were important comments and suggestions, and often specific text, were
contributed by many members of the WG and design team. Those contributed by many members of the WG and design team. Those
contributions include material from John C Klensin, Charles Lindsey, contributions include material from John C Klensin, Charles Lindsey,
Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman,
Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens,
Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok
Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund,
skipping to change at page 15, line 38 skipping to change at page 15, line 25
Applied errata suggested by Alfred Hoenes. Applied errata suggested by Alfred Hoenes.
7.2. draft-ietf-eai-rfc5336bis: Version 00 7.2. draft-ietf-eai-rfc5336bis: Version 00
Applied the changes suggested by the EAI new charter. Applied the changes suggested by the EAI new charter.
7.3. draft-ietf-eai-rfc5336bis: Version 01 7.3. draft-ietf-eai-rfc5336bis: Version 01
Applied the changes suggested by 78 IETF EAI meeting. Applied the changes suggested by 78 IETF EAI meeting.
7.4. draft-ietf-eai-rfc5336bis: Version 02
remove the appendix since rfc4952bis has added this material
improve the text
remove the text about no body parameter
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] American National Standards Institute (formerly United [ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. Information Interchange", ANSI X3.4-1968, 1968.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
skipping to change at page 16, line 25 skipping to change at page 16, line 21
January 2003. January 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", RFC 3629, November 2003.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006. RFC 4409, April 2006.
[RFC4952bis] [RFC4952bis]
Klensin, J. and Y. Ko, "Overview and Framework for Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007. Internationalized Email", RFC 4952, July 2010.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", RFC 5248, June 2008. Mail System Status Codes", RFC 5248, June 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5335bis] [RFC5335bis]
Abel, Y., Ed., "Internationalized Email Headers", Abel, Y., Ed., "Internationalized Email Headers",
RFC 5335, August 2008. RFC 5335, August 2010.
[RFC5337bis] [RFC5337bis]
Newman, C. and A. Melnikov, Ed., "Internationalized Newman, C. and A. Melnikov, Ed., "Internationalized
Delivery Status and Disposition Notifications", RFC 5337, Delivery Status and Disposition Notifications", RFC 5337,
August 2008. August 2008.
[RFC5890] Klensin, J., "Internationalizing Domain Names in [RFC5890] Klensin, J., "Internationalizing Domain Names in
Applications (IDNA)", RFC 5890, June 2010. Applications (IDNA definitions)", RFC 5890, June 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
8.2. Informative References 8.2. Informative References
[Emailaddr]
Klensin, J., "Internationalization of Email Addresses",
draft-klensin-emailaddr-i18n-03 (work in progress),
July 2005.
[RFC0974] Partridge, C., "Mail routing and the domain system", [RFC0974] Partridge, C., "Mail routing and the domain system",
RFC 974, January 1986. RFC 974, January 1986.
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996. October 1996.
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", RFC 3030, of Large and Binary MIME Messages", RFC 3030,
December 2000. December 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007. for Authentication", RFC 4954, July 2007.
Appendix A. Additional Material [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008.
A.1. Conventional Message and Internationalized Message
o A conventional message is one that does not use any extension
defined in this document or in the UTF-8 header specification
[RFC5335bis], and which is strictly conformant to RFC 5322
[RFC5322].
o An internationalized message is a message utilizing one or more of
the extensions defined in this specification or in the UTF-8
header specification [RFC5335bis], so that it is no longer
conformant to the RFC 5322 specification of a message.
A.2. LMTP
LMTP [RFC2033] may be used as the final delivery agent. In such
cases, LMTP may be arranged to deliver the mail to the mail store.
The mail store may not have UTF8SMTPbis capability. LMTP needs to be
updated to deal with these situations.
A.3. SMTP Service Extension for DSNs
The existing Draft Standard regarding delivery status notifications
(DSNs) [RFC3461] is limited to ASCII text in the machine readable
portions of the protocol. "International Delivery and Disposition
Notifications" [RFC5337bis] adds a new address type for international
email addresses so an original recipient address with non-ASCII
characters can be correctly preserved even after downgrading. If an
SMTP server advertises both the UTF8SMTPbis and the DSN extension,
that server MUST implement EAI DSN [RFC5337bis] including support for
the ORCPT parameter.
A.4. Implementation Advice
In the absence of this extension, SMTP clients and servers are
constrained to using only those addresses permitted by RFC 5321. The
local parts of those addresses MAY be made up of any ASCII
characters, although some of them MUST be quoted as specified there.
It is notable in an internationalization context that there is a long
history on some systems of using overstruck ASCII characters (a
character, a backspace, and another character) within a quoted string
to approximate non-ASCII characters. This form of
internationalization SHOULD be phased out as this extension becomes
widely deployed, but backward-compatibility considerations require
that it continue to be supported.
Authors' Addresses Authors' Addresses
Jiankang YAO (editor) Jiankang YAO
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing Beijing
Phone: +86 10 58813007 Phone: +86 10 58813007
Email: yaojk@cnnic.cn Email: yaojk@cnnic.cn
Wei MAO (editor) Wei MAO
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing Beijing
Phone: +86 10 58812230 Phone: +86 10 58812230
Email: maowei_ietf@cnnic.cn Email: maowei_ietf@cnnic.cn
 End of changes. 27 change blocks. 
122 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/