Network Working Group
Email Address Internationalization                             E. Dainow
Internet-Draft
(EAI)                                                            Afilias
Intended status: Experimental
Internet-Draft                                               K. Fujiwara
Expires: January 8, 2010
Intended status: Informational                                      JPRS
                                                           July 8, 2009
Expires: March 11, 2013                                September 7, 2012

             Guidelines for Internationalized Email Clients
                      draft-ietf-eai-email-clients-00
                    draft-ietf-eai-email-clients-01

Abstract

   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 This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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. March 11, 2013.

Copyright Notice

   Copyright (c) 2009 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This  Code Components extracted from this document provides some guidelines for email clients that support
   Email Address Internationalization (EAI) must
   include Simplified BSD License text as outlined described in RFC 4952. A
   number of interoperability cases between different versions Section 4.e of email
   components are reviewed. Recommendations are made to improve
   interoperability and usability and to minimize discrepancies between
   the display of composed Trust Legal Provisions and received email are provided without warranty as
   described in different language
   environments. the Simplified BSD License.

Table of Contents

   1.  Conventions used in this document..............................3 document  . . . . . . . . . . . . . .  3
   2. Introduction...................................................3
      2.1. Terminology...............................................3  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Version Interoperability.......................................4
      3.1. Sending...................................................6
         3.1.1. Downgrade............................................7
      3.2. Receiving.................................................8
         3.2.1. Display of Downgraded Messages As Received...........9
         3.2.2. Downgraded Display...................................9  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. Alternate Addresses...........................................10  Interoperability . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1. Sender...................................................10
      4.2. Recipients...............................................11
      4.3. Entry and Display of Alternate Addresses.................11
      4.4. Mailbox Integration......................................12  Interoperability Scenarios . . . . . . . . . . . . . . . .  5
   5. Character Encoding............................................13  Compatibility Support  . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Address Book . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Message Mode . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Message Format . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Error Handling . . . . . . . . . . . . . . . . . . . . . .  8
     5.5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.6.  Limitations  . . . . . . . . . . . . . . . . . . . . . . . 10
   6. Normalization.................................................13  Mailbox Integration  . . . . . . . . . . . . . . . . . . . . . 12
   7. Security Considerations.......................................14  Character Encoding . . . . . . . . . . . . . . . . . . . . . . 12
   8. IANA Considerations...........................................14  Normalization  . . . . . . . . . . . . . . . . . . . . . . . . 13
   9. Acknowledgments...............................................14  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. References...................................................14
      10.1. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   12. Normative References....................................14
      10.2. Informative References..................................16
   Author's Addresses...............................................16 References . . . . . . . . . . . . . . . . . . . . . 14

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   [RFC 4952]

   [RFC6530] Overview and Framework for Internationalized Email
   describes changes to electronic mail (email) to fully support
   internationalized characters.  The fundamental change is to remove
   the ASCII only restriction on email addresses and allow them to
   contain UTF-8 characters.  Additional documents provide detailed
   specifications for the extensions required to email headers [RFC5335] [RFC6532]
   and to the protocols SMTP [RFC5336], [RFC6531], POP [draft-ietf-eai-pop] [I-D.ietf-eai-rfc5721bis]
   and IMAP [draft-ietf-eai-imap-utf8]. [I-D.ietf-eai-5738bis].

   This document provides guidelines for email clients that support
   these specifications for Email Address Internationalization (EAI).
   It does not introduce any protocol extensions that are not defined in
   the above documents.  It highlights the extensions that are important
   to the design and implementation of email clients and makes a number
   of recommendations intended to improve interoperability and
   usability.

2.1.

3.  Terminology

   A number of different acronyms are typically used to describe the
   major functional components of email.

   Mail User Agent (MUA)
   Message Submission Agent (MSA)
   Message Transfer Agent (MTA)
   Message Delivery Agent (MDA)
   Message Store (MS)

   The architecture of modern email systems can range from simple, with
   all components running on one server, to very complex, with
   components being distributed across multiple, geographically
   dispersed machines.  Nevertheless, the above terminology is generally
   sufficient to represent different architectures from a functional
   point of view.  For a comprehensive description of email architecture
   see [draft-crocker-email-arch]. [RFC5598].

   sender -> MUA -> MSA -> MTA
                           ...
                           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
   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
   direct access to the File system.  The MUA also provides a User
   Interface (UI) that allows an end user to read (display) and write
   (compose) their email.

   A common email architecture includes the MSA function within the MTA.
   An improved architecture that better addresses security concerns is a
   separate MSA component as shown here [RFC4409], [RFC6409], [RFC5068].

   "UTF8SMTP"

   "SMTPUTF8" is used to indicate email address internationalization as
   specified by [RFC4952] [RFC6530] and related documents.

   "ASCII" refers to the strict 7-bit ASCII character set [ASCII].
   [ANSI.X3-4.1968].

   "UTF-8", Unicode Transformation Format/8-bit is a character encoding
   scheme that can represent any character in the Unicode standard
   [RFC3629].  It contains ASCII as a subset.

   "message/global" is an email message that contains UTF-8 characters
   beyond 7-bit ASCII in message headers and/or body parts [RFC5335]. [RFC6532].

   "message/rfc822" is an email message that contains only 7 bit ASCII
   and does not use any UTF8SMTP SMTPUTF8 extensions.  Note that the original
   message (as composed by the user) may contain non-ASCII characters
   that have been encoded into ASCII using IDNA [RFC3490], [RFC5890], MIME body
   encoding [RFC2045] or MIME header encoding [RFC2047].

