draft-ietf-eai-smtpext-08.txt   draft-ietf-eai-smtpext-09.txt 
Network Working Group J. Yao, Ed. Network Working Group J. Yao, Ed.
Internet-Draft W. Mao, Ed. Internet-Draft W. Mao, Ed.
Intended status: Experimental CNNIC Updates: RFC4952 CNNIC
Expires: March 6, 2008 September 3, 2007 (if approved) November 17, 2007
Intended status: Experimental
Expires: May 20, 2008
SMTP extension for internationalized email address SMTP extension for internationalized email address
draft-ietf-eai-smtpext-08.txt draft-ietf-eai-smtpext-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 6, 2008. This Internet-Draft will expire on May 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies the use of SMTP extension for This document specifies an SMTP extension for transport and delivery
internationalized email address delivery. Communication with systems of email messages with internationalized email addresses or header
that do not implement this specification is specified in another information. Communication with systems that do not implement this
document. specification is specified in another document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of this specification . . . . . . . . . . . . . . . . 3 1.1. Role of this specification . . . . . . . . . . . . . . . . 3
1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4
2.1. Framework for the Internationalization Extension . . . . . 4 2.1. Framework for the Internationalization Extension . . . . . 4
2.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5 2.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6
2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 8 2.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 8
2.5. ALT-ADDRESS parameter usage and response codes . . . . . . 9 2.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 9
2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10
2.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11
2.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 2.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11
2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 10 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
2.7.4. UTF-8 Reply . . . . . . . . . . . . . . . . . . . . . 11 2.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12
3. Issues with Other Parts of the Email System . . . . . . . . . 13 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3.1. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
3.2. SMTP Service Extension for DSNs . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 13 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Potential problems . . . . . . . . . . . . . . . . . . . . . . 14 6.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 15
4.1. Impact many email related RFC . . . . . . . . . . . . . . 14 6.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 15
5. Implementation Advice . . . . . . . . . . . . . . . . . . . . 14 6.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 15
7. Security considerations . . . . . . . . . . . . . . . . . . . 15 6.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 16
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 6.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 16
9.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 15 6.8. draft-ietf-eai-smtpext: Version 07 . . . . . . . . . . . . 16
9.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 15 6.9. draft-ietf-eai-smtpext: Version 08 . . . . . . . . . . . . 16
9.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 16 6.10. draft-ietf-eai-smtpext: Version 09 . . . . . . . . . . . . 16
9.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
9.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 16 Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 18
9.8. draft-ietf-eai-smtpext: Version 07 . . . . . . . . . . . . 16 A.1. Conventional Message and Internationalized Message . . . . 19
9.9. draft-ietf-eai-smtpext: Version 08 . . . . . . . . . . . . 17 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
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 peering difference is that emails are delivered through a chain of clients
clients and servers while domain names are resolved by name servers and servers while domain names are resolved by name servers looking
by looking up their own tables. In addition to this, email transport up those names in their own tables. In addition to this, the
protocol ESMTP[RFC1869] provides a negotiation mechanism through extended email transport protocol [RFC2821] provides a negotiation
which clients can make decisions for further processing; please see mechanism with which clients can discover server capabilities and
more in [EAI-framework]. Email addresses can exploit the SMTP make decisions for further processing. An extended overview of the
extension negotiation mechanism while Internationalized Domain extension model for internationalized addresses and headers appears
Name(IDN) does not have such a facility. This is also more in [EAI-framework], referred to as "the framework document" or just
architecturally desirable approach. This document specifies an SMTP as "Framework" elsewhere in this specification. This document
extension to permit internationalized email addresses in envelopes, specifies an SMTP extension to permit internationalized email
and UTF-8 in headers. The protocol described here is an MTA solution addresses in envelopes, and UNICODE characters (encoded in UTF-8) in
which is feasible, architecturally elegant, and not difficult to headers.
deploy.
1.1. Role of this specification 1.1. Role of this specification
The framework document [EAI-framework] specifies the requirements The framework document specifies the requirements for, and describes
for, and components of, full internationalization of electronic mail. components of, full internationalization of electronic mail. A
To understand and implement this specification, understanding the thorough understanding of the information in that document and in the
context presented in [EAI-framework] is necessary. base Internet email specifications [RFC2821] [RFC2822] is necessary
to understand and implement this specification.
This document specifies an element of that work, specifically the This document specifies an element of the email internationalization
definition of an SMTP extension [RFC1869] for the internationalized work, specifically the definition of an SMTP extension [RFC2821] for
email address transport delivery. internationalized email address transport delivery.
1.2. Proposal Context 1.2. Proposal Context
This specification describes a change to the email transport This specification describes an optional extension to the email
mechanism that permits non-ASCII characters in both the envelope and transport mechanism that permits non-ASCII [ASCII] characters in both
header fields of messages while the specification in [EAI-utf8header] the envelope and header fields of messages. The EAI-utf8header
specifies the details of how and where non-ASCII characters are specification [EAI-utf8header] provides the details of how and where
permitted in the header fields of messages. The context for the non-ASCII characters are permitted in the header fields of messages.
change is described in [EAI-framework]. The context for the change is described in the framework document.
1.3. Terminology 1.3. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in RFC and "MAY" in this specification are to be interpreted as described in
2119 [RFC2119]. RFC 2119 [RFC2119].
All specialized terms used in this specification are defined in the The terms "conventional message" and "internationalized message" are
EAI framework [EAI-framework] or in [RFC2821] and [RFC2822]. The defined in an appendix to this specification. The terms "UTF-8
terms "ASCII address", "internationalized email address", "non-ASCII string" or "UTF-8 character" are used informally to refer to Unicode
address", "i18mail address", "UTF8SMTP", "message" and "mailing list" characters encoded in UTF-8 [RFC3629]. All other specialized terms
are used with the definitions from the [EAI-framework] document. used in this specification are defined in the framework document or
in the base Internet email specifications [RFC2821] [RFC2822]. In
particular, the terms "ASCII address", "internationalized email
address", "non-ASCII address", "i18mail address", "UTF8SMTP",
"message" and "mailing list" are used in this document according to
the definitions in the framework one.
This document defines only those ABNF [RFC4234] syntax rules that are This specification defines only those ABNF [RFC4234] syntax rules
different from those of the base email specifications that are different from those of the base email specifications
[RFC2821][RFC2822] and, where the earlier rules are upgraded or [RFC2821][RFC2822] and, where the earlier rules are upgraded or
extended, gives them new names. When the new rule is a small upgrade extended, gives them new names. When the new rule is a small
to the older one, it is typically given a name starting with "u". modification to the older one, it is typically given a name starting
Rules that are undefined here may be found in the base email with "u". Rules that are undefined here may be found in the base
documents under the same names. email specifications under the same names.
[[anchor4: RFC EDITOR'S NOTE: The following text should be deleted [[anchor4: NOTE TO RFC EDITOR: Please remove the following text
before publication.]] This document is being discussed on the EAI before publication.]]
mailing list. See https://www1.ietf.org/mailman/listinfo/ima for This specification is being discussed on the EAI mailing list. See
information about subscribing. The list's archive is at https://www1.ietf.org/mailman/listinfo/ima for information about
subscribing. The list's archive is at
http://www1.ietf.org/mail-archive/web/ima/index.html. http://www1.ietf.org/mail-archive/web/ima/index.html.
2. Mail Transport-level Protocol 2. Mail Transport-level Protocol
2.1. Framework for the Internationalization Extension 2.1. Framework for the Internationalization Extension
The following service extension is defined: The following service extension is defined:
1. The name of the SMTP service extension is "Email Address 1. The name of the SMTP service extension is "Email Address
Internationalization"; Internationalization".
2. The EHLO keyword value associated with this extension is 2. The EHLO keyword value associated with this extension is
"UTF8SMTP"; "UTF8SMTP".
3. No parameter values are defined for this EHLO keyword value. In 3. No parameter values are defined for this EHLO keyword value. In
order to permit future (although unanticipated) extensions, the order to permit future (although unanticipated) extensions, the
EHLO response MUST NOT contain any parameters for that keyword. EHLO response MUST NOT contain any parameters for that keyword.
Clients MUST ignore any parameters, that is, clients MUST behave Clients MUST ignore any parameters, that is, clients MUST behave
as if the parameters do not appear. If a server includes as if the parameters do not appear. If a server includes
UTF8SMTP in its EHLO response, it MUST be fully compliant with UTF8SMTP in its EHLO response, it MUST be fully compliant with
this version of this specification. this version of this specification.
4. One optional parameter, ALT-ADDRESS, is added to the SMTP MAIL 4. One optional parameter, ALT-ADDRESS, is added to the MAIL and
and RCPT commands. ALT-ADDRESS specifies an all-ASCII address RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII
which can be used as a substitute for the i18mail addresses that address which can be used as a substitute for the corresponding
we call the primary address; you can learn more in primary (i18mail) address when downgrading. More discussion of
[EAI-framework] or [EAI-downgrading]. the use of this parameter appears in [EAI-framework] and
[EAI-downgrading].
5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN
commands. The parameter UTF8REPLY has no value. The parameter commands. The parameter UTF8REPLY has no value. The parameter
indicates the SMTP client can accept UTF-8 on replies of the indicates that the SMTP client can accept Unicode characters in
VRFY and EXPN commands. UTF-8 encoding in replies from the VRFY and EXPN commands.
6. No additional SMTP verbs are defined by this extension. 6. No additional SMTP verbs are defined by this extension.
7. Servers offering this extension MUST provide support for, and 7. Servers offering this extension MUST provide support for, and
announce, the 8BITMIME extension [RFC1652]. announce, the 8BITMIME extension [RFC1652].
8. The reverse-path and forward-path of the SMTP MAIL and RCPT
8. The reverse-path and forward-path of SMTP MAIL and RCPT commands commands are extended to allow Unicode characters encoded in
are extended to allow UTF-8 characters in the specified mailbox UTF-8 in mailbox names (addresses).
address. 9. The mail message body is extended as specified in
9. The mail datum is extended in compliance with [EAI-utf8header] [EAI-utf8header].
10. The maximum length of a MAIL and RCPT command lines is increased 10. The maximum length of MAIL and RCPT command lines is increased
by 460 characters by the possible addition of the ALT-ADDRESS by 460 characters by the possible addition of the ALT-ADDRESS
keyword and value. keyword and value.
11. The UTF8SMTP extension is valid on the submission port
[RFC4409].
2.2. The UTF8SMTP Extension 2.2. The UTF8SMTP Extension
An SMTP Server that announces this extension MUST be prepared to An SMTP Server that announces this extension MUST be prepared to
accept a UTF-8 string [RFC3629] in any position in which RFC 2821 accept a UTF-8 string [RFC3629] in any position in which RFC 2821
specifies that a "mailbox" MAY appear. That string MUST be parsed specifies that a mailbox can appear. That string MUST be parsed only
only as specified in RFC 2821, i.e., by separating the mailbox into as specified in RFC 2821, i.e., by separating the mailbox into source
source route, local part and domain part, using only the characters route, local part and domain part, using only the characters colon
colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified (U+003A), comma (U+002C), and at-sign (U+0040) as specified there.
there. Once isolated by this parsing process, the local part MUST be Once isolated by this parsing process, the local part MUST be treated
treated as opaque unless the SMTP Server is the final delivery MTA. as opaque unless the SMTP Server is the final delivery MTA. Any
Any domain names that are to be looked up in the DNS MUST first be domain names that are to be looked up in the DNS MUST first be
processed into the form specified in IDNA [RFC3490] by means of the processed into the form specified in IDNA [RFC3490] by means of the
ToASCII() operation unless they are already in that form. Any domain ToASCII() operation unless they are already in that form. Any domain
names that are to be compared to local strings SHOULD be checked for names that are to be compared to local strings SHOULD be checked for
validity and then MUST be compared as specified in section 3.4 of validity and then MUST be compared as specified in section 3.4 of
IDNA. IDNA.
The UTF8SMTP extension is valid on the submission port [RFC4409].
An SMTP Client that receives the UTF8SMTP extension keyword in An SMTP Client that receives the UTF8SMTP extension keyword in
response to the "EHLO" command MAY transmit a mailbox name as an response to the "EHLO" command MAY transmit mailbox names within SMTP
internationalized string in UTF-8 form and MAY send an UTF-8 header commands as internationalized strings in UTF-8 form. It MAY send a
[EAI-utf8header]. It MAY transmit the domain part of that string in UTF-8 header [EAI-utf8header] (which may also include mailbox names
either the form of ACE labels specified in [RFC3490] or UTF-8 form. in UTF-8). It MAY transmit the domain parts of mailbox names within
In the domain part of the mailbox string, if any of the labels are SMTP commands or the message header in either the form of ACE labels
intended to be interpreted as non-ASCII (i.e., are IDNs), then the as specified in IDNA [RFC3490] or as UTF-8 strings. All labels in
Message Submission Server ("MSA") [RFC4409] MUST take responsibility domain parts of mailbox names which are IDNs (either UTF-8 or ACE
for ensuring that the labels are valid (whether they appear in native strings) MUST be valid. If the original client submits a message to
character or ACE form). The presence of the UTF8SMTP extension does a Message Submission Server ("MSA") [RFC4409], it is the
not change the requirement of RFC 2821 that servers relaying mail responsibility of the MSA that all domain labels are valid; otherwise
MUST not attempt to parse, evaluate, or transform the local part in it is the original client's responsibility. The presence of the
any way. UTF8SMTP extension does not change the requirement of RFC 2821 that
servers relaying mail MUST not attempt to parse, evaluate, or
transform the local part in any way.
If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP
client MUST NOT transmit an internationalized address and MUST NOT client MUST NOT transmit an internationalized address and MUST NOT
transmit a mail message which contains internationalized mail headers transmit a mail message containing internationalized mail headers as
[EAI-utf8header] at any level within its MIME structure. Instead, if described in [EAI-utf8header] at any level within its MIME structure.
an SMTP client (SMTP sender) attempts to transfer a UTF8SMTP message Instead, if an SMTP client (SMTP sender) attempts to transfer a
and encounters a server that does not support the extension, it MUST internationalized message and encounters a server that does not
make one of the following four choices: support the extension, it MUST make one of the following four
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[RFC4409], it MAY, consistent with the general provisions Server ("MSA") [RFC4409], it MAY, consistent with the general
for changes by such servers, rewrite the envelope, headers, or provisions for changes by such servers, rewrite the envelope,
message material to make them entirely ASCII and consistent with headers, or message material to make them entirely ASCII and
the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822]. consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822
2. Reject the message during the SMTP transaction or generate a [RFC2822].
notification of non-deliverability, as specified in RFC 2821 2. Either reject the message during the SMTP transaction or accept
[RFC2821] and RFC 3464 [RFC3464]. If the message content can be the message and then generate and transmit a notification of non-
returned without alteration, content should be returned as deliverability. Such notification MUST be done as specified in
specified in 2821 but, if a server is encountered along the RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI DSN
return path that cannot accept UTF8SMTP traffic, the content specification [EAI-dsn].
should simply be abridged or dropped.
3. Find an alternate route to the destination that permits UTF8SMTP. 3. Find an alternate route to the destination that permits UTF8SMTP.
That route may be discovered by trying alternate MX hosts (using That route may be discovered by trying alternate MX hosts (using
preference rules as specified in RFC 2821) or using other means preference rules as specified in RFC 2821) or using other means
available to the SMTP-sender. available to the SMTP-sender.
4. If and only if ASCII addresses are available for all addresses 4. If and only if ASCII addresses are available for all addresses
that appear in the return path and the specific forward paths that appear in the return path and the specific forward paths
being attempted, downgrade the message to an all-ASCII form as being attempted, downgrade the message to an all-ASCII form as
specified in [EAI-downgrading]. An ASCII address is considered specified in [EAI-downgrading]. An ASCII address is considered
to be "available" for a particular address if the original to be "available" for a particular address if the original
address in the envelope is in ASCII or if an ALT-Address address in the envelope is in ASCII or if an ALT-ADDRESS
parameter is specified for a UTF8SMTP address. parameter is specified for a UTF8SMTP address.
2.3. Extended Mailbox Address Syntax 2.3. Extended Mailbox Address Syntax
RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in
terms of ASCII characters, using the production for "Mailbox" and terms of ASCII characters, using the production for a mailbox and
those on which it depends. those 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 "sub-domain" to permit either the
definition above or a UTF-8 string representing a DNS label that definition above or a UTF-8 string representing a DNS label that
is conformant with IDNA [RFC3490]. is conformant with IDNA [RFC3490].
o Change the definition of "Atom" to permit either the definition o Change the definition of "Atom" to permit either the definition
above or a UTF-8 string. That string MUST NOT contain any of the above or a UTF-8 string. That string MUST NOT contain any of the
ASCII characters (either graphics or controls) that are not ASCII characters (either graphics or controls) that are not
permitted in "atext"; it is otherwise unrestricted. permitted in "atext"; it is otherwise unrestricted.
According to the description above, define the syntax of an According to the description above, the syntax of an
internationalized email mailbox with ABNF [RFC4234] as internationalized email mailbox name (address) is defined in ABNF
[RFC4234] as
uMailbox = uLocal-part "@" uDomain uMailbox = uLocal-part "@" uDomain
; Replace Mailbox in RFC 2821, section 4.1.2 ; Replace Mailbox in RFC 2821, section 4.1.2
uLocal-part = uDot-string / uQuoted-string uLocal-part = uDot-string / uQuoted-string
; MAY be case-sensitive ; MAY be case-sensitive
; Replace Local-part in RFC 2821, section 4.1.2 ; Replace Local-part in RFC 2821, section 4.1.2
uDot-string = uAtom *("." uAtom) uDot-string = uAtom *("." uAtom)
; Replace Dot-string in RFC 2821, section 4.1.2 ; Replace Dot-string in RFC 2821, section 4.1.2
skipping to change at page 7, line 34 skipping to change at page 8, line 4
uqcontent = qcontent / UTF8-xtra-char uqcontent = qcontent / UTF8-xtra-char
; qcontent is defined in RFC 2822, section 3.2.5 ; qcontent is defined in RFC 2822, section 3.2.5
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, section 4.1.2 ; Replace Domain in RFC 2821, section 4.1.2
; address-literal is defined in RFC2821 section 4.1.2 ; address-literal is defined in RFC2821 section 4.1.2
sub-udomain = uLet-dig [uLdh-str] sub-udomain = uLet-dig [uLdh-str]
; Replace sub-domain in RFC 2821, section 4.1.2 ; Replace sub-domain in RFC 2821, section 4.1.2
uLet-dig = Let-dig / UTF8-xtra-char uLet-dig = Let-dig / UTF8-xtra-char
; Let-dig is defined in RFC 2821, section 4.1.3 ; Let-dig is defined in RFC 2821, section 4.1.3
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig
; Replace Ldh-str in RFC 2821, section 4.1.3 ; Replace Ldh-str in RFC 2821, section 4.1.3
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629 ; UTF8-2, UTF8-3 and UTF8-4 are two, three, or four
; octet UTF-8 characters, as defined in RFC 3629
The value of "udomain" SHOULD be verified with IDNA [RFC3490]; If The value of "udomain" SHOULD be verified by applying the tests
failed, the email address with that udomain can not be regarded as specified as part of IDNA [RFC3490]. If that verification fails, the
the valid email address. email address with that udomain MUST NOT be regarded as a valid email
address.
2.4. The ALT-ADDRESS parameter 2.4. The ALT-ADDRESS Parameter
If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and
RCPT commands is extended to support the optional esmtp-keyword "ALT- RCPT commands is extended to support the optional esmtp-keyword "ALT-
ADDRESS", which specifies an alternate all-ASCII address which may be ADDRESS". That keyword specifies an alternate all-ASCII address
used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it which may be used when downgrading. If the ALT-ADDRESS esmtp-keyword
MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value which is is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-
defined below). value, which is defined below).
Based on the definition of mail-parameters in [RFC2821], the ALT- Based on the definition of mail-parameters in [RFC2821], the ALT-
ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is
defined below. defined as follows. The following definitions are given in the same
format as used in RFC 2821.
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update mail command in RFC 2821, section 4.1.1.2. ; Update the MAIL command in RFC 2821, section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal ; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies ; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified by <esmtp-param>. ; with the syntax specified for <esmtp-param> in RFC 2821.
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / "RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" /
uForward-Path) [ SP Rcpt-parameters ] CRLF uForward-Path) [ SP Rcpt-parameters ] CRLF
; Update rcpt command in RFC 2821, section 4.1.1.3. ; Update RCPT command in RFC 2821, section 4.1.1.3.
; A new parameter defined by the ABNF non-terminal ; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies ; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified by <esmtp-param>. ; with the syntax specified for <esmtp-param>.
; uDomain is defined in section 2.3 of this document
uReverse-path = uPath uReverse-path = uPath
; Replace Reverse-path in RFC 2821, section 4.1.2 ; Replace Reverse-path in RFC 2821, section 4.1.2
uForward-path = uPath uForward-path = uPath
; Replace Forward-path in RFC 2821, section 4.1.2 ; Replace Forward-path in RFC 2821, section 4.1.2
uPath = "<" [ A-d-l ":" ] uMailbox ">" uPath = "<" [ A-d-l ":" ] uMailbox ">"
; Replace Path in RFC 2821, section 4.1.2 ; Replace Path in RFC 2821, section 4.1.2
; A-d-l is defined in RFC 2821, section 4.1.2 ; A-d-l is defined in RFC 2821, section 4.1.2
; uMailbox is defined in section 2.3 of this document ; uMailbox is defined in section 2.3 of this document
ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-value
ALT-ADDRESS-esmtp-value=xtext ALT-ADDRESS-value=xtext
; Mailbox encoded as xtext. ; The value is a mailbox name encoded as xtext.
; xtext is defined in RFC 3461 [RFC3461], section 4.2 ; xtext is defined in RFC 3461, section 4.2
The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL
or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email
address before xtext encoding. address before xtext encoding.
2.5. ALT-ADDRESS parameter usage and response codes 2.5. ALT-ADDRESS Parameter Usage and Response Codes
[EAI-utf8header] specifies "UTF8SMTP message" which requires UTF8SMTP An "internationalized message" as defined in the appendix of this
support. Such a message MUST NOT be sent to an SMTP server which specification MUST NOT be sent to an SMTP server that does not
does not support UTF8SMTP. Such a message MAY be rejected due to support UTF8SMTP. Such a message MAY be rejected by a server if it
lack of the ALT-ADDRESS as discussed in section 2.2 of this document. lacks one or more ALT-ADDRESSes as discussed in Section 2.2 of this
specification.
When messages are rejected because they require UTF8SMTP, the The three-digit reply codes used in this section are consistent with
response code "550" is used, defined in [RFC2821], meaning "mailbox their meanings as defined in RFC 2821.
unavailable". If enhanced mail system status codes [RFC3463] are
used, the response code should be "5.6.x" [SMTP-codes], meaning that When messages are rejected because the RCPT command requires an ALT-
"The alt-address is required but not specified". ADDRESS, the response code 553 is used with the meaning "mailbox name
not allowed". When messages are rejected for other reasons, such as
the MAIL command requiring an ALT-ADDRESS, the response code 550 is
used with the meaning "mailbox unavailable". If enhanced mail system
status codes [RFC3463] are used, the response code should be "5.6.x"
[SMTP-codes], meaning that "The ALT-ADDRESS is required but not
specified".
If the response code is issued after the final "." of the DATA If the response code is issued after the final "." of the DATA
command, the response code "554" is used, defined in [RFC2821], command, the response code "554" is used with the meaning
meaning "Transaction failed". If enhanced mail system status codes "Transaction failed". If enhanced mail system status codes [RFC3463]
[RFC3463] are used, the response code should be "5.6.z" [SMTP-codes], are used, the response code should be "5.6.z" [SMTP-codes], meaning
meaning that "UTF8SMTP downgrade failed". that "UTF8SMTP downgrade failed".
[[anchor8: REMOVE THIS: IANA please assign the proper error codes for [[anchor7: RFC Editor: please insert the proper error codes for
"5.6.x" and "5.6.z".]] "5.6.x" and "5.6.z" after IANA has made the relevant assignments.]]
2.6. Body Parts and SMTP Extensions 2.6. Body Parts and SMTP Extensions
Since there is no ESMTP parameter which tells whether the message is Since there is no ESMTP parameter which tells whether the message is
UTF8SMTP message, SMTP server needs to parse all message header an internationalized message, an SMTP server that requires accurate
fields and MIME header fields in the message body to discover which knowledge of whether a message is internationalized is required to
messages are UTF8SMTP. While this specification requires that parse all message header fields and MIME header fields in the message
servers support the 8BITMIME extension [RFC1652] to ensure that body. While this specification requires that servers support the
servers have adequate handling capability for 8-bit data and to avoid 8BITMIME extension [RFC1652] to ensure that servers have adequate
a number of complex encoding problems, the use of internationalized handling capability for 8-bit data and to avoid a number of complex
addresses obviously does not require non-ASCII body parts in the MIME encoding problems, the use of internationalized addresses obviously
message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME does not require non-ASCII body parts in the MIME message. The
parameter if that is appropriate given the body content or, if the UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if
server advertises it and it is appropriate, with the BODY=BINARYMIME that is appropriate given the body content or, if the server
parameter specified in [RFC3030]. advertises BINARYMIME [RFC3030] and the BODY=BINARYMIME is
appropriate, with the BODY=BINARYMIME parameter.
Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
least one non-ASCII address, with or without ALT-ADDRESS, the precise
interpretation of "No 'Body' parameter", "BODY= 8BITMIME", and "BODY=
BINARYMIME" in the MAIL command is:
1. For No "Body" parameter, headers are in UTF-8, body parts are in
ASCII.
2. For BODY=8BITMIME parameter, headers are in UTF-8, some or all
body parts contain 8-bit line-oriented data.
3. For BODY=BINARYMIME parameter, headers are in UTF-8, some or all Assuming that the server advertises UTF8SMTP and 8BITMIME, and
body parts contain binary data without restriction as to line receives at least one non-ASCII address, with or without ALT-ADDRESS,
lengths or delimiters. the precise interpretation of "No 'Body' parameter", "BODY=
8BITMIME", and "BODY= BINARYMIME" in the MAIL command is:
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
line-oriented data.
3. If a BODY=BINARYMIME parameter is present, the header contains
UTF-8 characters and some or all body parts contain binary data
without restriction as to line lengths or delimiters.
2.7. Additional ESMTP Changes and Clarifications 2.7. Additional ESMTP Changes and Clarifications
The mail transport process involves addresses ("mailboxes") and The information carried in the mail transport process involves
domain names in contexts in addition to the MAIL and RCPT commands addresses ("mailboxes") and domain names in contexts in addition to
and extended alternatives to them. In general, the rule is that, the MAIL and RCPT commands and extended alternatives to them. In
when RFC 2821 specifies a mailbox, this document expects UTF-8 to be general, the rule is that, when RFC 2821 specifies a mailbox, this
used for the entire string; when RFC 2821 specifies a domain name, specification expects UTF-8 to be used for the entire string; when
the name SHOULD be in the form of ACE labels if its raw form is non- RFC 2821 specifies a domain name, the name SHOULD be in the form of
ASCII. ACE labels if its raw form is non-ASCII.
The following subsections list and discuss all of the relevant cases. The following subsections list and discuss all of the relevant cases.
Support and use of this extension requires support for 8BITMIME. It
means that 8BITMIME MUST be advertised by the UTF8SMTP capable SMTP
server.
2.7.1. The Initial SMTP Exchange 2.7.1. The Initial SMTP Exchange
When an SMTP or ESMTP connection is opened, the server normally sends When an SMTP or ESMTP connection is opened, the server normally sends
a "greeting" response consisting of the '220' reply code and some a "greeting" response consisting of the '220' reply code and some
information. The client then sends the EHLO command. Since the information. The client then sends the EHLO command. Since the
client cannot know whether the server supports UTF8SMTP until after client cannot know whether the server supports UTF8SMTP until after
it receives the response from EHLO, any domain names that appear in it receives the response from EHLO, any domain names that appear in
this dialogue, or in responses to EHLO, MUST be in the hostname form, this dialogue, or in responses to EHLO, MUST be in the hostname form,
i.e., internationalized ones MUST be in the form of ACE labels. i.e., internationalized ones MUST be in the form of ACE labels.
2.7.2. Mail eXchangers 2.7.2. Mail eXchangers
Commonly, organizations authorize multiple servers to accept mail Organizations often authorize multiple servers to accept mail
addressed to them. For example, the organization may itself operate addressed to them. For example, the organization may itself operate
more than one server, and may also or instead have an agreement with more than one server, and may also or instead have an agreement with
other organizations to accept mail as a backup. Authorized servers other organizations to accept mail as a backup. Authorized servers
are generally listed in MX records [RFC2821]. When more than one are generally listed in MX records as described in RFC2821. When
server accepts mail for the domain-part of a Mailbox, it is strongly more than one server accepts mail for the domain-part of a mailbox,
advised that either all or none of them support the UTF8SMTP it is strongly advised that either all or none of them support the
extension. Otherwise, surprising downgrades can happen during UTF8SMTP extension. Otherwise, surprising downgrades can happen
temporary failures, which is not a good thing. during temporary failures, which is not a good thing.
2.7.3. Trace Information 2.7.3. Trace Information
When an SMTP server receives a message for delivery or further When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received") processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content. Time stamp information at the beginning of the message content. "Time stamp" or
appears in the form of "Received: lines". The most important use of "Received" appears in the form of "Received: lines". The most
Received: lines is for debugging mail faults. When the delivery SMTP important use of Received: lines is for debugging mail faults. When
server makes the "final delivery" of a message, it inserts a return- the delivery SMTP server makes the "final delivery" of a message, it
path line at the beginning of the mail data. The primary purpose of inserts a return-path line at the beginning of the mail data. The
the Return-path is to designate the address to which messages primary purpose of the Return-path is to designate the address to
indicating non-delivery or other mail system failures are to be sent. which messages indicating non-delivery or other mail system failures
For the trace information, we update the time stamp line and the are to be sent. For the trace information, this memo updates the
return path line [RFC2821] formally defined as follows: time stamp line and the return path line [RFC2821] formally defined
as follows:
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF> uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF>
; Replaces Return-path-line in the section 4.4 of [RFC2821] ; Replaces Return-path-line in section 4.4 of RFC2821
; uReverse-path is defined in Section 2.3 ; uReverse-path is defined in Section 2.3 of this document
uTime-stamp-line = "Received:" FWS uStamp <CRLF> uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in the section 4.4 of [RFC2821] ; Replaces Time-stamp-line in section 4.4 of RFC2821
uStamp = From-domain By-domain uOpt-info ";" FWS date-time uStamp = From-domain By-domain uOpt-info ";" FWS date-time
; Replaces Stamp in the section 4.4 of [RFC2821] ; Replaces Stamp in section 4.4 of RFC2821
uOpt-info = [Via] [With] [ID] [uFor] uOpt-info = [Via] [With] [ID] [uFor]
; Replaces Opt-info in the section 4.4 of [RFC2821] ; Replaces Opt-info in section 4.4 of RFC2821
; [With]'s protocol value will allow UTF8SMTP value ; The protocol value for With will allow a UTF8SMTP value
uFor = "FOR" 1*( FWS (uPath / uMailbox) ) CFWS uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
; Replaces For in the section 4.4 of [RFC2821] ; Replaces For in section 4.4 of RFC2821
; uPath is defined in section 2.4 of this document ; uPath and uMailbox are defined in Sections 2.4 and
; uMailbox is defined in section 2.3 of this document ; 2.3, respectively, of this document
[[anchor12: Note: Whether the FOR parameter is permitted to accept [[anchor11: Note: The FOR parameter has been changed to match the
more than one address is now under discussion as part of the definition in RFC2821bis, permitting only one address in the For
rfc2821bis effort. The multiple-address construction was introduced clause. The group working on that document reached mailing list
with RFC 2821; it is not clear that it has been widely implemented or consensus that the syntax in RFC 2821 that permitted more than one
that it is wise. Whatever decision is reached about RFC2821bis will address was simply a mistake.]]
be reflected in the syntax of a future version of this document.]]
Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain
name may be used, internationalized domain names in Received fields names may be used, internationalized domain names in Received fields
MUST be transmitted in the form of ACE labels. The protocol value of MUST be transmitted in the form of ACE labels. The protocol value of
the WITH clause is UTF8SMTP when this extension is used. More the WITH clause is UTF8SMTP when this extension is used. More
information is in the "IANA Considerations" section of this document. information is in the "IANA Considerations" section of this
specification.
2.7.4. UTF-8 Reply 2.7.4. UTF-8 Strings in Replies
If the client issues the RCPT command which contains non-ASCII 2.7.4.1. MAIL and RCPT Commands
If the client issues the RCPT command containing non-ASCII
characters, the SMTP server is permitted to use UTF-8 characters in characters, the SMTP server is permitted to use UTF-8 characters in
the email address within 251 and 551 response codes. the email address associated with 251 and 551 response codes.
If an SMTP client follows this specification and sends any RCPT If an SMTP client follows this specification and sends any RCPT
commands containing non-ASCII addresses, it MUST be able to accept commands containing non-ASCII addresses, it MUST be able to accept
and process 251 or 551 replies containing UTF-8 email addresses. If and process 251 or 551 replies containing UTF-8 email addresses. If
a given RCPT command does not include non-ASCII envelope addresses, a given RCPT command does not include a non-ASCII envelope address,
the server MUST not return a 251 or 551 response containing a non- the server MUST not return a 251 or 551 response containing a non-
ASCII mailbox. Instead, it MUST transform such responses into 250 or ASCII mailbox. Instead, it MUST transform such responses into 250 or
550 responses that do not contain addresses. 550 responses that do not contain addresses.
If the VRFY and EXPN commands have the optional parameter 2.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter
"UTF8REPLY", it indicates the client can accept UTF-8 on replies of
the VRFY and EXPN commands. Specially this allows to use UTF-8 on If the VRFY and EXPN commands are transmitted the optional parameter
mailboxes and full names which occur on replies. The SMTP client "UTF8REPLY", it indicates the client can accept UTF-8 strings in
following this specification MUST accept UTF-8 on replies of the VRFY replies from those commands. This allows the server to use UTF-8
and EXPN commands. However the SMTP server MUST not use UTF-8 on strings in mailbox names and full names which occur in replies
replies, if the SMTP client does not ask UTF-8 replies. Some replies without concern that the client might be confused by them. An SMTP
include the mailbox, but usually most of replies do not require that client that conforms to this specification MUST accept and correctly
the mailbox is included in it and therefore UTF-8 is not needed. The process replies from the VRFY and EXPN commands that contain UTF-8
UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP strings. However the SMTP server MUST NOT use UTF-8 strings in
server that the client is prepared for UTF-8 on SMTP replies. replies if the SMTP client does not specifically allow such replies
by transmitting this parameter. Most replies do not require that a
mailbox name be included in the returned text and therefore UTF-8 is
not needed in them. Some replies, notably those resulting from
successful execution of the VRFY and EXPN commands, do include the
mailbox, making the provisions of this section important.
VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to: VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to:
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF
;uLocal-part is defined in section 2.3 of this document ; uLocal-part and uMailbox are defined in
;uMailbox is defined in section 2.3 of this document : Section 2.3 of this document
"EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF
;uLocal-part is defined in section 2.3 of this document ; uLocal-part and uMailbox are defined in
;uMailbox is defined in section 2.3 of this document ; Section 2.3 of this document
This parameter "UTF8REPLY" does not have value. If SMTP reply There is no value associated with the "UTF8REPLY" parameter. If SMTP
requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in reply requires UTF-8, but SMTP client does not use "UTF8REPLY"
the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code 252 parameter in the VERIFY (VRFY) and EXPAND (EXPN) commands, the
is used, defined in [RFC2821], meaning "Cannot VRFY user, but will response code 252 is used, defined in [RFC2821], meaning "Cannot VRFY
accept the message and attempt the delivery". Also response code 550 user, but will accept the message and attempt the delivery". Also
may be used, meaning "Requested action not taken: mailbox response code 550 may be used, meaning "Requested action not taken:
unavailable". If enhanced mail system status code [RFC3463] is used, mailbox unavailable". If enhanced mail system status code [RFC3463]
response codes given on below is used. "UTF8REPLY" on the VERIFY is used, response codes given on below is used. "UTF8REPLY" on the
(VRFY) or EXPAND (EXPN) commands enables UTF-8 for that command only. VERIFY (VRFY) or EXPAND (EXPN) commands enables UTF-8 for that
command only.
If a normal (i.e., 250) response is returned, the response MAY If a normal success response (i.e., 250) is returned, the response
include the full name of the user and MUST include the mailbox of the MAY include the full name of the user and MUST include the mailbox of
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 <uMailbox>
; uMailbox is defined in section 2.3 of this document ; uMailbox is defined in section 2.3 of this document
; User Name allows the non-ASCII character. ; User Name can contain non-ASCII characters.
uMailbox uMailbox
; uMailbox is defined in section 2.3 of this document ; uMailbox is defined in section 2.3 of this document
If the SMTP reply requires UTF-8, but UTF-8 is not allowed on reply, If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in
and enhanced mail system status code [RFC3463] is used, the response the reply, and enhanced mail system status codes [RFC3463] are used,
code should be "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The the response code should be "5.6.y" or "2.6.y" [SMTP-codes], meaning
UTF-8 reply required, but not allowed.". [[anchor13: REMOVE THIS: that "A reply containing a UTF-8 string is required to show the
IANA please assign the proper error codes for "5.6.y" and "2.6.y".]] mailbox name, but that form of response is not permitted by the
client.".
If the SMTP Client lack of the UTF8SMTP support receives the UTF-8 If the SMTP Client does not support the UTF8SMTP service extension,
message on reply, it may crash. UTF-8 messages on reply are only but receives a the UTF-8 string in a reply, it may not be able to
allowed in the commands under the situations described above. Under properly report the reply to the user or even crash.
any other circumstances, UTF-8 messages on the reply MUST NOT be Internationalized messages in replies are only allowed in the
used. commands under the situations described above. Under any other
circumstances, UTF-8 text MUST NOT appear in the reply.
Although UTF-8 is needed to represent email addresses in responses Although UTF-8 is needed to represent email addresses in responses
under the rules specified in this section, this extension does not under the rules specified in this section, this extension does not
permit the use of UTF-8 for any other purposes. SMTP servers MUST permit the use of UTF-8 for any other purposes. SMTP servers MUST
NOT include non-ASCII characters except in the limited cases NOT include non-ASCII characters in replies except in the limited
specifically permitted in this section. cases specifically permitted in this section.
3. Issues with Other Parts of the Email System
3.1. 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 UTF8SMTP capability. LMTP need to be
updated to deal with these situations.
3.2. SMTP Service Extension for DSNs
The existing draft standard Delivery status notifications
(DSNs)[RFC3461] is presently limited to US-ASCII text in the machine
readable portions of the protocol. "International Delivery and
Disposition Notifications" [EAI-dsn] adds a new address type for
international email addresses so an original recipient address with
non-US-ASCII characters can be correctly preserved even after
downgrading. If an SMTP server advertises both the UTF8SMTP and the
DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including
support for the ORCPT parameter.
3.3. POP and IMAP
The [EAI-framework] has introduced two documents [EAI-pop] and
[EAI-imap] to how to use internationalized user names based on UTF-8
characters for the retrieval of messages from a mail server.
4. Potential problems
4.1. Impact many email related RFC
Internationalized email has implications for all processes and
protocols which examine, handle, generate, or otherwise deal with
mail. In particular, address parsing or validity checks, message
parsing or handling, etc.
5. Implementation Advice
In the absence of this extension, SMTP clients and servers are
constrained to using only those addresses permitted by RFC 2821. 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.
6. IANA Considerations 3. IANA Considerations
IANA is requested to add "UTF8SMTP" to the SMTP extensions registry IANA is requested to add "UTF8SMTP" to the SMTP extensions registry
with the entry pointing to this specification for its definition. with the entry pointing to this specification for its definition.
IANA is requested to assign the proper error codes "5.6.x", "5.6.z", IANA is requested to assign the proper error codes for "5.6.x",
"5.6.y" and "2.6.y" for this specification based on [SMTP-codes]. "5.6.z", "5.6.y" and "2.6.y", following the guidance in Section 2.5,
and based on [SMTP-codes] and enter them in the appropriate registry.
The "Mail Transmission Types" registry is requested to be updated to The "Mail Transmission Types" registry is requested to be updated to
include the following new entries: include the following new entries:
WITH protocol types Description Reference +---------------+----------------------------+----------------------+
------------------- ---------------------------- --------- | WITH protocol | Description | Reference |
UTF8SMTP UTF8SMTP with Service Extensions [RFCxxxx] | types | | |
UTF8SMTPA UTF8SMTP with SMTP AUTH [RFC2554bis] +---------------+----------------------------+----------------------+
[RFCxxxx] | UTF8SMTP | UTF8SMTP with Service | [RFCXXXX] |
UTF8SMTPS UTF8SMTP with STARTTLS [RFC3207] | | Extensions | |
[RFCxxxx] | UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFCXXXX] |
UTF8SMTPSA UTF8SMTP with both STARTTLS and [RFC3207] | UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFCXXXX] |
SMTP AUTH [RFC2554bis] | UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
[RFCxxxx] | | STARTTLS and SMTP AUTH | [RFCXXXX] |
[[anchor22: REMOVE THIS: where RFCxxxx represents the future RFC N0. +---------------+----------------------------+----------------------+
of this document. When this document is published as RFC and
assigned with a RFC No., "xxxx" should be replaced with 4-digits No..
"RFC2554bis" should be replaced with the new RFC No. when the
"RFC2554bis" document is assigned with the new RFC No.]]
7. Security considerations 4. Security Considerations
See the extended security considerations discussion in See the extended security considerations discussion in the framework
[EAI-framework] document [EAI-framework].
8. Acknowledgements 5. Acknowledgements
Much of the text in the initial version of this document was derived Much of the text in the initial version of this specification was
or copied from [Klensin-emailaddr] with the permission of the author. derived or copied from [Klensin-emailaddr] with the permission of the
Significant comments and suggestions were received from Xiaodong LEE, author. Significant comments and suggestions were received from
Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other
team and were incorporated into the document. Special thanks to members of the JET team and were incorporated into the specification.
those contributors for this version of the document, those include Additional important comments and suggestions, and often specific
(but not limited to) John C Klensin, Charles Lindsey, Dave Crocker, text, were contributed by many members of the WG and design team.
Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Those contributions include material from John C Klensin, Charles
Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris
Ellermann, Alexey Melnikov. Of course, none of the individuals are Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall
necessarily responsible for the combination of ideas represented Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S.M., and
here. Soobok Lee. Of course, none of the individuals are necessarily
responsible for the combination of ideas represented here.
9. Change History 6. Change History
[[anchor25: REMOVE THIS: This section is used for tracking the update [[anchor17: RFC Editor: Please remove this section.]]
of this document. It may be useful to retain parts of it to
facilitate establishing dates and documents for the history of this
work.]]
9.1. draft-ietf-eai-smtpext: Version 00 6.1. draft-ietf-eai-smtpext: Version 00
This version supercedes draft-yao-ima-smtpext-03.txt. It refines the This version supercedes draft-yao-ima-smtpext-03.txt. It refines the
ABNF definition of the internationalized email address. It ABNF definition of the internationalized email address. It
represents as the EAI working group document. represents as the EAI working group document.
9.2. draft-ietf-eai-smtpext: Version 01 6.2. draft-ietf-eai-smtpext: Version 01
o Upgraded to reflect discussions during IETF 66. o Upgraded to reflect discussions during IETF 66.
o Remove the atomic parameter. o Remove the atomic parameter.
o Add the new section of "the Suggestion of the value of the ALT- o Add the new section of "the Suggestion of the value of the ALT-
ADDRESS parameter". ADDRESS parameter".
9.3. draft-ietf-eai-smtpext: Version 02 6.3. draft-ietf-eai-smtpext: Version 02
o Upgraded to reflect the recent discussion of the ima@ietf.org o Upgraded to reflect the recent discussion of the ima@ietf.org
mailing list. mailing list.
o Add the section of "Body Parts and SMTP Extensions". o Add the section of "Body Parts and SMTP Extensions".
o Add the new section of "Change History". o Add the new section of "Change History".
o Add the subsection about SMTP extensions for DSN. o Add the subsection about SMTP extensions for DSN.
9.4. draft-ietf-eai-smtpext: Version 03 6.4. draft-ietf-eai-smtpext: Version 03
o Update the syntax related to mailbox. o Update the syntax related to mailbox.
o Update the trace field section. o Update the trace field section.
o Add the new section about message retry. o Add the new section about message retry.
o Update the subsection about SMTP extensions for DSN. o Update the subsection about SMTP extensions for DSN.
9.5. draft-ietf-eai-smtpext: Version 04 6.5. draft-ietf-eai-smtpext: Version 04
o Refine some syntax. o Refine some syntax.
o Delete "Message Header Label" section. o Delete "Message Header Label" section.
o Change "bounce" to "reject". o Change "bounce" to "reject".
9.6. draft-ietf-eai-smtpext: Version 05 6.6. draft-ietf-eai-smtpext: Version 05
o Refine the abstract. o Refine the abstract.
o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter"
section. section.
o Move original section 2.7.4 and 2.7.5 to section 3 with the name o Move original section 2.7.4 and 2.7.5 to section 3 with the name
"Issues with other parts of the email system". "Issues with other parts of the email system".
o Add the new section "LMTP". o Add the new section "LMTP".
o Refine some text according to suggestions from the EAI mailing o Refine some text according to suggestions from the EAI mailing
list discussion list discussion
o Remove the section "Mailing List Question" o Remove the section "Mailing List Question"
9.7. draft-ietf-eai-smtpext: Version 06 6.7. draft-ietf-eai-smtpext: Version 06
o Delete the section about message retry. o Delete the section about message retry.
o Add the new subsection about Mail eXchangers o Add the new subsection about Mail eXchangers
o Add the new section about "UTF-8 Reply" o Add the new section about "UTF-8 Reply"
o Refine some response code for the section "Using the ALT-ADDRESS o Refine some response code for the section "Using the ALT-ADDRESS
parameter" parameter"
9.8. draft-ietf-eai-smtpext: Version 07 6.8. draft-ietf-eai-smtpext: Version 07
o Rename the section 2.5 o Rename the section 2.5
o Refine sthe section 2.7 o Refine sthe section 2.7
9.9. draft-ietf-eai-smtpext: Version 08 6.9. draft-ietf-eai-smtpext: Version 08
o Refine some texts and update some references o Refine some texts and update some references
10. References 6.10. draft-ietf-eai-smtpext: Version 09
10.1. Normative References o Add the appendix
o Move section 3.1, 3.2 and section 5 to Appendix
o Remove section 3.3 and section 4
o Add the new term definitions of conventional message and
international message in the appendix
o Refine some texts according to suggestions from the EAI mailing
list discussion during WG Last call
o Use the same reference for ASCII as RFC 2821.
o General editorial revision and cleanup, including extensive
modifications to the XML to produce a version that has better odds
of getting through the various checkers and validators.
[ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, 7. References
October 1969.
7.1. Normative References
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968.
[EAI-dsn] Newman, C. and A. Melnikov, "SMTP extensions for DSNs",
draft-ietf-eai-dsn-03.txt (work in progress),
September 2007.
[EAI-framework] [EAI-framework]
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 2007.
[EAI-utf8header] [EAI-utf8header]
Abel, Y., "Transmission of Email Headers in UTF-8 Abel, Y., "Transmission of Email Headers in UTF-8
Encoding", draft-ietf-eai-utf8headers-07.txt (work in Encoding", draft-ietf-eai-utf8headers-07.txt (work in
progress), September 2007. progress), September 2007.
[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",
RFC 1652, July 1994. RFC 1652, July 1994.
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995.
[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.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
skipping to change at page 18, line 19 skipping to change at page 18, line 11
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 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.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
10.2. Informative References [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
7.2. Informative References
[EAI-downgrading] [EAI-downgrading]
YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading
mechanism for Internationalized eMail Address", mechanism for Internationalized eMail Address",
draft-ietf-eai-downgrade-04 (work in progress), 7 2007. draft-ietf-eai-downgrade-04 (work in progress), 7 2007.
[EAI-dsn] Newman, C. and A. Melnikov, "SMTP extensions for DSNs",
draft-ietf-eai-dsn-03.txt (work in progress), 9 2007.
[EAI-imap]
Resnick, P. and C. Newman, "Considerations for IMAP in
Conjunction with Email Address Internationalization",
draft-ietf-eai-imap-utf8-01 (work in progress),
March 2007.
[EAI-mailing list]
Gellens, R. and E. Chung, "Mailing Lists and
Internationalized Email Addresses",
draft-ietf-eai-mailinglist-01.txt (work in progress),
January 2007.
[EAI-pop] Newman, C., "POP3 Support for UTF-8",
draft-ietf-eai-pop-01.txt (work in progress),
January 2007.
[Klensin-emailaddr] [Klensin-emailaddr]
Klensin, J., "Internationalization of Email Addresses", Klensin, J., "Internationalization of Email Addresses",
draft-klensin-emailaddr-i18n-03 (work in progress), draft-klensin-emailaddr-i18n-03 (work in progress),
July 2005. July 2005.
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996. October 1996.
[RFC2554bis]
Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", draft-siemborski-rfc2554bis-09 (work
in progress), April 2007.
[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.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
RFC 4409, April 2006. for Authentication", RFC 4954, July 2007.
[SMTP-codes] [SMTP-codes]
KLensin, J., "An IANA Registry for Extended SMTP Status KLensin, J., "An IANA Registry for Extended SMTP Status
Codes", draft-klensin-smtp-code-registry-00 (work in Codes", draft-klensin-smtp-code-registry-00 (work in
progress), April 2007. progress), April 2007.
Appendix A. Material Updating RFC 4952
RFC 4952, the Overview and Framework document covering this set of
extensions for internationalized email [EAI-framework], was completed
before this specification, which specifies a particular part of the
protocol set. This appendix, which is normative, contains material
that would have been incorporated into RFC 4952 had it been delayed
until the work described in the rest of this specification was
completed and that should be included in any update to RFC 4952.
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 UTF8header specification
[EAI-utf8header], and strictly conformant to RFC 2822 [RFC2822].
o An internationalized message is a message utilizing one or more of
the extensions defined in this specification or in the UTF8header
specification [EAI-utf8header], so that it is no longer conformant
to the RFC 2822 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 UTF8SMTP capability. LMTP need to be
updated to deal with these situations.
A.3. SMTP Service Extension for DSNs
The existing draft standard Delivery status notifications
(DSNs)[RFC3461] is limited to ASCII text in the machine readable
portions of the protocol. "International Delivery and Disposition
Notifications" [EAI-dsn] 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 UTF8SMTP and the DSN extension, that
server MUST implement EAI-dsn [EAI-dsn] 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 2821. 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 (editor)
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
 End of changes. 106 change blocks. 
424 lines changed or deleted 447 lines changed or added

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