draft-ietf-eai-email-clients-00.txt   draft-ietf-eai-email-clients-01.txt 
Network Working Group E. Dainow Email Address Internationalization E. Dainow
Internet-Draft Afilias (EAI) Afilias
Intended status: Experimental K. Fujiwara Internet-Draft K. Fujiwara
Expires: January 8, 2010 JPRS Intended status: Informational JPRS
July 8, 2009 Expires: March 11, 2013 September 7, 2012
Guidelines for Internationalized Email Clients Guidelines for Internationalized Email Clients
draft-ietf-eai-email-clients-00 draft-ietf-eai-email-clients-01
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document provides some guidelines for email clients that support
Email Address Internationalization (EAI) as outlined in [RFC6530]. A
number of interoperability cases between different versions of email
components are reviewed. Recommendations are made to improve
interoperability and usability and to minimize discrepancies between
the display of composed and received email in different language
environments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on March 11, 2013.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides some guidelines for email clients that support described in the Simplified BSD License.
Email Address Internationalization (EAI) as outlined in RFC 4952. A
number of interoperability cases between different versions of email
components are reviewed. Recommendations are made to improve
interoperability and usability and to minimize discrepancies between
the display of composed and received email in different language
environments.
Table of Contents Table of Contents
1. Conventions used in this document..............................3 1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction...................................................3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology...............................................3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Version Interoperability.......................................4 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Sending...................................................6 4.1. Interoperability Scenarios . . . . . . . . . . . . . . . . 5
3.1.1. Downgrade............................................7 5. Compatibility Support . . . . . . . . . . . . . . . . . . . . 6
3.2. Receiving.................................................8 5.1. Address Book . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Display of Downgraded Messages As Received...........9 5.2. Message Mode . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Downgraded Display...................................9 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 8
4. Alternate Addresses...........................................10 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sender...................................................10 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Recipients...............................................11 5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Entry and Display of Alternate Addresses.................11 6. Mailbox Integration . . . . . . . . . . . . . . . . . . . . . 12
4.4. Mailbox Integration......................................12 7. Character Encoding . . . . . . . . . . . . . . . . . . . . . . 12
5. Character Encoding............................................13 8. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Normalization.................................................13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations.......................................14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations...........................................14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments...............................................14 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14
10. References...................................................14
10.1. Normative References....................................14
10.2. Informative References..................................16
Author's Addresses...............................................16
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
[RFC 4952] Overview and Framework for Internationalized Email [RFC6530] Overview and Framework for Internationalized Email
describes changes to electronic mail (email) to fully support describes changes to electronic mail (email) to fully support
internationalized characters. The fundamental change is to remove the internationalized characters. The fundamental change is to remove
ASCII only restriction on email addresses and allow them to contain the ASCII only restriction on email addresses and allow them to
UTF-8 characters. Additional documents provide detailed contain UTF-8 characters. Additional documents provide detailed
specifications for the extensions required to email headers [RFC5335] specifications for the extensions required to email headers [RFC6532]
and to the protocols SMTP [RFC5336], POP [draft-ietf-eai-pop] and and to the protocols SMTP [RFC6531], POP [I-D.ietf-eai-rfc5721bis]
IMAP [draft-ietf-eai-imap-utf8]. and IMAP [I-D.ietf-eai-5738bis].
This document provides guidelines for email clients that support This document provides guidelines for email clients that support
these specifications for Email Address Internationalization (EAI). It these specifications for Email Address Internationalization (EAI).
does not introduce any protocol extensions that are not defined in It does not introduce any protocol extensions that are not defined in
the above documents. It highlights the extensions that are important the above documents. It highlights the extensions that are important
to the design and implementation of email clients and makes a number to the design and implementation of email clients and makes a number
of recommendations intended to improve interoperability and of recommendations intended to improve interoperability and
usability. usability.
2.1. Terminology 3. Terminology
A number of different acronyms are typically used to describe the A number of different acronyms are typically used to describe the
major functional components of email. major functional components of email.
Mail User Agent (MUA) Mail User Agent (MUA)
Message Submission Agent (MSA) Message Submission Agent (MSA)
Message Transfer Agent (MTA) Message Transfer Agent (MTA)
Message Delivery Agent (MDA) Message Delivery Agent (MDA)
Message Store (MS) Message Store (MS)
The architecture of modern email systems can range from simple, with The architecture of modern email systems can range from simple, with
all components running on one server, to very complex, with all components running on one server, to very complex, with
components being distributed across multiple, geographically components being distributed across multiple, geographically
dispersed machines. Nevertheless, the above terminology is generally dispersed machines. Nevertheless, the above terminology is generally
sufficient to represent different architectures from a functional sufficient to represent different architectures from a functional
point of view. For a comprehensive description of email architecture point of view. For a comprehensive description of email architecture
see [draft-crocker-email-arch]. see [RFC5598].
sender -> MUA -> MSA -> MTA sender -> MUA -> MSA -> MTA
... ...
MTA -> MDA -> MS -> PIF -> MUA -> recipient MTA -> MDA -> MS -> PIF -> MUA -> recipient
(where ... represents possible additional MTA relays)
In this context, an "Email Client" is an MUA that has an interface to In this context, an "Email Client" is an MUA that has an interface to
an MSA to send email and an interface to the MS to retrieve email. an MSA to send email and an interface to the MS to retrieve email.
The interface to retrieve mail (PIF) is a POP or IMAP server or The interface to retrieve mail (PIF) is a POP or IMAP server or
direct access to the File system. The MUA also provides a User direct access to the File system. The MUA also provides a User
Interface (UI) that allows an end user to read (display) and write Interface (UI) that allows an end user to read (display) and write
(compose) their email. (compose) their email.
A common email architecture includes the MSA function within the MTA. A common email architecture includes the MSA function within the MTA.
An improved architecture that better addresses security concerns is a An improved architecture that better addresses security concerns is a
separate MSA component as shown here [RFC4409], [RFC5068]. separate MSA component as shown here [RFC6409], [RFC5068].
"UTF8SMTP" is used to indicate email address internationalization as "SMTPUTF8" is used to indicate email address internationalization as
specified by [RFC4952] and related documents. specified by [RFC6530] and related documents.
"ASCII" refers to the strict 7-bit ASCII character set [ASCII]. "ASCII" refers to the strict 7-bit ASCII character set
[ANSI.X3-4.1968].
"UTF-8", Unicode Transformation Format/8-bit is a character encoding "UTF-8", Unicode Transformation Format/8-bit is a character encoding
scheme that can represent any character in the Unicode standard scheme that can represent any character in the Unicode standard
[RFC3629]. It contains ASCII as a subset. [RFC3629]. It contains ASCII as a subset.
"message/global" is an email message that contains UTF-8 characters "message/global" is an email message that contains UTF-8 characters
beyond 7-bit ASCII in message headers and/or body parts [RFC5335]. beyond 7-bit ASCII in message headers and/or body parts [RFC6532].
"message/rfc822" is an email message that contains only 7 bit ASCII "message/rfc822" is an email message that contains only 7 bit ASCII
and does not use any UTF8SMTP extensions. Note that the original and does not use any SMTPUTF8 extensions. Note that the original
message (as composed by the user) may contain non-ASCII characters message (as composed by the user) may contain non-ASCII characters
that have been encoded into ASCII using IDNA [RFC3490], MIME body that have been encoded into ASCII using IDNA [RFC5890], MIME body
encoding [RFC2045] or MIME header encoding [RFC2047]. encoding [RFC2045] or MIME header encoding [RFC2047].
3. Version Interoperability 4. Interoperability
Not all the components in Internet email systems will get upgraded to Internationalized Email is not compatible with legacy email systems,
UTF8SMTP at the same time. There will be a transition period where those based on prior Internet email standards [RFC5321], [RFC5322].
upgraded components should be backwards compatible with traditional Non-ASCII email addresses cannot be submitted in legacy SMTP commands
email components. like MAIL FROM or RCPT TO. In addition the Internationalized Email
standard does not include a method to "downgrade" message/global to
message/rfc822.
The following table characterizes the most typical (but not all the An Internationalized message cannot be transmitted via SMTP if the
possible) email paths between users in different organizations or receiving MTA does not announce SMTPUTF8 in response to EHLO. There
enterprises (E1, E2, etc.) and highlights the boundaries where are two failure cases that an email client may have to handle
incompatibilities will occur most frequently. described in Section 3.2 of [RFC6531].
Cases where email does not cross a jurisdictional boundary between a) If the client is submitting a message to an MSA that does not
sender and receiver are not shown. This includes email between users support SMTPUTF8, the message will be rejected.
within the same organization and email between users in different
organizations who use the same third party mail service.
| Sending |Receiving b) If the MSA does support SMTPUTF8 but a downstream MTA does not,
Case| MUA |MSA |MTA...MTA |MTA...MTA |MDA |MUA | then the mail will bounce. That is, a delivery status notification
----+-----+----+----------+----------+----+----+ (DSN) that the mail could not be delivered will be sent back to the
1 | E1------------------|E2--------------> | sender.
2 | E1--|E2-------------|E3-------------|E4 |
3a | E1--|E2-------------|E3--------------> |
3b | E1------------------|E2-------------|E3 |
It is assumed in all cases that SMTP mail between MTAs uses DNS. Incompatibility between Internationalized email and legacy systems is
Lookup of the MX record for the destination domain means that there expected to be important initially during a transition period but
is only one boundary of incompatibility between MTAs. less important over time as more email systems upgrade to support the
SMTPUTF8 extensions. To the extent that this incompatibility is
deemed important at the time an implementation is undertaken, the
email client should provide methods to prevent or at least minimize
these failures.
Case 1 represents the larger organizations and expert users who 4.1. Interoperability Scenarios
manage their own email infrastructure. In these environments there
will likely be a coordinated effort to upgrade all components of the
email system together. Each organization typically has several MTAs
that act as virus scanners, spam filters, mail relays and gateways to
manage mail across different divisions and locations of the
organization. The boundary of incompatibility is the MTA between the
organizations. If both enterprises support UTF8SMTP, they will be
able to send Internationalized email without the risk of
incompatibility or Downgrade.
For large organizations that allow end users to select and install The following scenarios cover the different cases of sending mail
their own email client software, the MUA boundaries are also possible from an Internationalized server to a legacy server.
incompatibilities. Users in this category would actually be
represented by cases 2 and 3.
Case 2 represents the home user and small to medium sized businesses 'I' indicates an Internationalized address (a non-ASCII address on an
who use the email infrastructure of a third party, such as an ISP Internationalized mail server).
(Internet Service Provider) or an outsourced provider. The mail
provider has an infrastructure similar to Case 1. The boundaries of
incompatibility are at the MUA and between the MTAs of the email
providers.
Case 3 covers mixed cases where a user with an outsourced email 'IA' indicates an ASCII address on an Internationalized server.
service sends to or receives from a user in an organization that
manages its own email infrastructure. The boundaries of
incompatibility correspond to Cases 1 and 2. These cases may also
apply to some applications within larger organizations. For example,
cell phone email may utilize a mail gateway from a third party
provider even though the rest of the email infrastructure is in-
house.
For an MUA, the boundaries where version compatibility is most likely 'LA' indicates an address on a Legacy mail server, which must be
to occur is between home/small office users and their email ASCII.
providers. The worst case scenario is Case 2, where three boundaries
of incompatibility are possible between sender and recipient.
3.1. Sending Case 1. The simple compatibility case
For an MUA that supports UTF8SMTP, there is a matrix of possibilities From: IA1 (or LA1)
based on whether the email envelope and the message contain non-ASCII To: LA2
characters and whether the MSA supports the UTF8SMTP extensions or Subject: ...
not. The following table shows all the possible combinations. Body ...
Case|Envelope |Message |MSA is |MUA sends The message will be successfully sent as long as the email client
| | |UTF8SMTP| sends message/rfc822 rather than message/global.
----+----------+---------+--------+-----------------
1 |UTF8SMTP |global |Yes |UTF8SMTP
2 |UTF8SMTP |rfc822 |Yes |UTF8SMTP
3 |ASCII |global |Yes |UTF8SMTP
4 |ASCII |rfc822 |Yes |Traditional email
5 |UTF8SMTP |global |No |Reject/Downgrade
6 |UTF8SMTP |rfc822 |No |Reject/Downgrade
7 |ASCII |global |No |Reject/Downgrade
8 |ASCII |rfc822 |No |Traditional email
----+----------+---------+--------+-----------------
The Envelope and the Message type are considered separately because Case 2. The simple incompatibility case
the Envelope may contain, for example, email addresses that are all
ASCII but the Subject or other header fields in the Message may
contain non-ASCII (Cases 3, 7).
Cases 2 and 6 are unusual since a UTF8SMTP address in the envelope is From: I1
usually also in the message header. An example of when this can occur To: LA2
is when an rfc822 message is forwarded with server-based forwarding Subject: ...
(as with a .forward file) to a UTF8SMTP address. Body ...
Cases 1-3 The message will be rejected by the MSA or will bounce from a
downstream SMTP server.
Messages containing non-ASCII characters SHOULD be sent using the If user I1 also has an ASCII email address IA1 or LA1, there may be a
UTF8SMTP extensions in preference to older encoding methods, such as simple workaround. If the email client supports multiple email
IDNA [RFC3490] and MIME header encoding [RFC2047]. If the message accounts, the user just has to switch the From address to an ASCII
body contains non-ASCII characters, it SHOULD be sent using 8BITMIME address and it becomes Case 1.
[RFC1652] instead of MIME body encoding such as quoted-printable or
base64 [RFC2045].
Cases 5-7 Case 3. The general incompatibility cases
This could be considered a configuration error. If the MSA does not The general case is a mix of Internationalized and legacy addresses.
support UTF8SMTP, the user should upgrade the MSA, or switch to an While many combinations are possible, the two cases below essentially
email provider that supports UTF8SMTP. cover all possibilities.
Upgrading the MSA is a reasonable approach in the case of larger From: I1
organizations, where an IT group would be expected to synchronize MUA To: LA2
and MSA versions. However, home/small office users may end up in this Cc: I3
situation when they have a computer that came with UTF8SMTP email
client software and their Internet Service Provider (ISP) does not
support UTF8SMTP.
In these cases, the MUA MUST NOT submit a message with UTF8SMTP The message will be sent to I3 but it will bounce from LA2.
headers if the MSA does not support the UTF8SMTP extensions
[RFC5336]-Section 3.2.
If the message is not submitted, some guidance should be provided to Switching the From address to an ASCII address as in Case 2 is not a
the user about how to correct the problem. It may also be desirable solution, as the following case demonstrates.
to save this status and highlight it for the user before they compose
a message. This would provide advance warning that internationalized
email cannot be sent.
3.1.1. Downgrade From: IA1 (or LA1)
To: LA2
Cc: I3
The MUA MAY support the "downgrade" option, which is specified as an This message will bounce from LA2 since the address in the Cc header
option for all email components MUA, MSA, MTA and MDA. Downgrade cannot be transmitted to a legacy server.
builds a message with all ASCII headers so that it is compatible with
email components that don't support the UTF8SMTP extensions.
Downgrade basically redirects mail from a UTF8SMTP address to an
Alternate ASCII Address [RFC5504].
It is not recommended that the MUA support Downgrade for cases 5-7. In these cases, users will likely send the message twice in order to
The user should be encouraged to correct the configuration and reach all intended recipients. First, to the original list and then
upgrade the MSA or switch email providers in order to get support for using an ASCII address to the bounced recipients.
internationalized email.
The following shows an example of downgrading a "From" header with a If users know beforehand which addresses are on legacy servers, they
non-ASCII "Display-Name", non-ASCII email address and ASCII Alternate can avoid bounced messages by removing those addresses, but they
Address. still have to send a second email to reach recipients that were
removed.
Original header: 5. Compatibility Support
From: Display-Name <eai-addr <alt-ascii-addr>> An email client can provide support to minimize the incompatibility
problems outlined in Section 4. There may be several ways to do
this. Following are guidelines on some of the ways that this can be
accomplished.
Downgrade would change the From address to the Alternate Address and At the very least, to provide basic compatibility between
preserve the EAI address in a new "Downgraded-From" header. Internationalized and legacy systems, if all email addresses in the
SMTP envelope and the message headers are ASCII, then a message/
rfc822 should be sent (Case 1 above).
From: =?UTF-8?Q?Display-Name?= <alt-ascii-addr> For Case 2, the email client should support multiple email accounts
Downgraded-From: =?UTF-8?Q?Display-Name?= and allow the user to switch the From address at any time during
=?UTF-8?Q?<eai-addr?= <alt-ascii-addr>> composition of the message.
Note that the Display-Name in the From header is encoded using For Case 3, several mechanisms may be required to provide
traditional MIME email standards [RFC2047] with charset UTF-8. The compatibility support. These are outlined in the following sub-
MUA at the recipient end does not need to support the UTF8SMTP sections.
extensions to decode and display the original name.
Complete examples of Downgrade are shown in the Appendix of 5.1. Address Book
[RFC5504].
3.2. Receiving Each contact in the address book should be able to have several email
addresses, each of which is configured to be either an
Internationalized or a Legacy address.
The matrix of possibilities is based on the email message type and The user may not necessarily know if an ASCII address they enter in
whether IMAP/POP and the MUA support the UTF8SMTP extensions or their address book is on a legacy server or not. If it is configured
not(Y/N) [draft-ietf-eai-imap-utf8], [draft-ietf-eai-pop]. as an Internationalized address and that turns out to be wrong, then
email sent to that contact may bounce. The user can then re-
configure the address as Legacy so the email client can provide
warnings of a possible bounce on subsequent messages.
Case|Original|Spooled |IMAP|Transfered|MUA|Displayed 5.2. Message Mode
|Message |Message |/POP|Message | |Message
----+--------+----------+----+----------+---+----------
1 |global |global | Y |global | Y |global
2 |global |global | Y |downgraded| N |downgraded
3 |global |global | N | - |Y/N| -
4a |global |downgraded|Y/N |downgraded| Y |downgraded
4b |global |downgraded|Y/N |downgraded| Y |global
5 |global |downgraded|Y/N |downgraded| N |downgraded
6 |rfc822 |rfc822 |Y/N |rfc822 |Y/N|rfc822
----+--------+----------+----+----------+---+----------
Note that the cases in which the recipient receives the message as Message composition should have "Message Mode" option to specify
sent are 1 (all UTF8SMTP), 6 (traditional email) and 4b (downgraded "Internationalized Mode" or "Legacy Mode".
conversion display).
In cases 2, 4a and 5 the recipient receives a downgraded message. If the type of each address in the headers does not conform to the
message mode, then the user is given a warning about those addresses
that don't match the mode. In a graphical user interface this might
be done by setting such addresses to a different color such as red.
Case 2 The user would typically first change the message mode to see if the
warnings disappear.
IMAP or POP must support Downgrade for this configuration. Direct When the mode is switched, the email client switches addresses in
maildrop access for message/global is prohibited if the MUA does not message header fields to match the mode, selecting from the list of
support UTF8SMTP. addresses in each contact.
Case 3 There are cases where both modes provide warnings (see Example 5
below). In these cases, the user can remove the addresses that don't
conform to the mode.
This is a configuration error. If IMAP or POP does not support For Internationalized mode, the user has an additional option to send
UTF8SMTP, then it is not possible for the MUA to receive global the message anyway, without removing flagged addresses. They would
messages. have to handle bounced messages from Legacy servers later. The
option to send anyway cannot be provided in Legacy mode, as it is not
possible to compose a message/rfc822 if any sender or recipient
address is not ASCII.
Cases 4-6 Where both modes provide warnings, users will likely want to send the
message in each mode in order to reach all recipients. The email
client should make it easy to do this. There are many possible
designs to accomplish this. The following is one example.
An ASCII message may be received from either a UTF8SMTP or a non- An option is provided when composing email to add a second message
UTF8SMTP interface. header section in the other mode that allows the user to move
addresses between sections. This is in addition to making individual
changes to address headers as in normal email composition. The
Subject and Body are common so the user can compose a single message
but have it sent in the two different modes to different recipients.
It is possible that the original message was a UTF8SMTP message that Following is an example of this for Case 3 above.
got downgraded to ASCII in transit. A message can be identified as
downgraded because it will have one or more headers that are prefixed
with "Downgraded-".
(Case 4a) A UTF8SMTP compliant MUA MAY display a downgraded message ---------------------------------------------
as received, or (Case 4b) it MAY apply a conversion to restore the Legacy Internationalized
information contained in the "Downgraded-" headers as specified in From: IA1 From: I1
[draft-ietf-eai-downgraded-display]. To: LA2 <---> To:
Cc: <---> Cc: I3
---------------------------------------------
Subject: ...
Body: ...
---------------------------------------------
3.2.1. Display of Downgraded Messages As Received 5.3. Message Format
Cases 2, 4a, 5 In Internationalized Mode, mail should be sent as message/global.
The aim of Internationalized Email is 8 bit clean messages using
UTF-8 encoding to represent Unicode characters in header fields and
the message body.
When displaying a downgraded message as received, UTF8SMTP addresses In Legacy Mode, mail must be sent as message/rfc822. This may
that had Alternate Addresses in the original email will not be shown include non-ASCII characters that are encoded into ASCII using MIME
in the headers when reading, replying or forwarding email. Only the body encoding [RFC2045] or MIME header encoding [RFC2047]. Any
Alternate Addresses will be shown. encoding should be based on UTF-8. In the interest of
interoperability, charsets other than UTF-8 are prohibited in mail
addresses and message headers described in Section 7.1 of [RFC6530].
If a UTF8SMTP address in the original email did not have an Alternate 5.4. Error Handling
Address, then the UTF8SMTP address will be displayed in an empty
group (using ":;") to note that a UTF8SMTP address has been removed
[RFC5504]-Section 5.1.7. This may appear in any header such as To: or
Cc: as
Display-Name Internationalized Address eai-addr Removed:; If a message is rejected by the MSA with a response code that
indicates incompatibility with legacy email described in Section 3.2
of [RFC6531], the compose window should be kept open so that the user
can make changes and retry. The email client should provide guidance
to the user about switching the Message Mode, reconfiguring the type
of an address in the address book or adding an ASCII legacy address
for a contact in the address book.
If a user replies to an email with such a group, many MUAs do not Similarly, if a message bounces, the email client could parse the
handle this correctly. Observed behavior has ranged from refusing to delivery status notifications and message disposition notifications
send the message due to an "invalid address", or attempting to send [RFC6533] to determine if the failure was a compatibility problem and
to the group and reporting a DSN failure, or deleting the group if so, which addresses caused the problem.
altogether. The user may resort to removing the group in order to get
around these problems. Recipients of such email will not have an
accurate record of who the original recipients were. MUAs should be
upgraded to support groups, as defined in [RFC2822]-Section 3.4.
Note that even if an MUA does not support UTF8SMTP (Cases 2, 5), it 5.5. Examples
is able to decode and display "Downgraded-" header fields because
Downgrade uses MIME encoding [RFC 2047][RFC 2231].
3.2.2. Downgraded Display The following examples illustrate most of the different possible
cases.
Case 4b Suppose the user (Sender) has set up the following email account
containing two email addresses, an Internationalized address and an
ASCII address on an Internationalized server.
Support for conversion of "Downgraded-" headers is separate from Sender: I0, IA0
support for Downgrade. An MUA MAY support none or one or both of
these options.
Conversion replaces the Alternate Addresses in email headers with the Examples are not provided for the following cases:
original UTF8SMTP addresses that were recorded in the "Downgraded-"
headers.
If the MUA supports conversion of "Downgraded-" headers, the a) Sender: I0, LA0
following considerations should be taken into account:
1. If the MUA receives mail from an IMAP/POP server, the conversion If the Sender has both Internationalized and Legacy addresses, then
may have already been done but the message will still contain this is equivalent to the above.
"Downgraded-Mail-From" and "Downgraded-Rcpt-To" headers.
2. Conversion of Downgraded headers is not a reliable, reversible b) Sender: I0
process.
3. There is no authenticated binding between the original UTF8SMTP and If the Sender has only Internationalized addresses, then it cannot
the downgraded Alternate Address. This introduces various security send Legacy messages. The email client cannot provide an option to
concerns [draft-ietf-eai-downgraded-display]-Section 5. switch the Message Mode to Legacy.
4. Alternate Addresses c) Sender: LA0
Alternate Addresses MAY be required for Downgrade, which may occur If the Sender has only accounts on Legacy servers, then it cannot
anywhere on the path that a non-UTF8SMTP email component is send Internationalized messages. The email client cannot provide an
encountered [RFC5336]-Section 3.2. If Downgrade cannot be done in option to switch the Message Mode to Internationalized.
these cases, the email may be returned ("bounced").
Downgrade is expected to be important initially during a transition The address book has the following contacts with email addresses.
period but less important over time as more email systems upgrade to
the UTF8SMTP extensions. To the extent that Downgrade is deemed
important at the time an implementation is undertaken, Alternate
Addresses [RFC5336] SHOULD be supported.
4.1. Sender Contact1: I1, IA1
Contact2: I2
Contact3: IA3
Contact4: LA4
An Alternate Address for the sender MAY be provided, so that after Example 1:
Downgrade there is a return path for delivery status notifications
(DSN).
Email addresses are generally created and set up on the server side, From: Sender
not by the MUA. An email provider may wish to set up an Alternate To: Contact1
Address automatically for each UTF8SMTP account that is created. CC: Contact2
While in some environments it may be difficult or unfamiliar for a
user to enter ASCII characters, selecting an Alternate Address for
the user's UTF8SMTP address SHOULD NOT be done automatically.
Automatic generation often results in usability problems when names
that are difficult to read or pronounce are produced. Any generation
of an Alternate Address should be presented to the user as a
suggestion that can be changed.
A UTF8SMTP implementation of an MSA/MTA may provide the ability to This message can be sent in Internationalized mode.
bind an Alternate Address to a UTF8SMTP address. In this case, the
MUA may not need to provide Alternate Addresses for the sender.
However, users may wish to use different Alternate Addresses than In Legacy mode the email client would flag Contact2, who does not
those created for their UTF8SMTP email account, such as when they have an ASCII address.
already have an ASCII address on another email system.
In general, the MUA SHOULD allow users to save an Alternate Address Example 2:
for the sender's UTF8SMTP address, typically under "Account"
settings. The configured value of this field is used as an ALT-
ADDRESS parameter on the SMTP command "MAIL FROM:" and in From:
message headers.
4.2. Recipients From: Sender
To: Contact1
CC: Contact3
There are two cases where Downgrade can occur: This message can be sent in either Internationalized or Legacy mode.
1. Mail sent from a UTF8SMTP user to a non-UTF8SMTP user. Example 3:
2. Mail sent from a UTF8SMTP user to a UTF8SMTP user where a non- From: Sender
UTF8SMTP component is on the path. To: Contact1
CC: Contact4
Downgrade in Case 1 provides backwards compatibility with recipients This message cannot be sent in Internationalized mode. Contact4
who are not UTF8SMTP. In this case, the recipient has an ASCII would be flagged since it is not on an Internationalized server.
address and an Alternate Address is not required.
In Case 2, Downgrade REQUIRES an Alternate Address for the recipient. This message can be sent in Legacy mode.
However, this case could be considered a configuration error. As
reviewed in section 3, when DNS is used to determine the transport
path from sender to receiver, mail does not get routed through an
email relay of a third party. If the sender and recipient both have
UTF8SMTP addresses, then one of their MTA mail relays was not
upgraded to UTF8SMTP. Users should only be set up with UTF8SMTP
addresses if all the mail relays within the organization support
UTF8SMTP.
If it is decided that it is important to support Downgrade for Case Example 4:
2, then the MUA SHOULD allow the user to enter and edit an optional
Alternate Address wherever a UTF8SMTP recipient address can be
entered and edited. This would typically be message headers when
composing email and entries stored in an "Address Book".
The recipient Alternate Address, if provided in an email composition, From: Sender
is used as an ALT-ADDRESS parameter on the SMTP command "RCPT TO:" To: Contact2
and in message headers where the recipient address is used. CC: Contact3
4.3. Entry and Display of Alternate Addresses This message can be sent in either Internationalized mode or Legacy
mode.
The following applies to both sender and recipient Alternate Example 5:
Addresses.
Alternate Address fields MUST NOT contain non-ASCII addresses. From: Sender
To: Contact2
CC: Contact4
If the main email address is not UTF8SMTP, then entering an address This message cannot be sent in either mode.
in the Alternate Address field SHOULD NOT be allowed [RFC5336]-
Section 3.4.
The following is one example of how to display Alternate Addresses, Internationalized mode would flag Contact4 which is on a Legacy
by using the UTF8SMTP "double angle bracket" format defined in server. The user can remove Contact4 or use the send anyway option.
[RFC5335]-Section 4.4:
Display-Name <eai-addr <alt-ascii-addr>> Legacy mode would flag Contact2 who does not have an ASCII address.
The user would have to remove Contact2 in order to send this message.
It would be helpful to display an indicator on UTF8SMTP email 5.6. Limitations
addresses that do not have an Alternate Address. This would alert the
user to the possibility that the message may bounce. In the example
above, an empty double bracket could be displayed in a highlighted
color, reminding the user to provide the missing alternate address,
as in
Display-Name <eai-addr < >> In summary, the guidelines outlines in Section 4 and Section 5 will
provide the following compatibility solutions:
When sending the message, the MUA would have to remove empty double 1. When there is an ASCII address for all contacts in the message,
angle brackets. then a single legacy compatible message can be sent to all
recipients.
Since Downgrade and Alternate Addresses may not be widely used after 2. When some contacts in the message do not have an ASCII address
a transition period, such an indicator should be configurable so that and some have only ASCII addresses on legacy servers, then the
a user is able to turn it off. message can be split into two. One message is sent as an
Internationalized message to recipients on Internationalized servers.
The other is sent as a legacy compatible message to recipients on
legacy servers.
4.4. Mailbox Integration These guidelines have a number of limitations.
If Alternate Addresses are supported, it may be desirable to combine a) Unknown Address Types
mail for the UTF8SMTP address and the Alternate Address into one
mailbox so that all related mail can be managed in one place.
For example, if a message is sent from a UTF8SMTP address to a list Message Mode is effective only if users are fairly disciplined about
of recipients, some of the messages may be downgraded. Replies to keeping addresses in their address book and configuring the type
downgraded messages will be delivered to the Alternate Address, so correctly as Internationalized or Legacy.
all the replies to a message may be split across two different
mailboxes.
Mailbox integration is not generally handled by an MUA. Many existing When replying to an email, the message may have addresses that are
MTAs/MDAs can do this with a mail "alias" or "forward". One address not in the address book. The user may also enter addresses directly
is selected as the primary mailbox and the other address is during message composition that are not in the address book.
configured as an alias.
Forwarding allows an email address on one email provider to be The email client may determine by inspection that some addresses are
integrated into the mailbox on another email provider. Mailbox Internationalized. If an address contains any non-ASCII character,
integration can make it easier for users to migrate from an old email then it must be Internationalized. However, an ASCII address may be
system that does not support UTF8SMTP to a newer one that does. All on either an Internationalized server or a Legacy server and there is
they need to do is forward their old email address to an Alternate no way software can determine this automatically.
Address that was created on their new mail service.
5. Character Encoding In such cases, it may be useful for the email client to flag unknown
address types in a message so that the user is not lead to believe
that the message will not bounce just because there were no
incompatibility warnings.
b) Address Removal
When email addresses are removed from a message to meet compatibility
requirements, recipients do not see everyone who was intended to be
part of the conversation. The email client can provide the address
of removed recipients by using an empty group. This technique is
described in Section 3.1.8 of [I-D.ietf-eai-popimap-downgrade].
This is not an ideal solution, since replies to the message will not
reach everyone intended. But at least it provides the necessary
contact information to recipients who may be able to use other
methods to reply to all intended.
6. Mailbox Integration
If more than one email address is used for the sender user, emails
may arrive at different email accounts. There are several ways to
provide mailbox integration so the user is able to view all mail in
one location, such as a single 'Inbox' folder.
If integration is done on the server, through the use of aliases,
then the email client does not need to do anything. All mail will be
received at the client from one address.
The email client should provide mailbox integration for cases where
server side integration is not available and for more flexibility on
the part of the user. Many email clients already provide a
convenient way to manage multiple email accounts.
An option to view all mail from a group of accounts in one integrated
folder should also be provided.
7. Character Encoding
Email message bodies may be composed and displayed using many Email message bodies may be composed and displayed using many
different character encoding schemes. Numerous character encodings different character encoding schemes. Numerous character encodings
have been developed over time in order to best represent different have been developed over time in order to best represent different
language scripts. In recent years there has been a trend to prefer language scripts. In recent years there has been a trend to prefer
Unicode as a "universal" character set and UTF-8 as the preferred Unicode as a "universal" character set and UTF-8 as the preferred
encoding method. encoding method.
A good general principle to follow is to minimize character A good general principle to follow is to minimize character
conversions. This will reduce the chance that the received message is conversions. This will reduce the chance that the received message
displayed differently from how it was composed. Displaying received is displayed differently from how it was composed. Displaying
mail SHOULD use the character encoding of the received mail. received mail SHOULD use the character encoding of the received mail.
Since older MUAs may not be able to parse UTF-8, the MUA SHOULD try Since older MUAs may not be able to parse UTF-8, the MUA SHOULD try
to reply to mail using the character encoding of the received mail. to reply to mail using the character encoding of the received mail.
This may not be possible if the sender adds new characters that This may not be possible if the sender adds new characters that
cannot be encoded in the original encoding. For example, if the cannot be encoded in the original encoding. For example, if the
received message is encoded in ISO-2022-JP and characters in ISO- received message is encoded in ISO-2022-JP and characters in ISO-
8859-1 are added to the message, the text cannot be carried in ISO- 8859-1 are added to the message, the text cannot be carried in ISO-
2022-JP and conversion to UTF-8 may be the best solution. 2022-JP and conversion to UTF-8 may be the best solution.
For new mail, A UTF8SMTP compliant MUA SHOULD use UTF-8 as the For new mail, A SMTPUTF8 compliant MUA SHOULD use UTF-8 as the
default encoding if the message type is global or if the envelope default encoding if the message type is global or if the envelope
contains non-ASCII addresses. If email clients utilize this default, contains non-ASCII addresses. If email clients utilize this default,
character conversions will be minimized and there will be less chance character conversions will be minimized and there will be less chance
that someone will receive mail in an unrecognized encoding. that someone will receive mail in an unrecognized encoding.
If the message type is rfc822, other considerations may apply, such If the message type is rfc822, other considerations may apply, such
as using the system locale/language. as using the system locale/language.
Notwithstanding the above, there may be cases where the default does Notwithstanding the above, there may be cases where the default does
not work well. There SHOULD be options for the user to reset the not work well. There SHOULD be options for the user to reset the
default character encoding. There SHOULD also be options to change default character encoding. There SHOULD also be options to change
the encoding when reading or writing individual email messages. the encoding when reading or writing individual email messages.
6. Normalization 8. Normalization
Different sequences of UTF-8 characters may represent the same thing. Different sequences of UTF-8 characters may represent the same thing.
Normalization is a process that converts all canonically equivalent Normalization is a process that converts all canonically equivalent
sequences to a single unique form. sequences to a single unique form.
For example, in the Japanese environment, special consideration is Normalization of email headers is specified in Section 3.1 of
needed for the "@" symbol used to separate the local name from the [RFC6532]. The MUA SHOULD normalize all email addresses in the
domain name in email addresses. Normalization is necessary to replace envelope and message headers.
FULLWIDTH COMMERCIAL AT (U+FF20) with ASCII "@", COMMERCIAL AT
(U+0040) for proper parsing of email addresses.
Normalization of email headers is specified in [RFC 5335]-Section
4.1. The MUA SHOULD normalize all email addresses in the envelope and
message headers.
If the MUA saves email addresses (such as in an address book), they
SHOULD be stored in normalized form. For example, an email address
entered as
user@host*domain
where * represents IDEOGRAPHIC FULL STOP (U+3002), as used in some
Asian languages, would display as
user@host.domain
For message bodies that contain UTF-8 characters (message/global), For message bodies that contain UTF-8 characters (message/global),
the "Net-Unicode" standardized text transmission format specified in the "Net-Unicode" standardized text transmission format specified in
[RFC5198] SHOULD be followed. It covers both normalization and [RFC5198] SHOULD be followed. It covers both normalization and
control characters that may affect display of text. control characters that may affect display of text.
7. Security Considerations If the MUA saves email addresses (such as in an address book), they
SHOULD be stored in normalized form.
Other normalizations may be needed in specific language environments.
For example, in the Japanese environment, special considerations are
needed for the "@" and "." symbols. Most Japanese input methods
convert "@" to FULLWIDTH COMMERCIAL AT (U+FF20) and "." to either
IDEOGRAPHIC FULL STOP (U+3002) or FILLWIDTH FULL STOP (U+FF0E). In
email addresses, "@" is needed to separate the local name from the
domain name and "." to separate domain name labels. Normalization is
necessary to replace FULLWIDTH COMMERCIAL AT (U+FF20) with ASCII "@",
IDEOGRAPHIC FULL STOP (U+3002) with ASCII "." and FILLWIDTH FULL STOP
(U+FF0E) with ASCII ".".
9. Security Considerations
This document does not introduce any security considerations beyond This document does not introduce any security considerations beyond
those already covered by the normative references for Email Address those already covered by the normative references for Email Address
Internationalization (EAI). Internationalization (EAI).
8. IANA Considerations 10. IANA Considerations
IANA changes are covered by the normative references for Email IANA changes are covered by the normative references for Email
Address Internationalization (EAI). Address Internationalization (EAI).
9. Acknowledgments 11. Acknowledgments
10. References
10.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.
ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains
definitive for the Internet.
[draft-ietf-eai-downgraded-display] Fujiwara, K., "Displaying 12. Normative References
Downgraded Messages for Email Address
Internationalization", draft-ietf-eai-downgraded-display-01
(work in progress), March 2009.
[draft-ietf-eai-imap-utf8] Resnick, P. and Newman, C., "IMAP Support [ANSI.X3-4.1968] American National Standards
for UTF-8", draft-ietf-eai-imap-utf8-04 (work in progress), Institute, "USA Code for
June 2009. Information Interchange",
ANSI X3.4, 1968.
[draft-ietf-eai-pop] Newman, C. and Gellens, R., "POP3 Support for [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S.
UTF-8", draft-ietf-eai-pop-06 (work in progress), June Shen, "IMAP Support for UTF-8",
2009. draft-ietf-eai-5738bis-09 (work in
progress), August 2012.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [I-D.ietf-eai-popimap-downgrade] Fujiwara, K., "Post-delivery
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", Message Downgrading for
RFC 1652, July 1994. Internationalized Email Messages",
draft-ietf-eai-popimap-downgrade-07
(work in progress), August 2012.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J.,
Extensions (MIME) Part One: Format of Internet Message and K. Fujiwara, "POP3 Support for
Bodies", RFC 2045, November 1996. UTF-8",
draft-ietf-eai-rfc5721bis-07 (work
in progress), July 2012.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2045] Freed, N. and N. Borenstein,
Part Three: Message Header Extensions for Non-ASCII Text", "Multipurpose Internet Mail
RFC 2047, November 1996. Extensions (MIME) Part One: Format
of Internet Message Bodies",
RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2047] Moore, K., "MIME (Multipurpose
Requirement Levels", BCP 14, RFC 2119, March 1997. Internet Mail Extensions) Part
Three: Message Header Extensions
for Non-ASCII Text", RFC 2047,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2119] Bradner, S., "Key words for use in
Part Three: Message Header Extensions for Non-ASCII Text", RFCs to Indicate Requirement
RFC 2047, November 1996. Levels", BCP 14, RFC 2119,
March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC3629] Yergeau, F., "UTF-8, a
2001. transformation format of ISO
10646", STD 63, RFC 3629,
November 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC5068] Hutzler, C., Crocker, D., Resnick,
"Internationalizing Domain Names in Applications (IDNA)", P., Allman, E., and T. Finch,
RFC 3490, March 2003. "Email Submission Operations:
Access and Accountability
Requirements", BCP 134, RFC 5068,
November 2007.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [RFC5198] Klensin, J. and M. Padlipsky,
STD 63, RFC 3629, November 2003. "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for [RFC5321] Klensin, J., "Simple Mail Transfer
Internationalized Email", RFC 4952, July 2007. Protocol", RFC 5321, October 2008.
[RFC5198] Klensin, J. and Padlipsky, M., "Unicode Format for Network [RFC5322] Resnick, P., Ed., "Internet Message
Interchange", RFC 5198, March 2008. Format", RFC 5322, October 2008.
[RFC5335] Yeh, J., "Internationalized Email Headers", RFC 5335, [RFC5598] Crocker, D., "Internet Mail
November 2008. Architecture", RFC 5598, July 2009.
[RFC5336] Yao, J. and W. Mao, "SMTP extension for internationalized [RFC5890] Klensin, J., "Internationalized
email address", RFC 5336, September 2008. Domain Names for Applications
(IDNA): Definitions and Document
Framework", RFC 5890, August 2010.
[RFC5504] Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for [RFC6409] Gellens, R. and J. Klensin,
Email Address Internationalization", RFC 5504, March 2009. "Message Submission for Mail",
STD 72, RFC 6409, November 2011.
10.2. Informative References [RFC6530] Klensin, J. and Y. Ko, "Overview
and Framework for Internationalized
Email", RFC 6530, February 2012.
[draft-crocker-email-arch] D. Crocker, "Internet Mail Architecture", [RFC6531] Yao, J. and W. Mao, "SMTP Extension
draft-crocker-email-arch-14 (work in progress), June 2009. for Internationalized Email",
RFC 6531, February 2012.
[RFC4409] Gellens, R. and Klensin, J., "Message Submission for Mail", [RFC6532] Yang, A., Steele, S., and N. Freed,
RFC 4409, 2006. "Internationalized Email Headers",
RFC 6532, February 2012.
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E. and [RFC6533] Hansen, T., Newman, C., and A.
Finch, T., "Email Submission Operations: Access and Melnikov, "Internationalized
Accountability Requirements", RFC 5068, November 2007. Delivery Status and Disposition
Notifications", RFC 6533,
February 2012.
Authors' Addresses Authors' Addresses
Ernie Dainow Ernie Dainow
Afilias Canada Afilias Canada
4141 Yonge Street 4141 Yonge Street
Toronto, Ontario M2P 2A8 Toronto, Ontario M2P 2A8
Canada Canada
Email: edainow@ca.afilias.info Phone:
EMail: edainow@afilias.info
Kazunori Fujiwara Kazunori Fujiwara
JPRS Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Email: fujiwara@jprs.co.jp Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp
 End of changes. 158 change blocks. 
502 lines changed or deleted 473 lines changed or added

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