3. Version

4.  Interoperability

   Not all the components in Internet email systems will get upgraded to
   UTF8SMTP at the same time. There will be a transition period where
   upgraded components should be backwards

   Internationalized Email is not compatible with traditional legacy email components.

   The following table characterizes the most typical (but not all the
   possible) systems,
   those based on prior Internet email paths between users standards [RFC5321], [RFC5322].
   Non-ASCII email addresses cannot be submitted in different organizations legacy SMTP commands
   like MAIL FROM or
   enterprises (E1, E2, etc.) and highlights RCPT TO.  In addition the boundaries where
   incompatibilities will occur most frequently.

   Cases where email Internationalized Email
   standard does not cross include a jurisdictional boundary between
   sender and receiver are not shown. This includes email between users
   within the same organization and email between users in different
   organizations who use method to "downgrade" message/global to
   message/rfc822.

   An Internationalized message cannot be transmitted via SMTP if the same third party mail service.

             | Sending             |Receiving
         Case| MUA |MSA |MTA...MTA |MTA...MTA |MDA |MUA |
         ----+-----+----+----------+----------+----+----+
          1  | E1------------------|E2-------------->   |
          2  | E1--|E2-------------|E3-------------|E4  |
          3a | E1--|E2-------------|E3-------------->   |
          3b | E1------------------|E2-------------|E3  |

   It is assumed
   receiving MTA does not announce SMTPUTF8 in all response to EHLO.  There
   are two failure cases that SMTP mail between MTAs uses DNS.
   Lookup an email client may have to handle
   described in Section 3.2 of [RFC6531].

   a) If the MX record for the destination domain means that there client is only one boundary of incompatibility between MTAs.

   Case 1 represents the larger organizations and expert users who
   manage their own email infrastructure. In these environments there
   will likely be submitting a coordinated effort message to upgrade all components of the
   email system together. Each organization typically has several MTAs an MSA that act as virus scanners, spam filters, mail relays and gateways to
   manage mail across different divisions and locations of does not
   support SMTPUTF8, the
   organization. The boundary of incompatibility is message will be rejected.

   b) If the MSA does support SMTPUTF8 but a downstream MTA between does not,
   then the
   organizations. If both enterprises support UTF8SMTP, they mail will be
   able to send Internationalized email without the risk of
   incompatibility or Downgrade.

   For large organizations bounce.  That is, a delivery status notification
   (DSN) that allow end users to select and install
   their own email client software, the MUA boundaries are also possible
   incompatibilities. Users in this category would actually mail could not be
   represented by cases 2 and 3.

   Case 2 represents the home user and small delivered will be sent back to medium sized businesses
   who use the
   sender.

   Incompatibility between Internationalized email infrastructure of and legacy systems is
   expected to be important initially during a third party, such transition period but
   less important over time as an ISP
   (Internet Service Provider) or an outsourced provider. The mail
   provider has an infrastructure similar more email systems upgrade to Case 1. The boundaries of support the
   SMTPUTF8 extensions.  To the extent that this incompatibility are is
   deemed important at the MUA and between the MTAs of time an implementation is undertaken, the
   email
   providers.

   Case 3 covers mixed client should provide methods to prevent or at least minimize
   these failures.

4.1.  Interoperability Scenarios

   The following scenarios cover the different cases where of sending mail
   from an Internationalized server to a user with legacy server.

   'I' indicates an Internationalized address (a non-ASCII address on an
   Internationalized mail server).

   'IA' indicates an ASCII address on an Internationalized server.

   'LA' indicates an outsourced address on a Legacy mail server, which must be
   ASCII.

   Case 1.  The simple compatibility case

   From:    IA1 (or LA1)
   To:      LA2
   Subject: ...
   Body     ...

   The message will be successfully sent as long as the email
   service client
   sends to message/rfc822 rather than message/global.

   Case 2.  The simple incompatibility case

   From:    I1
   To:      LA2
   Subject: ...
   Body     ...

   The message will be rejected by the MSA or receives will bounce from a
   downstream SMTP server.

   If user in an organization that
   manages its own email infrastructure. The boundaries of
   incompatibility correspond to Cases 1 and 2. These cases may I1 also
   apply to some applications within larger organizations. For example,
   cell phone has an ASCII email address IA1 or LA1, there may utilize a mail gateway from be a third party
   provider even though the rest of
   simple workaround.  If the email infrastructure is in-
   house.

   For an MUA, client supports multiple email
   accounts, the boundaries where version compatibility is most likely user just has to occur is between home/small office users switch the From address to an ASCII
   address and their email
   providers. it becomes Case 1.

   Case 3.  The general incompatibility cases

   The worst general case scenario is Case 2, where three boundaries a mix of incompatibility are possible between sender Internationalized and recipient.

