draft-ietf-eai-smtpext-03.txt   draft-ietf-eai-smtpext-04.txt 
Network Working Group J. Yao, Ed. Network Working Group J. Yao, Ed.
Internet-Draft W. Mao, Ed. Internet-Draft W. Mao, Ed.
Expires: August 16, 2007 CNNIC Expires: September 4, 2007 CNNIC
February 12, 2007 March 3, 2007
SMTP extension for internationalized email address SMTP extension for internationalized email address
draft-ietf-eai-smtpext-03.txt draft-ietf-eai-smtpext-04.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 34
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 August 16, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Internationalized email address includes two parts, the local part 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 5 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 5
2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 8 2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 8
2.5. The Suggestion of the Value of the ALT-ADDRESS 2.5. The Suggestion of the Value of the ALT-ADDRESS
parameter . . . . . . . . . . . . . . . . . . . . . . . . 9 parameter . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . 10
2.7.2. Message Retry . . . . . . . . . . . . . . . . . . . . 10 2.7.2. Message Retry . . . . . . . . . . . . . . . . . . . . 10
2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
2.7.4. Mailing List Question . . . . . . . . . . . . . . . . 12 2.7.4. Mailing List Question . . . . . . . . . . . . . . . . 12
2.7.5. Message Header Label . . . . . . . . . . . . . . . . . 12 2.7.5. POP and IMAP . . . . . . . . . . . . . . . . . . . . . 12
2.7.6. POP and IMAP . . . . . . . . . . . . . . . . . . . . . 12 2.7.6. SMTP Service Extension for DSNs . . . . . . . . . . . 12
2.7.7. SMTP Service Extension for DSNs . . . . . . . . . . . 13 3. Potential problems . . . . . . . . . . . . . . . . . . . . . . 12
3. Potential problems . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Impact to RFC 4409 and many email related RFC . . . . . . 13
3.1. Impact to IRI . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Impact to RFC 2476 and many email related RFC . . . . . . 13
4. Implementation Advice . . . . . . . . . . . . . . . . . . . . 13 4. Implementation Advice . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security considerations . . . . . . . . . . . . . . . . . . . 14 6. Security considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 14 8.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 14
8.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 14 8.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 14
8.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 15 8.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 14
8.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 15 8.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 14
8.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
Internationalized email address is different from the Internationalized email address is different from the
internationalized domain name (IDN). It can be solved by exploiting internationalized domain name (IDN). It can be solved by exploiting
the negotiation mechanism while IDN can not use the negotiation the negotiation mechanism while IDN can not use the negotiation
mechanism. So internationalized email address SHOULD be solved in mechanism. So internationalized email address SHOULD be solved in
the mail transport-level using the negotiation mechanism, which is an the mail transport-level using the negotiation mechanism, which is an
architecturally desirable approach. This document specifies a architecturally desirable approach. This document specifies a
protocol to solve the problem of internationalized email address protocol to solve the problem of internationalized email address
skipping to change at page 5, line 38 skipping to change at page 5, line 38
internationalized string in UTF-8 form and MAY send an internationalized string in UTF-8 form and MAY send an
internationalized mail header [EAI-utf8header]. It MAY transmit the internationalized mail header [EAI-utf8header]. It MAY transmit the
domain part of that string in either punycode (derived from the IDNA domain part of that string in either punycode (derived from the IDNA
process) or UTF-8 form. If it sends the domain in UTF-8 form, the process) or UTF-8 form. If it sends the domain in UTF-8 form, the
original SMTP client SHOULD first verify that the string is valid for original SMTP client SHOULD first verify that the string is valid for
a domain name according to IDNA rules. As required by RFC 2821, it a domain name according to IDNA rules. As required by RFC 2821, it
MUST not attempt to parse, evaluate, or transform the local part in MUST not attempt to parse, evaluate, or transform the local part in
any way if the UTF8SMTP SMTP extension is offered by the server. If any way if the UTF8SMTP SMTP extension is offered by the server. If
the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 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 body which contains internationalized mail headers transmit a mail message which contains internationalized mail headers
[EAI-utf8header]. Instead, it MUST either return the message to the [EAI-utf8header]. Instead, it MUST either return the message to the
user as undeliverable or replace it with the alternate ASCII address. user as undeliverable or replace it with the alternate ASCII address.
If it is replaced, the replacement MUST be the ASCII-only address If it is replaced, the replacement MUST be the ASCII-only address
specified with the ALT-ADDRESS parameter.[EAI-downgrading]. specified with the ALT-ADDRESS parameter.[EAI-downgrading].
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 "Mailbox" and
those on which it depends. those on which it depends.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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
uAtom = 1*ucharacter uAtom = 1*ucharacter
; Replace Atom in RFC 2821, section 4.1.2 ; Replace Atom in RFC 2821, section 4.1.2
ucharacter = atext / Non-ASCII ucharacter = atext / UTF8-non-ASCII
; Replace character in RFC 2821, section 4.1.2 ; Replace character in RFC 2821, section 4.1.2
; atext is defined in RFC 2822 ; atext is defined in RFC 2822
; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629
uQuoted-string = DQUOTE *uqcontent DQUOTE uQuoted-string = DQUOTE *uqcontent DQUOTE
; Replace Quoted-string in RFC 2821, section 4.1.2 ; Replace Quoted-string in RFC 2821, section 4.1.2
; DQUOTE is Double Quote defined in RFC 4234 ; DQUOTE is Double Quote defined in RFC 4234
uqcontent = qcontent / Non-ASCII uqcontent = qcontent / UTF8-non-ASCII
; 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 / Non-ASCII uLet-dig = Let-dig / UTF8-non-ASCII
; Let-dig in the right of '=' is defined in RFC 2822 ; Let-dig is defined in RFC 2821, section 4.1.3
uLdh-str = *( ALPHA / DIGIT / "-" / Non-ASCII) uLet-dig uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ASCII) uLet-dig
; Replace Ldh-str in RFC 2821, section 4.1.2 ; Replace Ldh-str in RFC 2821, section 4.1.3
Non-ASCII = UTF8-2 / UTF8-3 / UTF8-4 UTF8-non-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629
The value of "udomain" SHOULD be verified with [RFC3490]; If failed, The value of "udomain" SHOULD be verified with [RFC3490]; If failed,
the email address with that udomain can not be regarded as the valid the email address with that udomain can not be regarded as the valid
email address. 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", to specify the conditions under which the SMTP server may ADDRESS", to specify the conditions under which the SMTP server may
skipping to change at page 8, line 31 skipping to change at page 8, line 31
"RCPT TO:" SP <uForward-path> [ SP <rcpt-parameters> ]<CRLF> "RCPT TO:" SP <uForward-path> [ SP <rcpt-parameters> ]<CRLF>
; Update rcpt command in RFC 2821, section 3.3 ; Update rcpt command in RFC 2821, section 3.3
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 = "<" [ uA-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
uA-d-l = uAt-domain *( "," uA-d-l ) ; uMailbox is defined in section 2.3 of this document
; Replace A-d-l in RFC 2821, section 4.1.2
uAt-domain = "@" udomain
; Replace At-domain in RFC 2821, section 4.1.2
; udomain is defined in section 2.3 of this document
ALT-ADDRESS-esmtp-value=Mailbox ALT-ADDRESS-esmtp-value=Mailbox
; Mailbox is defined in RFC 2821, section 4.1.2 ; Mailbox is defined in RFC 2821, section 4.1.2
The use of the ALT-ADDRESS is specified below: If some involved SMTP The use of the ALT-ADDRESS is specified below: If some involved SMTP
servers can not support UTF8SMTP capability and if the sender has servers can not support UTF8SMTP capability and if the sender has
already set the ALT-ADDRESS value, the client SMTP server will use already set the ALT-ADDRESS value, the client SMTP server will use
this address as the email address when the SMTP server does the this address as the email address when the SMTP server does the
subsequent operations. If the ALT-ADDRESS value is not set by the subsequent operations. If the ALT-ADDRESS value is not set by the
sender, the email must be bounced to the original sender. If the sender, the email must be rejected to the original sender. If the
email is bounced due to the incapability of supporting UTF8SMTP, the email is rejected due to the incapability of supporting UTF8SMTP, the
relative server should issue the response error code "5.3.3" defined relative server should issue the response error code "5.3.3" defined
in [RFC3463] which means that System is not capable of selected in [RFC3463] which means that System is not capable of selected
features, permanent failure. features, permanent failure.
2.5. The Suggestion of the Value of the ALT-ADDRESS parameter 2.5. The Suggestion of the Value of the ALT-ADDRESS parameter
The "ALT-ADDRESS" requires an all-ASCII address. There are two The "ALT-ADDRESS" requires an all-ASCII address. There are two
alternative ways to set ALT-ADDRESS value: one is set by the sender alternative ways to set ALT-ADDRESS value: one is set by the sender
using the all-ASCII address, the other is set using the transformed using the all-ASCII address, the other is set using the transformed
email address. email address.
skipping to change at page 11, line 20 skipping to change at page 11, line 19
recipient address is non-ASCII, that the delivery path servers recipient address is non-ASCII, that the delivery path servers
normally support UTF8SMTP (if the sender's client or MSA didn't normally support UTF8SMTP (if the sender's client or MSA didn't
support UTF8SMTP, the message would not have been accepted for support UTF8SMTP, the message would not have been accepted for
delivery in the first place). Thus, a lack of UTF8SMTP support is delivery in the first place). Thus, a lack of UTF8SMTP support is
likely to be a temporary situation, such as a normal inbound server likely to be a temporary situation, such as a normal inbound server
being down and a cooperating site acting as a backup MX. If the lack being down and a cooperating site acting as a backup MX. If the lack
of UTF8SMTP in the delivery path of a message is a temporary of UTF8SMTP in the delivery path of a message is a temporary
situation, and the message is sent successfully after retrying, then situation, and the message is sent successfully after retrying, then
it was a good thing to do. Of course, if there is always an ASCII- it was a good thing to do. Of course, if there is always an ASCII-
only SMTP server in the path, then retrying only adds delay to the only SMTP server in the path, then retrying only adds delay to the
failure (bounce or downgrade). failure (reject or downgrade).
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. The most information at the beginning of the message content. The most
important use of Received: lines is for debugging mail faults. For important use of Received: lines is for debugging mail faults. For
the trace information, we update the time stamp line and the return the trace information, we update the time stamp line and the return
path line [RFC2821] formally defined as follows: path line [RFC2821] formally defined as follows:
skipping to change at page 11, line 45 skipping to change at page 11, line 44
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 the 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 the 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 the section 4.4 of [RFC2821]
; [With]'s protocl value will allow UTF8SMTP value ; [With]'s protocl value will allow UTF8SMTP value
uFor = "FOR" FWS 1*( Path / uMailbox ) CFWS uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS
; Replaces For in the section 4.4 of [RFC2821] ; Replaces For in the section 4.4 of [RFC2821]
; uReverse-path is defined in Section 2.4 ; uReverse-path is defined in Section 2.4
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 name may be used, internationalized domain names in Received fields
MUST be transmitted in the punycode form. The [With]'s protocl value MUST be transmitted in the punycode form. The [With]'s protocl value
will have the value of 'UTF8SMTP' for UTF8SMTP extension. We will will have the value of 'UTF8SMTP' for UTF8SMTP extension. We will
give more informaiton about this in "IANA consideration" section of give more informaiton about this in "IANA consideration" section of
this document. If a "for" clause containing non-ASCII is encountered this document. If a "for" clause containing non-ASCII is encountered
when downgrading a message, it is better to just drop the "for" when downgrading a message, it is better to just drop the "for"
skipping to change at page 12, line 23 skipping to change at page 12, line 21
For more detailed information, you may see it in [EAI-utf8header]. For more detailed information, you may see it in [EAI-utf8header].
2.7.4. Mailing List Question 2.7.4. Mailing List Question
How a mixture of traditional and internationalized addresses on a How a mixture of traditional and internationalized addresses on a
mailing list will impact message flows, error reports, and delivery mailing list will impact message flows, error reports, and delivery
notifications in all plausible combinations of UTF8SMTP capability notifications in all plausible combinations of UTF8SMTP capability
and un-capability servers is discussed and specified in the and un-capability servers is discussed and specified in the
[EAI-mailing list]. [EAI-mailing list].
2.7.5. Message Header Label 2.7.5. POP and IMAP
Today it is routine that many MTAs scan every message for spam, virus
or other reasons. It seems that few MTAs depend on "Header-Type"
fields or marker to decide the message's type. The better choice is
to rely on scanning the message to decide the message's type:
UTF8SMTP or ASCII, instead of the header label "Header-Type" fields
or marker. The message header label "Header-Type" SHOULD NOT be used
to identify and distinguish the i18mail message from the normal
message when SMTP messages are transmitted on wire. This issue is
discussed and specified in [EAI-utf8header].
2.7.6. POP and IMAP
While SMTP mainly takes care of the transportation of messages and While SMTP mainly takes care of the transportation of messages and
the header fields on wire, POP essentially handles the retrieval of the header fields on wire, POP essentially handles the retrieval of
mail objects from the server by a client. In order to use mail objects from the server by a client. In order to use
internationalized user names based on i18mail for the retrieval of internationalized user names based on i18mail for the retrieval of
messages from a mail server using the POP protocol, a new capability messages from a mail server using the POP protocol, a new capability
SHOULD be introduced following the POP3 extension mechanism SHOULD be introduced following the POP3 extension mechanism
[RFC2449]. This is discussed and specified in the [EAI-pop]. [RFC2449]. This is discussed and specified in the [EAI-pop].
IMAP [RFC3501] uses the traditional user name which is based on IMAP [RFC3501] uses the traditional user name which is based on
ASCII. IMAP SHOULD be updated to support the internationalized user ASCII. IMAP SHOULD be updated to support the internationalized user
names based on i18mail for the retrieval of messages from a mail names based on i18mail for the retrieval of messages from a mail
server. This is discussed and specified in the [EAI-imap]. server. This is discussed and specified in the [EAI-imap].
2.7.7. SMTP Service Extension for DSNs 2.7.6. SMTP Service Extension for DSNs
The existing draft standard Delivery status notifications The existing draft standard Delivery status notifications
(DSNs)[RFC3461] is presently limited to US-ASCII text in the machine (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine
readable portions of the protocol. "International Delivery and readable portions of the protocol. "International Delivery and
Disposition Notifications" [EAI-dsn] adds a new address type for Disposition Notifications" [EAI-dsn] adds a new address type for
international email addresses so an original recipient address with international email addresses so an original recipient address with
non-US-ASCII characters can be correctly preserved even after non-US-ASCII characters can be correctly preserved even after
downgrading. If an SMTP server advertises both the UTF8SMTP and the downgrading. If an SMTP server advertises both the UTF8SMTP and the
DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including
support for the ORCPT parameter. support for the ORCPT parameter.
3. Potential problems 3. Potential problems
3.1. Impact to IRI 3.1. Impact to RFC 4409 and many email related RFC
The mailto: schema in IRI [RFC3987] MAY need to be modified when EAI
is standardized.
3.2. Impact to RFC 2476 and many email related RFC
The EAI protocols will impact on many email related RFC documents The internationalized email address protocols will impact on many
such as Message Submission [RFC2476]. These protocols SHOULD be email related RFC documents such as Message Submission [RFC4409].
considered when implementing the EAI protocol. Those protocols SHOULD be considered when implementing the
internationalized email address protocols.
4. Implementation Advice 4. Implementation Advice
In the absence of this extension, SMTP clients and servers are In the absence of this extension, SMTP clients and servers are
constrained to using only those addresses permitted by RFC 2821. The constrained to using only those addresses permitted by RFC 2821. The
local parts of those addresses MAY be made up of any ASCII local parts of those addresses MAY be made up of any ASCII
characters, although some of them MUST be quoted as specified there. characters, although some of them MUST be quoted as specified there.
It is notable in an internationalization context that there is a long It is notable in an internationalization context that there is a long
history on some systems of using overstruck ASCII characters (a history on some systems of using overstruck ASCII characters (a
character, a backspace, and another character) within a quoted string character, a backspace, and another character) within a quoted string
skipping to change at page 14, line 28 skipping to change at page 14, line 15
7. Acknowledgements 7. Acknowledgements
Much of the text in the initial version of this document was derived Much of the text in the initial version of this document was derived
or copied from [Klensin-emailaddr] with the permission of the author. or copied from [Klensin-emailaddr] with the permission of the author.
Significant comments and suggestions were received from Xiaodong LEE, Significant comments and suggestions were received from Xiaodong LEE,
Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET
team and were incorporated into the document. Special thanks to team and were incorporated into the document. Special thanks to
those contributors for this version of document, those includes (but those contributors for this version of document, those includes (but
not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald
Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon
Chung, Tony Finch, Kari Hurtta, Randall Gellens. Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann.
8. Change History 8. Change History
[[anchor21: REMOVE THIS: This section is used for tracking the update [[anchor19: REMOVE THIS: This section is used for tracking the update
of this document. It may be useful to retain parts of it to of this document. It may be useful to retain parts of it to
facilitate establishing dates and documents for the history of this facilitate establishing dates and documents for the history of this
work.]] work.]]
8.1. draft-ietf-eai-smtpext: Version 00 8.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 definiton of the internationalized email address. It represents ABNF definiton of the internationalized email address. It represents
as the EAI working group document. as the EAI working group document.
skipping to change at page 15, line 22 skipping to change at page 15, line 4
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.
8.4. draft-ietf-eai-smtpext: Version 03 8.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.
8.5. draft-ietf-eai-smtpext: Version 04
o Refine some syntax.
o Delete "Message Header Label" section.
o Change "bounce" to "reject".
9. References 9. References
9.1. Normative References 9.1. Normative References
[ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, [ASCII] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[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 (IMA)", mechanism for Internationalized eMail Address (IMA)",
skipping to change at page 16, line 33 skipping to change at page 16, line 20
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869, Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995. 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.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998. Mechanism", RFC 2449, November 1998.
[RFC2476] Gellens, R. and J. Klensin, "Message Submission",
RFC 2476, December 1998.
[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.
[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.
skipping to change at page 17, line 28 skipping to change at page 17, line 14
[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.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[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.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
9.2. Informative References 9.2. Informative References
[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.
[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.
 End of changes. 29 change blocks. 
63 lines changed or deleted 48 lines changed or added

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