draft-ietf-eai-rfc5336bis-09.txt   draft-ietf-eai-rfc5336bis-10.txt 
Network Working Group J. Yao Network Working Group J. Yao
Internet-Draft W. Mao Internet-Draft W. Mao
Obsoletes: RFC5336 (if approved) CNNIC Obsoletes: RFC5336 (if approved) CNNIC
Updates: RFC5321 and 5322 April 11, 2011 Updates: RFC5321 and 5322 June 2, 2011
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 13, 2011 Expires: December 4, 2011
SMTP Extension for Internationalized Email Address SMTP Extension for Internationalized Email Address
draft-ietf-eai-rfc5336bis-09.txt draft-ietf-eai-rfc5336bis-10.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.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 October 13, 2011. This Internet-Draft will expire on December 4, 2011.
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 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Updates to Other Specifications . . . . . . . . . . . . . 5 1.3. Updates to Other Specifications . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . 10 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9
3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 10 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 14 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 18 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16
7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 19 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 16
7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 19 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17
7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 19 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17
7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 19 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17
7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 19 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17
7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 19 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17
7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 19 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17
7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 19 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17
7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 19 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17
7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 20 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Simple Mail Transfer Protocol [RFC5321] provides a negotiation The Simple Mail Transfer Protocol [RFC5321] provides a negotiation
mechanism about service extension by which SMTP clients can discover mechanism about service extension by which SMTP clients can discover
SMTP server capabilities and make decisions for further processing. SMTP server capabilities and make decisions for further processing.
This document uses this mechanism and specifies an SMTP extension to This document uses this mechanism and specifies an SMTP extension to
permit internationalized email addresses (see Section 1.2) in the permit internationalized email addresses (see section 1.2) in the
SMTP envelope, and Unicode characters encoded in UTF-8 [RFC3629] in SMTP envelope, and Unicode characters encoded in UTF-8 [RFC3629] in
the headers. An extended overview of the extension model for the headers. An extended overview of the extension model for
internationalized email addresses and the email header appears in internationalized email addresses and the email header appears in
[RFC4952bis], referred to as "the framework document" or just as [RFC4952bis], referred to as "the framework document" or just as
"framework" elsewhere in this specification. "framework" elsewhere in 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
byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned
when the standards track SMTP extension in this series [RFC5336bis- when the standards track SMTP extension in this series [RFC5336bis-
skipping to change at page 5, line 8 skipping to change at page 5, line 8
used in this specification are defined in the framework document or used in this specification are defined in the framework document or
in the base Internet email specifications. In particular, the terms in the base Internet email specifications. In particular, the terms
"ASCII address", "internationalized email address", "non-ASCII "ASCII address", "internationalized email address", "non-ASCII
address", "UTF8SMTPbis", "internationalized message", and "message" address", "UTF8SMTPbis", "internationalized message", and "message"
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], with This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some
some modifications. The modified rules are defined in this basic rules in this document can be found from [RFC5234] or [RFC5321]
specification. When a new rule has a name starting with "u", it is a or [RFC5322] under the same names.
small modification to an older rule. Rules that are undefined here
can be found from [RFC5234] or [RFC5321] or [RFC5322] under the same
names.
1.3. Updates to Other Specifications 1.3. Updates to Other Specifications
This specification modifies RFC 5321 by permitting internationalized This specification modifies RFC 5321 by permitting internationalized
email address in the envelope. It also updates some syntax rules email address in the envelope. It also updates some syntax rules
defined in RFC 5321. It modifies RFC 5322 by permitting data formats defined in RFC 5321. It modifies RFC 5322 by permitting data formats
defined in [RFC5335bis]. It does not modify the 8BITMIME defined in [RFC5335bis]. It does not modify the 8BITMIME
specification [RFC6152] in any way, but it does require that the specification [RFC6152] in any way, but it does require that the
8BITMIME extension be announced by the EAI-aware SMTP server and used 8BITMIME extension be announced by the EAI-aware SMTP server and used
with "BODY=8BMITMIME" by the SMTP client. with "BODY=8BMITMIME" by the EAI-aware SMTP client.
2. Overview of Operation 2. Overview of Operation
This specification describes an optional extension to the email This specification describes an optional extension to the email
transport mechanism that permits non-ASCII characters in both the transport mechanism that permits non-ASCII characters in both the
envelope and header fields of messages, which are encoded in UTF-8. envelope and header fields of messages, which are encoded in UTF-8.
The extension is identified with the token "UTF8SMTPbis". The extension is identified with the token "UTF8SMTPbis".
The EAI UTF-8 header specification [RFC5335bis] provides the details The EAI UTF-8 header specification [RFC5335bis] provides the details
of email header features enabled by this extension of email header features enabled by this extension
skipping to change at page 6, line 40 skipping to change at page 6, line 40
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 names to be looked up in the DNS MUST allow for [RFC5890] domain names to be looked up in the DNS MUST allow for [RFC5890]
behavior. When doing lookups, the EAI-aware SMTP server MUST either behavior. When doing lookups, the EAI-aware SMTP client or server
use a Unicode aware DNS library, or transform it to A-label defined MUST either use a Unicode aware DNS library, or transform it to
in [RFC5890]. A-label defined in [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.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
and encounters an SMTP server that does not support the extension, it and encounters an SMTP server that does not support the extension, it
MUST make one of the following three choices and the priority order MUST make one of the following three choices and the priority order
is 1, 2 and 3. 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 EAI specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI
delivery status notification (DSN) specification [RFC5337bis]. delivery status notification (DSN) specification [RFC5337bis].
2. If and only if the EAI-aware SMTP client (sender) is a Message 2. If and only if the EAI-aware SMTP client (sender) is a Message
Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the Submission Agent ("MSA") [RFC4409] [RFC5598], MSA may choose its
envelope, headers, or message material to make them entirely own way to deal with this scenario according to the provisions of
ASCII [ASCII] and consistent with the provisions of RFC 5321 [RFC4409] or its future versions. But the detailed specification
[RFC5321] and RFC 5322 [RFC5322]. of this process and its results is outside the scope of this
document.
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 EAI-aware SMTP RFC 5321) or using other means available to the EAI-aware SMTP
client. client.
This document applies only when an EAI-aware SMTP client is trying to This document applies only when an EAI-aware SMTP client is trying to
send an internationalized message to an EAI-aware SMTP server. For send an internationalized message to an EAI-aware SMTP server. For
all other cases, and for addresses and messages that do not require all other cases, and for addresses and messages that do not require
an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do not an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do not
change the behavior specified in [RFC5321]. change the behavior specified in [RFC5321].
An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and
[RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the [RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the
format of ASCII@A-label [RFC5890] if the email address is in the format of ASCII@A-label [RFC5890] if the email address is in the
format of ASCII@U-label. format of ASCII@U-label.
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 RFC 5321, section 4.1.2, defines the syntax of a <Mailbox> entirely
in terms of ASCII characters. in terms of ASCII characters. This document will make <Mailbox> to
support non-ASCII characters.
The key changes made by this specification include: The key changes made by this specification include:
o Change the definition of <Domain> to permit both the RFC 5321 o In order to update the <Mailbox> to support the internationalized
definition and a UTF-8 string representing a DNS label that is email address, the <Mailbox> ABNF rule will be importted from RFC
conforming with IDNA definitions [RFC5890]. 5321 directly, and other related rules are importted from RFC
o Change the definition of <Local-part> to permit both the RFC 5321 5321, RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this
document.
o Extend the definition of <sub-domain> to permit both the RFC 5321
definition and a UTF-8 string in a DNS label that is conforming
with IDNA definitions [RFC5890].
o Extend the definition of <atext> to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII characters (either graphics or controls) that are not of the ASCII graphics or controls characters.
permitted in <atext>; it is otherwise unrestricted.
According to the description above, the syntax of an
internationalized email mailbox name (address) is defined in ABNF
[RFC5234] as follows.
uMailbox = uLocal-part "@" ( uDomain / address-literal )
; Replace Mailbox in RFC 5321, Section 4.1.2
address-literal = <Defined in Section 4.1.2 of RFC 5321>
uLocal-part = uDot-string / uQuoted-string
; MAY be case-sensitive
; Replace Local-part in RFC 5321, Section 4.1.2
uDot-string = uAtom *("." uAtom)
; Replace Dot-string in RFC 5321, Section 4.1.2
uAtom = 1*ucharacter
; Replace Atom in RFC 5321, Section 4.1.2
ucharacter = atext / UTF8-non-ascii
atext = <Defined in Section 3.2.3 of RFC 5322>
; Same definition with atext in RFC 5321, Section 4.1.2
uQuoted-string = DQUOTE *uQcontentSMTP DQUOTE
; Replace Quoted-string in RFC 5321, Section 4.1.2
DQUOTE = <Defined in appendix B.1 of RFC 5234>
uQcontentSMTP = qtextSMTP / quoted-pairSMTP / UTF8-non-ascii The following ABNF rules will be importted from RFC 5321, section
4.1.2 directly:
o <Mailbox>
o <Local-part>
o <Dot-string>
o <Quoted-string>
o <QcontentSMTP>
o <Domain>
o <Atom>
qtextSMTP = <Defined in Section 4.1.2 of RFC 5321> The following ABNF rule will be importted from RFC 5335bis, section
4.1 directly:
o <UTF8-non-ascii>
quoted-pairSMTP = <Defined in Section 4.1.2 of RFC 5321> The following ABNF rule will be importted from RFC 5234, appendix B.1
directly:
o <DQUOTE>
uDomain = sub-udomain *("." sub-udomain) The following ABNF rule will be importted from RFC 5890, section
; Replace Domain in RFC 5321, Section 4.1.2 2.3.2.1 directly:
o <U-label>
sub-udomain = uLet-dig [uLdh-str] The following rules are extended in ABNF [RFC5234] as follows.
; Replace sub-domain in RFC 5321, Section 4.1.2
; Note that uDomain may not be resolvable if sub-udomain is not a
; valid U-Label or LDH Label as defined in RFC 5890
uLet-dig = Let-dig / UTF8-non-ascii sub-domain =/ U-label
; extend the defintion of sub-domain in RFC5321, section 4.1.2
Let-dig = <Defined in Section 4.1.2 of RFC 5321> atext =/ UTF8-non-ascii
; extend the defintion of atext in RFC5321, section 4.1.2
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig quoted-pairSMTP =/ %d92 UTF8-non-ascii
; Replace Ldh-str in RFC 5321, Section 4.1.2 ; extend the defintion of quoted-pairSMTP in RFC5321, section 4.1.2
UTF8-non-ascii = <Defined in Section 4.1 of RFC5335bis> qtextSMTP =/ UTF8-non-ascii
; extend the defintion of qtextSMTP in RFC5321, section 4.1.2
3.4. MAIL Command Parameter Usage 3.4. MAIL Command Parameter Usage
If the envelope or message being sent requires the capabilities of If the envelope or message being sent requires the capabilities of
the UTF8SMTPbis extension, the SMTP client MUST supply the the UTF8SMTPbis extension, the EAI-aware SMTP client MUST supply the
UTF8SMTPbis parameter with the MAIL command. If this parameter is UTF8SMTPbis parameter with the MAIL command. If this parameter is
provided, it MUST have no value. If the SMTP client is aware that provided, it MUST have no value. If the EAI-aware SMTP client is
neither the envelope nor the message being sent requires any of the aware that neither the envelope nor the message being sent requires
UTF8SMTPbis extension capabilities, it SHOULD NOT supply the any of the UTF8SMTPbis extension capabilities, it SHOULD NOT supply
UTF8SMTPbis parameter with the MAIL command. the UTF8SMTPbis parameter with the MAIL command.
Because there is no guarantee that a next-hop SMTP server will Because there is no guarantee that a next-hop SMTP server will
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.
skipping to change at page 11, line 20 skipping to change at page 10, line 20
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. The message being sent via the MAIL command
with the UTF8SMTPbis parameter has still a chance of that the message with the UTF8SMTPbis parameter has still a chance of that the message
transmitted is not an internationalized message. An EAI-aware SMTP transmitted is not an internationalized message. An EAI-aware SMTP
client or server that requires accurate knowledge of whether a client or server that requires accurate knowledge of whether a
message is internationalized needs to parse all message header fields message is internationalized needs to parse all message header fields
and MIME header fields [RFC2045] and [RFC2047] in the message body. and MIME header fields [RFC2045] and [RFC2047] in the message body.
However, this specification does not require that the SMTP client or However, this specification does not require that the EAI-aware SMTP
server inspects the message. client or server inspects the message.
While this specification requires that EAI-aware SMTP servers support While this specification requires that EAI-aware SMTP servers support
the 8BITMIME extension [RFC6152] to ensure that servers have adequate the 8BITMIME extension [RFC6152] to ensure that servers have adequate
handling capability for 8-bit data and to avoid a number of complex handling capability for 8-bit data and to avoid a number of complex
encoding problems, the use of internationalized email addresses encoding problems, the use of internationalized email addresses
obviously does not require non-ASCII body parts in the MIME message obviously does not require non-ASCII body parts in the MIME message
in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with
the BODY=8BITMIME parameter [RFC6152] if that is appropriate given the BODY=8BITMIME parameter [RFC6152] if that is appropriate given
the body content or, with the BODY=BINARYMIME parameter, if the SMTP the body content or, with the BODY=BINARYMIME parameter, if the SMTP
server advertises BINARYMIME [RFC3030] and that is appropriate. server advertises BINARYMIME [RFC3030] and that is appropriate.
skipping to change at page 12, line 17 skipping to change at page 11, line 17
in the EHLO response, they MUST be in the form of LDH labels or in the EHLO response, they MUST be in the form of LDH labels or
A-labels. A-labels.
3.7.2. Mail eXchangers 3.7.2. Mail eXchangers
If multiple DNS MX records are used to specify multiple servers for a If multiple DNS MX records are used to specify multiple servers for a
domain in section 5 of [RFC5321], it is strongly advised that all or domain in section 5 of [RFC5321], it is strongly advised that all or
none of them SHOULD support the UTF8SMTPbis extension. Otherwise, none of them SHOULD support the UTF8SMTPbis extension. Otherwise,
surprising rejections can happen during temporary or permanent surprising rejections can happen during temporary or permanent
failures, which users might perceive as serious reliability issues. failures, which users might perceive as serious reliability issues.
In order to avoid the possible surprising rejections, the EAI-aware
email system may also implement the advice in EAI addresses advice
document [EAI addresses] and EAI deployment advice document [EAI
Deployment].
3.7.3. Trace Information 3.7.3. Trace Information
For the trace information [RFC5321], this memo updates the time stamp The trace information <Return-path-line>, <Time-stamp-line> and their
line and the return path line [RFC5321] formally defined as follows: related rules have been defined in in section 4.4 of RFC 5321
[RFC5321]. This document has updated <Mailbox> and <Domain> to
uReturn-path-line = "Return-Path:" FWS uReverse-path CRLF support non-ASCII characters. So Return-path-line may include the
; Replaces Return-path-line in Section 4.4 of RFC 5321 'Reverse-path' clause where internationalized domain name with the
U-label form may be used. Time-stamp-line may include the 'For'
uReverse-path = uPath / "<>" clause where the internationalized domain name with the U-label form
; Replace Reverse-path in RFC 5321, section 4.1.2 may be used.
uPath = "<" [ A-d-l ":" ] uMailbox ">"
; Replace Path in RFC 5321, section 4.1.2
; uMailbox is defined in section 3.3 of this document
A-d-l = <Defined in section 4.1.2 of RFC 5321>
uTime-stamp-line = "Received:" FWS uStamp CRLF
; Replaces Time-stamp-line in Section 4.4 of RFC 5321
uStamp = From-domain By-domain uOpt-info [CFWS] ";" FWS date-time
; Replaces Stamp in Section 4.4 of RFC 5321
From-domain = <Defined in section 4.4 of RFC 5321>
By-domain = <Defined in section 4.4 of RFC 5321>
date-time = <Defined in section 3.3 of RFC 5322>
; Same definition with date-time in Section 4.4 of RFC 5321
uOpt-info = [Via] [With] [ID] [uFor]
[Additional-Registered-Clauses]
; Replaces Opt-info in Section 4.4 of RFC 5321
; The protocol value for With will allow a UTF8SMTPbis value
Via = <Defined in section 4.4 of RFC 5321>
With = <Defined in section 4.4 of RFC 5321>
ID = <Defined in section 4.4 of RFC 5321>
Additional-Registered-Clauses = <Defined in section 4.4 of RFC 5321>
uFor = CFWS "FOR" FWS ( uPath / uMailbox)
; Replaces For in Section 4.4 of RFC 5321
; uMailbox is defined in section 3.3 of this document
Except in the 'uFor' clause and 'uReverse-path' value where Except in the 'For' clause and 'Reverse-path' clause where
internationalized domain name with the U-label form MAY be used, internationalized domain name with the U-label form MAY be used,
internationalized domain names in Received fields MUST be transmitted internationalized domain names in Received fields MUST be transmitted
in the form of A-labels. The protocol value of the WITH clause when in the form of A-labels. The protocol value of the 'WITH' clause
this extension is used is one of the UTF8SMTPbis values specified in when this extension is used is one of the UTF8SMTPbis values
the "IANA Considerations" section of this document. specified in the "IANA Considerations" section of this document.
3.7.4. UTF-8 Strings in Replies 3.7.4. UTF-8 Strings in Replies
3.7.4.1. MAIL Command 3.7.4.1. MAIL Command
If an SMTP client follows this specification and sends any MAIL If an SMTP client follows this specification and sends any MAIL
commands containing the UTF8SMTPbis parameter, the EAI-aware SMTP commands containing the UTF8SMTPbis parameter, the EAI-aware SMTP
server is permitted to use UTF-8 characters in the email address 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 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 able to accept and process them. If a given MAIL command does not
skipping to change at page 14, line 40 skipping to change at page 12, line 26
commands that contain UTF-8 strings. However, the EAI-aware SMTP commands that contain UTF-8 strings. However, the EAI-aware SMTP
server MUST NOT use UTF-8 strings in replies if the SMTP client does server MUST NOT use UTF-8 strings in replies if the SMTP client does
not specifically allow such replies by transmitting this parameter. not specifically allow such replies by transmitting this parameter.
Most replies do not require that a mailbox name be included in the Most replies do not require that a mailbox name be included in the
returned text, and therefore UTF-8 string is not needed in them. returned text, and therefore UTF-8 string is not needed in them.
Some replies, notably those resulting from successful execution of Some replies, notably those resulting from successful execution of
the VRFY and EXPN commands, do include the mailbox. the VRFY and EXPN commands, do include the mailbox.
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
vrfy = "VRFY" SP uString vrfy = "VRFY" SP String
[ SP "UTF8SMTPbis" ] CRLF [ SP "UTF8SMTPbis" ] CRLF
; String may include UTF-8 characters
expn = "EXPN" SP uString expn = "EXPN" SP String
[ SP "UTF8SMTPbis" ] CRLF [ SP "UTF8SMTPbis" ] CRLF
; String may include UTF-8 characters
uString = uAtom / uQuoted-string
; uAtom and uQuoted-string are defined in
; Section 3.3 of this document.
The "UTF8SMTPbis" parameter does not use a value. If the reply to a The "UTF8SMTPbis" parameter does not use a value. If the reply to a
VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the
SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI- SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI-
aware SMTP server MUST use either the reply-code 252 or 550. Reply- aware SMTP server MUST use either the reply-code 252 or 550. Reply-
code 252, defined in [RFC5321], means "Cannot VRFY user, but will code 252, defined in [RFC5321], means "Cannot VRFY user, but will
accept the message and attempt the delivery". Reply-code 550, also accept the message and attempt the delivery". Reply-code 550, also
defined in [RFC5321], means "Requested action not taken: mailbox defined in [RFC5321], means "Requested action not taken: mailbox
unavailable". When the EAI-aware SMTP server supports enhanced mail unavailable". When the EAI-aware SMTP server supports enhanced mail
system status codes [RFC3463], the enhanced reply-code as specified system status codes [RFC3463], the enhanced reply-code as specified
below is used. Using the "UTF8SMTPbis" parameter with a VERIFY below is used. Using the "UTF8SMTPbis" parameter with a VERIFY
(VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that
command only. command only.
If a normal success response (i.e., 250) is returned, the response 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 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: the user. It MUST be in either of the following forms:
User Name <uMailbox> User Name <Mailbox>
; uMailbox is defined in Section 3.3 of this document. ; Mailbox is defined in section 3.3 of this document.
; User Name can contain non-ASCII characters. ; User Name can contain non-ASCII characters.
uMailbox Mailbox
; uMailbox is defined in Section 3.3 of this document. ; Mailbox is defined in section 3.3 of this document.
If the SMTP reply requires UTF-8 strings, but UTF-8 string is not If the SMTP reply requires UTF-8 strings, but UTF-8 string is not
allowed in the reply, and the EAI-aware SMTP server supports enhanced allowed in the reply, and the EAI-aware SMTP server supports enhanced
mail system status codes [RFC3463], the enhanced reply-code is mail system status codes [RFC3463], the enhanced reply-code is
"X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is
REQUIRED to show the mailbox name, but that form of response is not REQUIRED to show the mailbox name, but that form of response is not
permitted by the SMTP client". permitted by the SMTP client".
If the SMTP client does not support the UTF8SMTPbis extension, but If the SMTP client does not support the UTF8SMTPbis extension, but
receives a UTF-8 string in a reply, it may not be able to properly receives a UTF-8 string in a reply, it may not be able to properly
skipping to change at page 18, line 42 skipping to change at page 16, line 36
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,
and Lars Eggert. Of course, none of the individuals are necessarily and Lars Eggert. Of course, none of the individuals are necessarily
responsible for the combination of ideas represented here. responsible for the combination of ideas represented here.
Thanks a lot to Dave Crocker for his comments and helping of ABNF
refinement.
7. Change History 7. Change History
[[anchor14: RFC Editor: Please remove this section.]] [[anchor14: 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
skipping to change at page 20, line 9 skipping to change at page 18, line 5
add the mail parameter add the mail parameter
add the new section about mail command parameter usage add the new section about mail command parameter usage
update the security consideration update the security consideration
7.11. draft-ietf-eai-rfc5336bis: Version 09 7.11. draft-ietf-eai-rfc5336bis: Version 09
improve the texts improve the texts
7.12. draft-ietf-eai-rfc5336bis: Version 10
refine the ABNF definitions
improve the texts
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, [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996. October 1996.
skipping to change at page 21, line 26 skipping to change at page 19, line 27
[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.
[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
[EAI Deployment]
Yao, J., Lee, X., and S. Steel, "Advice for EAI
deployment", draft eai-deployment, December 2010.
[EAI addresses]
Steel, S., Yao, J., and Mark. Davis, "Advice for non-ASCII
& ASCII addresses", draft eai-address-advice,
December 2010.
[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) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. 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,
 End of changes. 38 change blocks. 
175 lines changed or deleted 121 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/