3.1. Sending

   For legacy addresses.
   While many combinations are possible, the two cases below essentially
   cover all possibilities.

   From: I1
   To:   LA2
   Cc:   I3

   The message will be sent to I3 but it will bounce from LA2.

   Switching the From address to an MUA that supports UTF8SMTP, there ASCII address as in Case 2 is not a matrix of possibilities
   based on whether the email envelope and
   solution, as the following case demonstrates.

   From: IA1 (or LA1)
   To:   LA2
   Cc:   I3

   This message contain non-ASCII
   characters and whether will bounce from LA2 since the MSA supports address in the UTF8SMTP extensions or
   not. The following table shows Cc header
   cannot be transmitted to a legacy server.

   In these cases, users will likely send the message twice in order to
   reach all intended recipients.  First, to the possible combinations.

      Case|Envelope  |Message  |MSA is  |MUA sends
          |          |         |UTF8SMTP|
      ----+----------+---------+--------+-----------------
       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 original list and then
   using an ASCII address to the Message type are considered separately because
   the Envelope may contain, for example, email bounced recipients.

   If users know beforehand which addresses that are all
   ASCII on legacy servers, they
   can avoid bounced messages by removing those addresses, but they
   still have to send a second email to reach recipients that were
   removed.

5.  Compatibility Support

   An email client can provide support to minimize the Subject or other header fields incompatibility
   problems outlined in the Message Section 4.  There may
   contain non-ASCII (Cases 3, 7).

   Cases 2 and 6 be several ways to do
   this.  Following are unusual since a UTF8SMTP address in the envelope is
   usually also in the message header. An example guidelines on some of when the ways that this can occur
   is when an rfc822 message is forwarded with server-based forwarding
   (as with a .forward file) to a UTF8SMTP address.

   Cases 1-3

   Messages containing non-ASCII characters SHOULD be sent using
   accomplished.

   At the
   UTF8SMTP extensions in preference very least, to older encoding methods, such as
   IDNA [RFC3490] provide basic compatibility between
   Internationalized and legacy systems, if all email addresses in the
   SMTP envelope and MIME header encoding [RFC2047]. If the message
   body contains non-ASCII characters, it SHOULD headers are ASCII, then a message/
   rfc822 should be sent using 8BITMIME
   [RFC1652] instead of MIME body encoding such as quoted-printable or
   base64 [RFC2045].

   Cases 5-7

   This could be considered a configuration error. If (Case 1 above).

   For Case 2, the MSA does not email client should support UTF8SMTP, multiple email accounts
   and allow the user should upgrade the MSA, or to switch the From address at any time during
   composition of the message.

   For Case 3, several mechanisms may be required to an
   email provider that supports UTF8SMTP.

   Upgrading provide
   compatibility support.  These are outlined in the MSA is a reasonable approach following sub-
   sections.

5.1.  Address Book

   Each contact in the case of larger
   organizations, where an IT group would address book should be expected able to synchronize MUA
   and MSA versions. However, home/small office users may end up in this
   situation when they have a computer that came with UTF8SMTP several 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
   headers if the MSA does not support the UTF8SMTP extensions
   [RFC5336]-Section 3.2.

   If the message
   addresses, each of which is not submitted, some guidance should be provided to
   the user about how configured to correct the problem. It may also be desirable
   to save this status and highlight it for the either an
   Internationalized or a Legacy address.

   The user before may not necessarily know if an ASCII address they compose enter in
   their address book is on a message. This would provide advance warning that internationalized
   email cannot be sent.

3.1.1. Downgrade

   The MUA MAY support the "downgrade" option, which legacy server or not.  If it is specified configured
   as an
   option for all email components MUA, MSA, MTA Internationalized address and MDA. Downgrade
   builds a message with all ASCII headers so that it is compatible with turns out to be wrong, then
   email components that don't support the UTF8SMTP extensions.
   Downgrade basically redirects mail from a UTF8SMTP address sent to an
   Alternate ASCII Address [RFC5504].

   It is not recommended that the MUA support Downgrade for cases 5-7. contact may bounce.  The user should be encouraged to correct can then re-
   configure the configuration and
   upgrade address as Legacy so the MSA or switch email providers in order to get support for
   internationalized email.

   The following shows an example client can provide
   warnings of downgrading a "From" header with a
   non-ASCII "Display-Name", non-ASCII email address and ASCII Alternate
   Address.

   Original header:

       From: Display-Name <eai-addr <alt-ascii-addr>>

   Downgrade would change the From address possible bounce on subsequent messages.

