draft-ietf-eai-rfc5336bis-14.txt   draft-ietf-eai-rfc5336bis-15.txt 
Network Working Group J. Yao Network Working Group J. Yao
Internet-Draft W. Mao Internet-Draft W. Mao
Obsoletes: 5336 (if approved) CNNIC Obsoletes: 5336 (if approved) CNNIC
Intended status: Standards Track October 6, 2011 Intended status: Standards Track October 27, 2011
Expires: April 8, 2012 Expires: April 29, 2012
SMTP Extension for Internationalized Email SMTP Extension for Internationalized Email
draft-ietf-eai-rfc5336bis-14.txt draft-ietf-eai-rfc5336bis-15.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. information. This specification replaces RFC 5336.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 8, 2012. This Internet-Draft will expire on April 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Updates to Other Specifications . . . . . . . . . . . . . 5 1.2. Changes Made to Other Specifications . . . . . . . . . . . 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. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9
3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13
4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 14
4.3. WITH protocol types sub-registry of the Mail
Transmission Types Registry . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 17 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 17
7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17
7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17
7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17
7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17
7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17
7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 18
7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 18
7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 18
7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 18
7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18
7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18
7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18 7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18
7.14. draft-ietf-eai-rfc5336bis: Version 12 . . . . . . . . . . 18 7.14. draft-ietf-eai-rfc5336bis: Version 12 . . . . . . . . . . 19
7.15. draft-ietf-eai-rfc5336bis: Version 13 . . . . . . . . . . 18 7.15. draft-ietf-eai-rfc5336bis: Version 13 . . . . . . . . . . 19
7.16. draft-ietf-eai-rfc5336bis: Version 14 . . . . . . . . . . 18 7.16. draft-ietf-eai-rfc5336bis: Version 14 . . . . . . . . . . 19
7.17. draft-ietf-eai-rfc5336bis: Version 15 . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The document defines a Simple Mail Transfer Protocol [RFC5321] The document defines a Simple Mail Transfer Protocol [RFC5321]
extension so servers can advertise the ability to accept and process extension so servers can advertise the ability to accept and process
internationalized email addresses (see section 1.1), and internationalized email addresses (see section 1.1), and
internationalized email headers [RFC5335bis]. internationalized email headers [RFC5335bis].
An extended overview of the extension model for internationalized An extended overview of the extension model for internationalized
email addresses and the email header appears in [RFC4952bis], email addresses and the email header appears in [RFC4952bis],
referred to as "the framework document" in this specification. A referred to as "the framework document" in this specification. A
thorough understanding of the information in that document and in the thorough understanding of the information in that document and in the
base Internet email specifications [RFC5321] [RFC5322] is necessary base Internet email specifications [RFC5321] [RFC5322] is necessary
to understand and implement this specification. to understand and implement this specification.
[[anchor1: Note in Draft and to RFC Editor: The keyword represented [[anchor1: Note in Draft and to RFC Editor: The keyword represented
in this document by "UTF8SMTPbis" (and in the XML source in this document by "UTF8SMTPbis" (and in the XML source by
byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned "UTF8SMTPbis") is a placeholder. The actual keyword will need to be
when the standards track SMTP extension in this series [RFC5336bis- assigned after document approval by a process to be worked out
SMTP] is approved for publication and should be substituted here. between the responsible AD, WG co-chairs, and IANA. The assigned
This paragraph should be treated as normative reference to that SMTP keyword should be substituted here. This paragraph should be removed
extension draft, creating a reference hold until it is approved by before RFC publication.]]
the IESG. This paragraph should be removed before RFC publication.]]
1.1. Terminology 1.1. 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 "UTF-8 string" or "UTF-8 character" are used to refer to The terms "UTF-8 string" or "UTF-8 character" are used to refer to
Unicode characters encoded in UTF-8. All other specialized terms Unicode characters encoded in UTF-8. All other specialized terms
used in this specification are defined in the framework document or used in this specification are defined in the framework document or
skipping to change at page 5, line 5 skipping to change at page 4, line 49
are used in this document according to the definitions in the are used in this document according to the definitions in the
framework document. framework document.
Non-ASCII characters or strings referred in this document MUST be Non-ASCII characters or strings referred in this document MUST be
expressed in UTF-8, a standard Unicode Encoding Form. expressed in UTF-8, a standard Unicode Encoding Form.
This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some
basic rules in this document can be found from [RFC5234] or [RFC5321] basic rules in this document can be found from [RFC5234] or [RFC5321]
under the same names. under the same names.
1.2. Updates to Other Specifications 1.2. Changes Made to Other Specifications
This specification extends some syntax rules defined in RFC 5321 and This specification extends some syntax rules defined in RFC 5321 and
permits internationalized email addresses in the envelope, but it permits internationalized email addresses in the envelope, but it
does not modify RFC 5321. It permits data formats defined in does not modify RFC 5321. It permits data formats defined in
[RFC5335bis], but it does not modify RFC 5322. It does require that [RFC5335bis], but it does not modify RFC 5322. It does require that
the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis- the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis-
aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis- aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis-
aware SMTP client, but it does not modify the 8BITMIME specification aware SMTP client, but it does not modify the 8BITMIME specification
in any way. in any way.
This specification replaces an earlier, experimental, approach to the This specification replaces an earlier, experimental, approach to the
same problem [RFC5336]. same problem [RFC5336]. Section 6 of [RFC4952bis] describes the
changes in approach between this specification and [RFC5336]. The
changes between them are significant after the experimental
experience. Readers need to review both documents carefully to
change implementation from the experimental specification to this
standard specification.
2. Overview of Operation 2. Overview of Operation
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 for work, specifically the definition of an SMTP extension for
internationalized email. The extension is identified with the token internationalized email. The extension is identified with the token
"UTF8SMTPbis". "UTF8SMTPbis".
The internationalized email headers specification [RFC5335bis] The internationalized email headers specification [RFC5335bis]
provides the details of email header features enabled by this provides the details of email header features enabled by this
skipping to change at page 6, line 24 skipping to change at page 6, line 25
characters in UTF-8 encoding in replies from the VRFY and EXPN characters in UTF-8 encoding in replies from the VRFY and EXPN
commands. commands.
7. No additional SMTP verbs are defined by this extension. 7. No additional SMTP verbs are defined by this extension.
8. Servers offering this extension MUST provide support for, and 8. Servers offering this extension MUST provide support for, and
announce, the 8BITMIME extension [RFC6152]. announce, the 8BITMIME extension [RFC6152].
9. The reverse-path and forward-path of the SMTP MAIL and RCPT 9. The reverse-path and forward-path of the SMTP MAIL and RCPT
commands are extended to allow Unicode characters encoded in commands are extended to allow Unicode characters encoded in
UTF-8 in mailbox names (addresses). UTF-8 in mailbox names (addresses).
10. The mail message body is extended as specified in [RFC5335bis]. 10. The mail message body is extended as specified in [RFC5335bis].
11. The UTF8SMTPbis extension is valid on the submission port 11. The UTF8SMTPbis extension is valid on the submission port
[RFC4409], and can be used with LMTP [RFC2033]. [RFC4409]. It may also be used with LMTP [RFC2033]. When these
protocols are used, their use should be reflected in trace field
WITH keywords as appropriate [RFC3848].
3.2. The UTF8SMTPbis Extension 3.2. The UTF8SMTPbis Extension
An SMTP server that announces this UTF8SMTPbis extension MUST be An SMTP server that announces this UTF8SMTPbis extension MUST be
prepared to accept a UTF-8 string [RFC3629] in any position in which prepared to accept a UTF-8 string [RFC3629] in any position in which
RFC 5321 specifies that a <mailbox> can appear. Although the RFC 5321 specifies that a <mailbox> can appear. Although the
characters in the <local-part> are permitted to contain non-ASCII characters in the <local-part> are permitted to contain non-ASCII
characters, actual parsing of the <local-part>, and the delimiters characters, actual parsing of the <local-part>, and the delimiters
used, are unchanged from the base email specification [RFC5321]. Any used, are unchanged from the base email specification [RFC5321]. Any
domain name to be looked up in the DNS MUST allow for [RFC5890] domain name to be looked up in the DNS MUST follow RFC 5890
behavior. When doing lookups, the UTF8SMTPbis-aware SMTP client or [RFC5890]. When doing lookups, the UTF8SMTPbis-aware SMTP client or
server MUST either use a Unicode aware DNS library, or transform the server MUST either use a Unicode aware DNS library, or transform the
internationalized domain name to the form of A-label as described in internationalized domain name to the form of A-label as described in
[RFC5890]. [RFC5890].
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 A-labels or U-labels SMTP commands or the message header as A-labels or U-labels
[RFC5890]. The presence of the UTF8SMTPbis extension does not change [RFC5890]. The presence of the UTF8SMTPbis extension does not change
RFC 5321 server relaying behaviors. RFC 5321 server relaying behaviors.
If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
the UTF8SMTPbis-aware SMTP client MUST NOT transmit an the UTF8SMTPbis-aware SMTP client MUST NOT transmit an
internationalized email address and MUST NOT transmit a mail message internationalized email address and MUST NOT transmit a mail message
containing internationalized mail headers as described in containing internationalized mail headers as described in
[RFC5335bis] at any level within its MIME structure [RFC2045] and [RFC5335bis] at any level within its MIME structure [RFC2045]. (For
[RFC2047]. (For this paragraph, the internationalized domain name in this paragraph, the internationalized domain name in the form of
the form of A-labels as specified in IDNA definitions [RFC5890] is A-labels as specified in IDNA definitions [RFC5890] is not considered
not considered to be "internationalized".) Instead, if a to be "internationalized".) Instead, if a UTF8SMTPbis-aware SMTP
UTF8SMTPbis-aware SMTP client (UTF8SMTPbis-aware SMTP sender) client (UTF8SMTPbis-aware SMTP sender) attempts to transfer an
attempts to transfer an internationalized message and encounters an internationalized message and encounters an SMTP server that does not
SMTP server that does not support the extension, it MUST make one of support the extension, it MUST make one of the following three
the following three choices and the priority order is 1, 2 and 3. choices and the priority order is 1, 2 and 3.
1. It MAY either reject the message during the SMTP transaction or 1. 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 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the
internationalized delivery status and disposition notifications internationalized delivery status and disposition notifications
specification [RFC5337bis]. specification [RFC5337bis].
2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a 2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a
Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may
choose its own way to deal with this scenario according to the choose its own way to deal with this scenario according to the
skipping to change at page 9, line 26 skipping to change at page 9, line 29
support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension
always carries a risk of transmission failure. In fact, during the always carries a risk of transmission failure. In fact, during the
early stages of deployment for the UTF8SMTPbis extension, the risk early stages of deployment for the UTF8SMTPbis extension, the risk
will be quite high. Hence there is a distinct near-term advantage will be quite high. Hence there is a distinct near-term advantage
for ASCII-only messages to be sent without using this extension. The for ASCII-only messages to be sent without using this extension. The
long-term advantage of casting ASCII [ASCII] characters(0x7f and long-term advantage of casting ASCII [ASCII] characters(0x7f and
below) as UTF-8 form is that it permits pure-Unicode environments. below) as UTF-8 form is that it permits pure-Unicode environments.
3.5. Non-ASCII addresses and Reply-codes 3.5. Non-ASCII addresses and Reply-codes
A UTF8SMTPbis-aware SMTP client MUST only send an internationalized A UTF8SMTPbis-aware SMTP client MUST NOT send an internationalized
message to an SMTP server that supports UTF8SMTPbis. If the SMTP message to an SMTP server that does not support UTF8SMTPbis. If the
server does not support this option, then the UTF8SMTPbis-aware SMTP SMTP server does not support this option, then the UTF8SMTPbis-aware
client has three choices according to section 3.2 of this SMTP client has three choices according to section 3.2 of this
specification. specification.
The three-digit Reply-codes used in this section are based on their The three-digit Reply-codes used in this section are based on their
meanings as defined in RFC 5321. meanings as defined in RFC 5321.
When messages are rejected because the RCPT command requires an ASCII When messages are rejected because the RCPT command requires an ASCII
address, the reply-code 553 is returned with the meaning "mailbox address, the reply-code 553 is returned with the meaning "mailbox
name not allowed". When messages are rejected because the MAIL name not allowed". When messages are rejected because the MAIL
command requires an ASCII address, the reply-code 550 is returned command requires an ASCII address, the reply-code 550 is returned
with the meaning "mailbox unavailable". When the UTF8SMTPbis-aware with the meaning "mailbox unavailable". When the UTF8SMTPbis-aware
skipping to change at page 10, line 17 skipping to change at page 10, line 20
The UTF8SMTPbis-aware SMTP servers are encouraged to detect that The UTF8SMTPbis-aware SMTP servers are encouraged to detect that
recipients can not accept internationalized messages and generate an recipients can not accept internationalized messages and generate an
error after the RCPT command rather than waiting until after the DATA error after the RCPT command rather than waiting until after the DATA
command to issue an error. command to issue an error.
3.6. Body Parts and SMTP Extensions 3.6. Body Parts and SMTP Extensions
The MAIL command parameter UTF8SMTPbis asserts that a message is an The MAIL command parameter UTF8SMTPbis asserts that a message is an
internationalized message or the message being sent needs the internationalized message or the message being sent needs the
UTF8SMTPbis support. The message being sent via the MAIL command UTF8SMTPbis support. There is still a chance that a message being
with the UTF8SMTPbis parameter has still a chance of that the message sent via the MAIL command with the UTF8SMTPbis parameter is not an
transmitted is not an internationalized message. A UTF8SMTPbis-aware internationalized message. A UTF8SMTPbis-aware SMTP client or server
SMTP client or server that requires accurate knowledge of whether a that requires accurate knowledge of whether a message is
message is internationalized needs to parse all message header fields internationalized needs to parse all message header fields and MIME
and MIME header fields [RFC2045] and [RFC2047] in the message body. header fields [RFC2045] in the message body. However, this
However, this specification does not require that the UTF8SMTPbis- specification does not require that the UTF8SMTPbis-aware SMTP client
aware SMTP client or server inspects the message. or server inspects the message.
While this specification requires that UTF8SMTPbis-aware SMTP servers Although this specification requires that UTF8SMTPbis-aware SMTP
support the 8BITMIME extension [RFC6152] to ensure that servers have servers support the 8BITMIME extension [RFC6152] to ensure that
adequate handling capability for 8-bit data and to avoid a number of servers have adequate handling capability for 8-bit data, it does not
complex encoding problems, the use of internationalized email require non-ASCII body parts in the MIME message in RFC 2045. The
addresses obviously does not require non-ASCII body parts in the MIME UTF8SMTPbis extension MAY be used with the BODY=8BITMIME parameter
message in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be [RFC6152] if that is appropriate given the body content or, with the
used with the BODY=8BITMIME parameter [RFC6152] if that is BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME
appropriate given the body content or, with the BODY=BINARYMIME [RFC3030] and that is appropriate.
parameter, if the SMTP server advertises BINARYMIME [RFC3030] and
that is appropriate.
3.7. Additional ESMTP Changes and Clarifications 3.7. 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 SMTP extension requires UTF-8 form to be used for the mailbox, this SMTP extension requires UTF-8 form to be used for the
entire string. When RFC 5321 specifies a domain name, the entire string. When RFC 5321 specifies a domain name, the
internationalized domain name SHOULD be in the form of U-label if the internationalized domain name SHOULD be in the form of U-label if the
skipping to change at page 13, line 47 skipping to change at page 13, line 47
Although UTF-8 form is needed to represent email addresses in Although UTF-8 form is needed to represent email addresses in
responses under the rules specified in this section, this extension responses under the rules specified in this section, this extension
does not permit the use of UTF-8 string for any other purposes. does not permit the use of UTF-8 string for any other purposes.
UTF8SMTPbis-aware SMTP servers MUST NOT include non-ASCII characters UTF8SMTPbis-aware SMTP servers MUST NOT include non-ASCII characters
in replies except in the limited cases specifically permitted in this in replies except in the limited cases specifically permitted in this
section. section.
4. IANA Considerations 4. IANA Considerations
4.1. SMTP Service Extensions Registry
IANA is requested to add a new value "UTF8SMTPbis" to the SMTP IANA is requested to add a new value "UTF8SMTPbis" to the SMTP
Service Extension subregistry of the Mail Parameters registry, Service Extension Registry of the Mail Parameters registry, according
according to the following data: to the following data:
+-------------+---------------------------------+-----------+ +-------------+---------------------------------+-----------+
| Keywords | Description | Reference | | Keywords | Description | Reference |
+-------------+---------------------------------+-----------+ +-------------+---------------------------------+-----------+
| UTF8SMTPbis | Internationalized email address | [RFCXXXX] | | UTF8SMTPbis | Internationalized email address | [RFCXXXX] |
+-------------+---------------------------------+-----------+ +-------------+---------------------------------+-----------+
This document updates the values to the SMTP Enhanced Status Code 4.2. SMTP Enhanced Status Code Registry
subregistry of the Mail Parameters registry, following the guidance
in Sections 3.5 and 3.7.4.2 of this document, and being based on The new code definitions in this document replace those that now
[RFC5248]. The registration data is as follows: appear in the SMTP Enhanced Status Code subregistry of the Mail
Parameters registry, following the guidance in Sections 3.5 and
3.7.4.2 of this document, and being based on [RFC5248]. The
registration data is as follows:
Code: X.6.7 Code: X.6.7
Sample Text: non-ASCII addresses not permitted Sample Text: non-ASCII addresses not permitted
for that sender/recipient for that sender/recipient
Associated basic status code: 550, 553 Associated basic status code: 550, 553
Description: This indicates the reception of a MAIL or RCPT Description: This indicates the reception of a MAIL or RCPT
command that non-ASCII addresses are not permitted command that non-ASCII addresses are not permitted
Defined: RFC XXXX (Standard track) Defined: RFC XXXX (Standard track)
Submitter: Jiankang YAO Submitter: Jiankang YAO
Change controller: ima@ietf.org Change controller: ima@ietf.org
skipping to change at page 15, line 4 skipping to change at page 15, line 14
Code: X.6.9 Code: X.6.9
Sample Text: UTF-8 header message can not be transferred Sample Text: UTF-8 header message can not be transferred
to one or more recipient so the message to one or more recipient so the message
must be rejected must be rejected
Associated basic status code: 550 Associated basic status code: 550
Description: This indicates that transaction failed Description: This indicates that transaction failed
after the final "." of the DATA command. after the final "." of the DATA command.
Defined: RFC XXXX (Standard track) Defined: RFC XXXX (Standard track)
Submitter: Jiankang YAO Submitter: Jiankang YAO
Change controller: ima@ietf.org Change controller: ima@ietf.org
Code: X.6.10 Code: X.6.10
Description: This is a duplicate of X.6.8 and Description: This is a duplicate of X.6.8 and
is thus deprecated. is thus deprecated.
The following entries SHOULD be updated or added in the "Mail 4.3. WITH protocol types sub-registry of the Mail Transmission Types
Registry
IANA is requested to update or add the following entries in the "Mail
Transmission Types" registry under the Mail Parameters registry. Transmission Types" registry under the Mail Parameters registry.
+--------------+-------------------------------+--------------------+ +-------------+---------------------------------+-------------------+
| WITH | Description | Reference | | WITH | Description | Reference |
| protocol | | | | protocol | | |
| types | | | | types | | |
+--------------+-------------------------------+--------------------+ +-------------+---------------------------------+-------------------+
| UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | | UTF8SMTP | ESMTP with UTF8SMTPbis | [RFCXXXX] |
| UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | | UTF8SMTPA | ESMTP with UTF8SMTPbis and SMTP | [RFC4954] |
| | AUTH | [RFCXXXX] | | | AUTH | [RFCXXXX] |
| UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | | UTF8SMTPS | ESMTP with UTF8SMTPbis and | [RFC3207] |
| | STARTTLS | [RFCXXXX] | | | STARTTLS | [RFCXXXX] |
| UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | | UTF8SMTPSA | ESMTP with UTF8SMTPbis and both | [RFC3207] |
| | STARTTLS and SMTP AUTH | [RFC4954] | | | STARTTLS and SMTP AUTH | [RFC4954] |
| | | [RFCXXXX] | | | | [RFCXXXX] |
| UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | | UTF8LMTP | LMTP with UTF8SMTPbis | [RFCXXXX] |
| UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | | UTF8LMTPA | LMTP with UTF8SMTPbis and SMTP | [RFC4954] |
| | AUTH | [RFCXXXX] | | | AUTH | [RFCXXXX] |
| UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | | UTF8LMTPS | LMTP with UTF8SMTPbis and | [RFC3207] |
| | STARTTLS | [RFCXXXX] | | | STARTTLS | [RFCXXXX] |
| UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | | UTF8LMTPSA | LMTP with UTF8SMTPbis and both | [RFC3207] |
| | STARTTLS and LMTP AUTH | [RFC4954] | | | STARTTLS and LMTP AUTH | [RFC4954] |
| | | [RFCXXXX] | | | | [RFCXXXX] |
+--------------+-------------------------------+--------------------+ +-------------+---------------------------------+-------------------+
5. Security Considerations 5. Security Considerations
The extended security considerations discussion in the framework The extended security considerations discussion in the framework
document [RFC4952bis] will apply here. document [RFC4952bis] will apply here.
More security considerations are discussed below: More security considerations are discussed below:
Beyond the use inside the email global system (in SMTP envelopes and Beyond the use inside the email global system (in SMTP envelopes and
message headers), internationalized email addresses will also show up message headers), internationalized email addresses will also show up
skipping to change at page 16, line 48 skipping to change at page 17, line 18
Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes,
Miguel Garcia, Magnus Westerlund, Joseph Yee and Lars Eggert. Of Miguel Garcia, Magnus Westerlund, Joseph Yee and Lars Eggert. Of
course, none of the individuals are necessarily responsible for the course, none of the individuals are necessarily responsible for the
combination of ideas represented here. combination of ideas represented here.
Thanks a lot to Dave Crocker for his comments and helping of ABNF Thanks a lot to Dave Crocker for his comments and helping of ABNF
refinement. refinement.
7. Change History 7. Change History
[[anchor12: RFC Editor: Please remove this section.]] [[anchor15: RFC Editor: Please remove this section.]]
7.1. draft-yao-eai-rfc5336bis: Version 00 7.1. draft-yao-eai-rfc5336bis: Version 00
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
skipping to change at page 18, line 47 skipping to change at page 19, line 21
7.15. draft-ietf-eai-rfc5336bis: Version 13 7.15. draft-ietf-eai-rfc5336bis: Version 13
Update the esmpt-value syntax according to Chris Newman's comments Update the esmpt-value syntax according to Chris Newman's comments
improve the texts improve the texts
7.16. draft-ietf-eai-rfc5336bis: Version 14 7.16. draft-ietf-eai-rfc5336bis: Version 14
improve the texts improve the texts
7.17. draft-ietf-eai-rfc5336bis: Version 15
improve the texts
updates based on IESG members' comments
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.
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003. RFC 3461, January 2003.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003. RFC 3463, January 2003.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
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.
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, July 2004.
[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", I-D rfc4952bis, September 2010. Internationalized Email", I-D rfc4952bis, September 2011.
[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.
skipping to change at page 20, line 19 skipping to change at page 20, line 45
[RFC5890] Klensin, J., "Internationalizing Domain Names in [RFC5890] Klensin, J., "Internationalizing Domain Names in
Applications (IDNA definitions)", RFC 5890, June 2010. Applications (IDNA definitions)", RFC 5890, June 2010.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
Service Extension for 8-bit MIME Transport", STD 71, Service Extension for 8-bit MIME Transport", STD 71,
RFC 6152, March 2011. RFC 6152, March 2011.
8.2. Informative References 8.2. Informative References
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 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.
 End of changes. 33 change blocks. 
96 lines changed or deleted 120 lines changed or added

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