5.2.  Message Mode

   Message composition should have "Message Mode" option to specify
   "Internationalized Mode" or "Legacy Mode".

   If the Alternate Address and
   preserve the EAI type of each address in a new "Downgraded-From" header.

       From: =?UTF-8?Q?Display-Name?= <alt-ascii-addr>
       Downgraded-From: =?UTF-8?Q?Display-Name?=
        =?UTF-8?Q?<eai-addr?= <alt-ascii-addr>>

   Note that the Display-Name in the From header is encoded using
   traditional MIME email standards [RFC2047] with charset UTF-8. The
   MUA at the recipient end headers does not need to support the UTF8SMTP
   extensions conform to decode and display the original name.

   Complete examples of Downgrade are shown in
   message mode, then the Appendix of
   [RFC5504].

3.2. Receiving

   The matrix of possibilities user is based on 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.

   The user would typically first change the email message type and
   whether IMAP/POP and mode to see if the MUA support
   warnings disappear.

   When the UTF8SMTP extensions or
   not(Y/N) [draft-ietf-eai-imap-utf8], [draft-ietf-eai-pop].

      Case|Original|Spooled   |IMAP|Transfered|MUA|Displayed
          |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 mode is switched, the cases email client switches addresses in which
   message header fields to match the recipient receives mode, selecting from the message as
   sent list of
   addresses in each contact.

   There are 1 (all UTF8SMTP), 6 (traditional email) and 4b (downgraded
   conversion display).

   In cases 2, 4a and where both modes provide warnings (see Example 5
   below).  In these cases, the recipient receives a downgraded message.

   Case 2

   IMAP or POP must support Downgrade for this configuration. Direct
   maildrop access for message/global is prohibited if user can remove the MUA does not
   support UTF8SMTP.

   Case 3

   This is a configuration error. If IMAP or POP does not support
   UTF8SMTP, then addresses that don't
   conform to the mode.

   For Internationalized mode, the user has an additional option to send
   the message anyway, without removing flagged addresses.  They would
   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 for the MUA to receive global
   messages.

   Cases 4-6

   An ASCII message may be received from either compose a UTF8SMTP message/rfc822 if any sender or a non-
   UTF8SMTP interface.

   It recipient
   address is possible that not ASCII.

   Where both modes provide warnings, users will likely want to send the original message was a UTF8SMTP
   message that
   got downgraded to ASCII in transit. A message can be identified as
   downgraded because each mode in order to reach all recipients.  The email
   client should make it will have one or more headers that easy to do this.  There are prefixed
   with "Downgraded-".

   (Case 4a) A UTF8SMTP compliant MUA MAY display many possible
   designs to accomplish this.  The following is one example.

   An option is provided when composing email to add a downgraded second message
   as received, or (Case 4b) it MAY apply a conversion to restore the
   information contained
   header section in the "Downgraded-" headers as specified in
   [draft-ietf-eai-downgraded-display].

3.2.1. Display of Downgraded Messages As Received

   Cases 2, 4a, 5

   When displaying a downgraded message as received, UTF8SMTP addresses other mode that had Alternate Addresses in the original email will not be shown
   in the headers when reading, replying or forwarding email. Only the
   Alternate Addresses will be shown.

   If a UTF8SMTP address in the original email did not have an Alternate
   Address, then allows the UTF8SMTP address will be displayed in an empty
   group (using ":;") user to note that a UTF8SMTP address has been removed
   [RFC5504]-Section 5.1.7. move
   addresses between sections.  This may appear is in any header such as To: or
   Cc: as

      Display-Name Internationalized Address eai-addr Removed:;

   If a user replies to an email with such a group, many MUAs do not
   handle this correctly. Observed behavior has ranged from refusing addition to
   send the message due to an "invalid address", or attempting to send making individual
   changes to the group address headers as in normal email composition.  The
   Subject and reporting a DSN failure, or deleting Body are common so the group
   altogether. The user may resort to removing the group can compose a single message
   but have it sent in order the two different modes to get
   around these problems. Recipients of such email will not have different recipients.

   Following is an
   accurate record example of who the original recipients were. MUAs this for Case 3 above.

   ---------------------------------------------
   Legacy                   Internationalized
   From: IA1                From: I1
   To:   LA2       <--->    To:
   Cc:             <--->    Cc:   I3
   ---------------------------------------------
   Subject: ...
   Body:    ...
   ---------------------------------------------

5.3.  Message Format

   In Internationalized Mode, mail should be
   upgraded to support groups, sent as defined in [RFC2822]-Section 3.4.

   Note that even if an MUA does not support UTF8SMTP (Cases 2, 5), it message/global.
   The aim of Internationalized Email is able 8 bit clean messages using
   UTF-8 encoding to decode and display "Downgraded-" represent Unicode characters in header fields because
   Downgrade uses and
   the message body.

   In Legacy Mode, mail must be sent as message/rfc822.  This may
   include non-ASCII characters that are encoded into ASCII using MIME
   body encoding [RFC 2047][RFC 2231].

3.2.2. Downgraded Display

   Case 4b

   Support for conversion of "Downgraded-" headers is separate from
   support for Downgrade. An MUA MAY support none or one [RFC2045] or both of
   these options.

   Conversion replaces the Alternate Addresses in email headers with the
   original UTF8SMTP addresses that were recorded in the "Downgraded-"
   headers.

   If the MUA supports conversion of "Downgraded-" headers, the
   following considerations MIME header encoding [RFC2047].  Any
   encoding should be taken into account:

  1. If based on UTF-8.  In the MUA receives interest of
   interoperability, charsets other than UTF-8 are prohibited in mail from an IMAP/POP server, the conversion
     may have already been done but the message will still contain
     "Downgraded-Mail-From"
   addresses and "Downgraded-Rcpt-To" headers.

  2. Conversion of Downgraded message headers is not a reliable, reversible
     process.

  3. There is no authenticated binding between the original UTF8SMTP and
     the downgraded Alternate Address. This introduces various security
     concerns [draft-ietf-eai-downgraded-display]-Section 5.

4. Alternate Addresses

   Alternate Addresses MAY be required for Downgrade, which may occur
   anywhere on described in Section 7.1 of [RFC6530].

5.4.  Error Handling

   If a message is rejected by the path that MSA with a non-UTF8SMTP response code that
   indicates incompatibility with legacy email component is
   encountered [RFC5336]-Section 3.2. If Downgrade cannot be done described in
   these cases, Section 3.2
   of [RFC6531], the email may be returned ("bounced").

   Downgrade is expected to compose window should be important initially during a transition
   period but less important over time as more kept open so that the user
   can make changes and retry.  The email systems upgrade client should provide guidance
   to the UTF8SMTP extensions. To user about switching the extent that Downgrade is deemed
   important at Message Mode, reconfiguring the time type
   of an implementation is undertaken, Alternate
   Addresses [RFC5336] SHOULD be supported.

4.1. Sender

   An Alternate Address address in the address book or adding an ASCII legacy address
   for a contact in the sender MAY be provided, so that after
   Downgrade there is address book.

   Similarly, if a return path for message bounces, the email client could parse the
   delivery status notifications
   (DSN).

   Email addresses are generally created and set up on message disposition notifications
   [RFC6533] to determine if the server side,
   not by failure was a compatibility problem and
   if so, which addresses caused the MUA. An email provider may wish to problem.

5.5.  Examples

   The following examples illustrate most of the different possible
   cases.

   Suppose the user (Sender) has set up an Alternate
   Address automatically for each UTF8SMTP the following email account that is created.
   While in some environments it may be difficult or unfamiliar for a
   user to enter ASCII characters, selecting
   containing two email addresses, an Alternate Address for
   the user's UTF8SMTP Internationalized 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 and an Alternate Address should be presented to the user as a
   suggestion that can be changed.

   A UTF8SMTP implementation of
   ASCII address on an MSA/MTA may provide Internationalized server.

   Sender: I0, IA0

   Examples are not provided for the ability to
   bind an Alternate Address to a UTF8SMTP address. In this case, following cases:

   a) Sender: I0, LA0

   If the
   MUA may not need Sender has both Internationalized and Legacy addresses, then
   this is equivalent to the above.

   b) Sender: I0

   If the Sender has only Internationalized addresses, then it cannot
   send Legacy messages.  The email client cannot provide Alternate Addresses for an option to
   switch the sender.

   However, users may wish Message Mode to use different Alternate Addresses than
   those created for their UTF8SMTP Legacy.

   c) Sender: LA0

   If the Sender has only accounts on Legacy servers, then it cannot
   send Internationalized messages.  The email account, such as when they
   already have client cannot provide an ASCII
   option to switch the Message Mode to Internationalized.

   The address on another book has the following contacts with email system. addresses.

   Contact1: I1, IA1
   Contact2: I2
   Contact3: IA3
   Contact4: LA4

   Example 1:

   From: Sender
   To:   Contact1
   CC:   Contact2

   This message can be sent in Internationalized mode.

   In general, Legacy mode the MUA SHOULD allow users to save email client would flag Contact2, who does not
   have an Alternate Address
   for the sender's UTF8SMTP address, typically under "Account"
   settings. The configured value of this field ASCII address.

   Example 2:

   From: Sender
   To:   Contact1
   CC:   Contact3

   This message can be sent in either Internationalized or Legacy mode.

   Example 3:

   From: Sender
   To:   Contact1
   CC:   Contact4

   This message cannot be sent in Internationalized mode.  Contact4
   would be flagged since it is used as an ALT-
   ADDRESS parameter not on the SMTP command "MAIL FROM:" and an Internationalized server.

   This message can be sent in Legacy mode.

   Example 4:

   From: Sender
   To:   Contact2
   CC:   Contact3

   This message headers.

4.2. Recipients

   There are two cases where Downgrade can occur:

  1. Mail be sent from a UTF8SMTP user to a non-UTF8SMTP user.

  2. Mail in either Internationalized mode or Legacy
   mode.

   Example 5:

   From: Sender
   To:   Contact2
   CC:   Contact4

   This message cannot be sent from a UTF8SMTP user to a UTF8SMTP user where a non-
     UTF8SMTP component in either mode.

   Internationalized mode would flag Contact4 which is on a Legacy
   server.  The user can remove Contact4 or use the path.

   Downgrade in Case 1 provides backwards compatibility with recipients send anyway option.

   Legacy mode would flag Contact2 who are does not UTF8SMTP. In this case, the recipient has have an ASCII
   address address.
   The user would have to remove Contact2 in order to send this message.

5.6.  Limitations

   In summary, the guidelines outlines in Section 4 and an Alternate Address Section 5 will
   provide the following compatibility solutions:

   1.  When there is not required.

   In Case 2, Downgrade REQUIRES an Alternate Address ASCII address for all contacts in the recipient.
   However, this case could be considered message,
   then a configuration error. As
   reviewed in section 3, when DNS is used single legacy compatible message can be sent to determine all
   recipients.

   2.  When some contacts in the transport
   path from sender to receiver, mail does message do not get routed through have an
   email relay of a third party. If the sender ASCII address
   and recipient both some have
   UTF8SMTP addresses, then one of their MTA mail relays was not
   upgraded to UTF8SMTP. Users should only be set up with UTF8SMTP ASCII addresses if all the mail relays within the organization support
   UTF8SMTP.

   If it is decided that it is important to support Downgrade for Case
   2, on legacy servers, then the MUA SHOULD allow the user to enter and edit an optional
   Alternate Address wherever a UTF8SMTP recipient address
   message can be
   entered and edited. This would typically be split into two.  One message headers when
   composing email and entries stored in is sent as an "Address Book".
   Internationalized message to recipients on Internationalized servers.
   The recipient Alternate Address, if provided in an email composition, other is used sent as an ALT-ADDRESS parameter a legacy compatible message to recipients on the SMTP command "RCPT TO:"
   and
   legacy servers.

   These guidelines have a number of limitations.

   a) Unknown Address Types

   Message Mode is effective only if users are fairly disciplined about
   keeping addresses in message headers where the recipient their address is used.

4.3. Entry book and Display of Alternate Addresses

   The following applies configuring the type
   correctly as Internationalized or Legacy.

   When replying to both sender and recipient Alternate
   Addresses.

   Alternate Address fields MUST NOT contain non-ASCII addresses.

   If an email, the main email address is message may have addresses that are
   not UTF8SMTP, then entering an in the address book.  The user may also enter addresses directly
   during message composition that are not in the Alternate Address field SHOULD NOT be allowed [RFC5336]-
   Section 3.4. address book.

   The following is one example of how to display Alternate Addresses, email client may determine by using the UTF8SMTP "double angle bracket" format defined in
   [RFC5335]-Section 4.4:

      Display-Name <eai-addr <alt-ascii-addr>>

   It would inspection that some addresses are
   Internationalized.  If an address contains any non-ASCII character,
   then it must be helpful to display Internationalized.  However, an indicator ASCII address may be
   on UTF8SMTP either an Internationalized server or a Legacy server and there is
   no way software can determine this automatically.

   In such cases, it may be useful for the email
   addresses client to flag unknown
   address types in a message so that do not have an Alternate Address. This would alert the user is not lead to the possibility believe
   that the message may bounce. In the example
   above, an empty double bracket could be displayed in will not bounce just because there were no
   incompatibility warnings.

   b) Address Removal

   When email addresses are removed from a highlighted
   color, reminding the user 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 missing alternate address,
   as address
   of removed recipients by using an empty group.  This technique is
   described in

      Display-Name <eai-addr < >>

   When sending Section 3.1.8 of [I-D.ietf-eai-popimap-downgrade].

   This is not an ideal solution, since replies to the message, message will not
   reach everyone intended.  But at least it provides the MUA would have necessary
   contact information to remove empty double
   angle brackets.

   Since Downgrade and Alternate Addresses recipients who may not be widely used after
   a transition period, such an indicator should be configurable so that
   a user is able to turn it off.

4.4. use other
   methods to reply to all intended.

6.  Mailbox Integration

   If Alternate Addresses are supported, it may be desirable to combine
   mail for the UTF8SMTP more than one email address and is used for the Alternate Address into one sender user, emails
   may arrive at different email accounts.  There are several ways to
   provide mailbox integration so that the user is able to view all related mail can be managed in
   one place.

   For example, if location, such as a message single 'Inbox' folder.

   If integration is sent from a UTF8SMTP address to a list
   of recipients, some of done on the messages may be downgraded. Replies to
   downgraded messages will be delivered to server, through the Alternate Address, so
   all use of aliases,
   then the replies to a message may be split across two different
   mailboxes.

   Mailbox integration is email client does not generally handled by an MUA. Many existing
   MTAs/MDAs can need to do this with a anything.  All mail "alias" or "forward". One address
   is selected as the primary mailbox and will be
   received at the other address is
   configured as an alias.

   Forwarding allows an email address on client from one address.

   The email provider to be
   integrated into the client should provide mailbox on another email provider. Mailbox integration can make it easier for users to migrate from an old email
   system that does cases where
   server side integration is not support UTF8SMTP to available and for more flexibility on
   the part of the user.  Many email clients already provide a newer one that does. All
   they need
   convenient way to do is forward their old manage multiple email address accounts.

   An option to an Alternate
   Address that was created on their new view all mail service.

5. 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
   different character encoding schemes.  Numerous character encodings
   have been developed over time in order to best represent different
   language scripts.  In recent years there has been a trend to prefer
   Unicode as a "universal" character set and UTF-8 as the preferred
   encoding method.

   A good general principle to follow is to minimize character
   conversions.  This will reduce the chance that the received message
   is displayed differently from how it was composed.  Displaying
   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
   to reply to mail using the character encoding of the received mail.
   This may not be possible if the sender adds new characters that
   cannot be encoded in the original encoding.  For example, if the
   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-
   2022-JP and conversion to UTF-8 may be the best solution.

   For new mail, A UTF8SMTP SMTPUTF8 compliant MUA SHOULD use UTF-8 as the
   default encoding if the message type is global or if the envelope
   contains non-ASCII addresses.  If email clients utilize this default,
   character conversions will be minimized and there will be less chance
   that someone will receive mail in an unrecognized encoding.

   If the message type is rfc822, other considerations may apply, such
   as using the system locale/language.

   Notwithstanding the above, there may be cases where the default does
   not work well.  There SHOULD be options for the user to reset the
   default character encoding.  There SHOULD also be options to change
   the encoding when reading or writing individual email messages.

6.

8.  Normalization

   Different sequences of UTF-8 characters may represent the same thing.
   Normalization is a process that converts all canonically equivalent
   sequences to a single unique form.

   For example, in the Japanese environment, special consideration is
   needed for the "@" symbol used to separate the local name from the
   domain name in email addresses. Normalization is necessary to replace
   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. Section 3.1 of
   [RFC6532].  The MUA SHOULD normalize all email addresses in the
   envelope and message headers.

   For message bodies that contain UTF-8 characters (message/global),
   the "Net-Unicode" standardized text transmission format specified in
   [RFC5198] SHOULD be followed.  It covers both normalization and
   control characters that may affect display of text.

   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, an email address
   entered as

         user@host*domain

   where * represents 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), as used in some
   Asian languages, would display as

         user@host.domain

   For message bodies that contain UTF-8 characters (message/global), (U+3002) or FILLWIDTH FULL STOP (U+FF0E).  In
   email addresses, "@" is needed to separate the "Net-Unicode" standardized text transmission format specified in
   [RFC5198] SHOULD be followed. It covers both normalization 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
   control characters that may affect display of text.

7. FILLWIDTH FULL STOP
   (U+FF0E) with ASCII ".".

9.  Security Considerations

   This document does not introduce any security considerations beyond
   those already covered by the normative references for Email Address
   Internationalization (EAI).

8.

10.  IANA Considerations

   IANA changes are covered by the normative references for Email
   Address Internationalization (EAI).

9.

11.  Acknowledgments

10. References

10.1.

12.  Normative References

   [ASCII]

   [ANSI.X3-4.1968]                  American National Standards Institute (formerly United States
             of America Standards Institute),
                                     Institute, "USA Code for
                                     Information Interchange",
                                     ANSI X3.4-1968, X3.4, 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
             Downgraded Messages for Email Address
             Internationalization", draft-ietf-eai-downgraded-display-01
             (work in progress), March 2009.

   [draft-ietf-eai-imap-utf8]

   [I-D.ietf-eai-5738bis]            Resnick, P. and P., Newman, C., and S.
                                     Shen, "IMAP Support for UTF-8", draft-ietf-eai-imap-utf8-04
                                     draft-ietf-eai-5738bis-09 (work in
                                     progress),
             June 2009.

   [draft-ietf-eai-pop] Newman, C. and August 2012.

   [I-D.ietf-eai-popimap-downgrade]  Fujiwara, K., "Post-delivery
                                     Message Downgrading for
                                     Internationalized Email Messages",
                                     draft-ietf-eai-popimap-downgrade-07
                                     (work in progress), August 2012.

   [I-D.ietf-eai-rfc5721bis]         Gellens, R., Newman, C., Yao, J.,
                                     and K. Fujiwara, "POP3 Support for
                                     UTF-8", draft-ietf-eai-pop-06
                                     draft-ietf-eai-rfc5721bis-07 (work
                                     in progress), June
             2009.

   [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
             Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
             RFC 1652, July 1994. 2012.

   [RFC2045]                         Freed, N. and N. Borenstein,
                                     "Multipurpose Internet Mail
                                     Extensions (MIME) Part One: Format
                                     of Internet Message Bodies",
                                     RFC 2045, November 1996.

   [RFC2047]                         Moore, K., "MIME (Multipurpose
                                     Internet Mail Extensions) Part
                                     Three: Message Header Extensions
                                     for Non-ASCII Text", RFC 2047,
                                     November 1996.

   [RFC2119]                         Bradner, S., "Key words for use in
                                     RFCs to Indicate Requirement
                                     Levels", BCP 14, RFC 2119,
                                     March 1997.

   [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
             Part Three: Message Header Extensions for Non-ASCII Text",
             RFC 2047, November 1996.

   [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
             2001.

   [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
             "Internationalizing Domain Names in Applications (IDNA)",
             RFC 3490, March 2003.

   [RFC3629]                         Yergeau, F., "UTF-8, a
                                     transformation format of ISO
                                     10646", STD 63, RFC 3629,
                                     November 2003.

   [RFC4952] Klensin, J.

   [RFC5068]                         Hutzler, C., Crocker, D., Resnick,
                                     P., Allman, E., and Y. Ko, "Overview T. Finch,
                                     "Email Submission Operations:
                                     Access and Framework for
             Internationalized Email", Accountability
                                     Requirements", BCP 134, RFC 4952, July 5068,
                                     November 2007.

   [RFC5198]                         Klensin, J. and M. Padlipsky, M.,
                                     "Unicode Format for Network
                                     Interchange", RFC 5198, March 2008.

   [RFC5335] Yeh,

   [RFC5321]                         Klensin, J., "Internationalized Email Headers", "Simple Mail Transfer
                                     Protocol", RFC 5335,
             November 5321, October 2008.

   [RFC5336] Yao, J. and W. Mao, "SMTP extension for internationalized
             email address",

   [RFC5322]                         Resnick, P., Ed., "Internet Message
                                     Format", RFC 5336, September 5322, October 2008.

   [RFC5504] Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for
             Email Address Internationalization", RFC 5504, March 2009.

10.2. Informative References

   [draft-crocker-email-arch] D.

   [RFC5598]                         Crocker, D., "Internet Mail
                                     Architecture",
             draft-crocker-email-arch-14 (work in progress), June RFC 5598, July 2009.

   [RFC4409]

   [RFC5890]                         Klensin, J., "Internationalized
                                     Domain Names for Applications
                                     (IDNA): Definitions and Document
                                     Framework", RFC 5890, August 2010.

   [RFC6409]                         Gellens, R. and J. Klensin, J.,
                                     "Message Submission for Mail",
                                     STD 72, RFC 4409, 2006.

   [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E. 6409, November 2011.

   [RFC6530]                         Klensin, J. and
             Finch, Y. Ko, "Overview
                                     and Framework for Internationalized
                                     Email", RFC 6530, February 2012.

   [RFC6531]                         Yao, J. and W. Mao, "SMTP Extension
                                     for Internationalized Email",
                                     RFC 6531, February 2012.

   [RFC6532]                         Yang, A., Steele, S., and N. Freed,
                                     "Internationalized Email Headers",
                                     RFC 6532, February 2012.

   [RFC6533]                         Hansen, T., "Email Submission Operations: Access Newman, C., and
             Accountability Requirements", A.
                                     Melnikov, "Internationalized
                                     Delivery Status and Disposition
                                     Notifications", RFC 5068, November 2007. 6533,
                                     February 2012.

Authors' Addresses

   Ernie Dainow
   Afilias Canada
   4141 Yonge Street
   Toronto, Ontario  M2P 2A8
   Canada

   Email: edainow@ca.afilias.info

   Phone:
   EMail: edainow@afilias.info

   Kazunori Fujiwara
   JPRS
   Japan Registry Services Co., Ltd.
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065
   Japan

   Email:

   Phone: +81 3 5215 8451
   EMail: fujiwara@jprs.co.jp