One document matched: draft-ietf-eai-email-clients-01.xml
<?xml version="1.0" encoding="US-ASCII" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc rfcedstyle="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc='yes'?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-eai-email-clients-01">
<front>
<title abbrev="Email Clients">
Guidelines for Internationalized Email Clients
</title>
<author initials="E.D." surname="Dainow" fullname="Ernie Dainow">
<organization abbrev="Afilias">Afilias Canada</organization>
<address>
<postal>
<street>4141 Yonge Street</street>
<city>Toronto</city>
<region>Ontario</region>
<code>M2P 2A8</code>
<country>Canada</country>
</postal>
<phone></phone>
<email>edainow@afilias.info </email>
</address>
</author>
<author initials="K.F." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
<address>
<postal>
<street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>
<city>Chiyoda-ku</city>
<region>Tokyo</region>
<code>101-0065</code>
<country>Japan</country>
</postal>
<phone>+81 3 5215 8451</phone>
<email>fujiwara@jprs.co.jp</email>
</address>
</author>
<date day="7" month="September" year="2012" />
<area>Applications</area>
<workgroup>Email Address Internationalization (EAI)</workgroup>
<keyword>EAI</keyword>
<keyword>Email Address Internationalization</keyword>
<keyword>Email Client</keyword>
<abstract>
<t>
This document provides some guidelines for email clients that
support Email Address Internationalization (EAI) as outlined in
<xref target="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.
</t>
</abstract>
</front>
<middle>
<section title="Conventions used in this document">
<t>
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 <xref target="RFC2119" />.
</t>
</section>
<section title="Introduction">
<t>
<xref target="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
<xref target="RFC6532" /> and to the protocols SMTP
<xref target="RFC6531" />, POP
<xref target="I-D.ietf-eai-rfc5721bis" /> and IMAP
<xref target="I-D.ietf-eai-5738bis" />.
</t><t>
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.
</t>
</section>
<section title="Terminology">
<t>
A number of different acronyms are typically used to describe the
major functional components of email.
</t>
<artwork>
Mail User Agent (MUA)
Message Submission Agent (MSA)
Message Transfer Agent (MTA)
Message Delivery Agent (MDA)
Message Store (MS)
</artwork>
<t>
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 <xref target="RFC5598" />.
</t>
<artwork>
<![CDATA[
sender -> MUA -> MSA -> MTA
...
MTA -> MDA -> MS -> PIF -> MUA -> recipient
]]>
</artwork>
(where ... represents possible additional MTA relays)
<t>
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.
</t><t>
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 <xref target="RFC6409" />, <xref target="RFC5068" />.
</t><t>
"SMTPUTF8" is used to indicate email address internationalization as
specified by <xref target="RFC6530" /> and related documents.
</t><t>
"ASCII" refers to the strict 7-bit ASCII character set <xref target="ANSI.X3-4.1968" />.
</t><t>
"UTF-8", Unicode Transformation Format/8-bit is a character encoding
scheme that can represent any character in the Unicode standard
<xref target="RFC3629" />. It contains ASCII as a subset.
</t><t>
"message/global" is an email message that contains UTF-8 characters
beyond 7-bit ASCII in message headers and/or body parts
<xref target="RFC6532" />.
</t><t>
"message/rfc822" is an email message that contains only 7 bit ASCII
and does not use any 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 <xref target="RFC5890" />, MIME body
encoding <xref target="RFC2045" /> or MIME header encoding <xref target="RFC2047" />.
</t>
</section>
<section title="Interoperability" anchor="Interoperability">
<t>
Internationalized Email is not compatible with legacy email systems, those based on prior Internet email standards <xref target="RFC5321" />, <xref target="RFC5322" />. Non-ASCII email addresses cannot be submitted in legacy SMTP commands like MAIL FROM or RCPT TO. In addition the Internationalized Email standard does not include a method to "downgrade" message/global to message/rfc822.
</t><t>
An Internationalized message cannot be transmitted via SMTP if the receiving MTA does not announce SMTPUTF8 in response to EHLO. There are two failure cases that an email client may have to handle described in Section 3.2 of <xref target="RFC6531" />.
</t><t>
a) If the client is submitting a message to an MSA that does not support SMTPUTF8, the message will be rejected.
</t><t>
b) If the MSA does support SMTPUTF8 but a downstream MTA does not, 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 sender.
</t><t>
Incompatibility between Internationalized email and legacy systems is expected to be important initially during a transition period but 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.
</t>
<section title="Interoperability Scenarios">
<t>
The following scenarios cover the different cases of sending mail from an Internationalized server to a legacy server.
</t><t>
'I' indicates an Internationalized address (a non-ASCII address on an Internationalized mail server).
</t><t>
'IA' indicates an ASCII address on an Internationalized server.
</t><t>
'LA' indicates an address on a Legacy mail server, which must be ASCII.
</t><t>
Case 1. The simple compatibility case
</t>
<artwork>
From: IA1 (or LA1)
To: LA2
Subject: ...
Body ...
</artwork>
<t>
The message will be successfully sent as long as the email client sends message/rfc822 rather than message/global.
</t><t>
Case 2. The simple incompatibility case
</t>
<artwork>
From: I1
To: LA2
Subject: ...
Body ...
</artwork>
<t>
The message will be rejected by the MSA or will bounce from a downstream SMTP server.
</t><t>
If user I1 also has an ASCII email address IA1 or LA1, there may be a simple workaround. If the email client supports multiple email accounts, the user just has to switch the From address to an ASCII address and it becomes Case 1.
</t><t>
Case 3. The general incompatibility cases
</t><t>
The general case is a mix of Internationalized and legacy addresses. While many combinations are possible, the two cases below essentially cover all possibilities.
</t>
<artwork>
From: I1
To: LA2
Cc: I3
</artwork>
<t>
The message will be sent to I3 but it will bounce from LA2.
</t><t>
Switching the From address to an ASCII address as in Case 2 is not a solution, as the following case demonstrates.
</t>
<artwork>
From: IA1 (or LA1)
To: LA2
Cc: I3
</artwork>
<t>
This message will bounce from LA2 since the address in the Cc header cannot be transmitted to a legacy server.
</t><t>
In these cases, users will likely send the message twice in order to reach all intended recipients. First, to the original list and then using an ASCII address to the bounced recipients.
</t><t>
If users know beforehand which addresses are 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.
</t>
</section>
</section>
<section title="Compatibility Support" anchor="Compatibility">
<t>
An email client can provide support to minimize the incompatibility
problems outlined in <xref target="Interoperability" />.
There may be several ways to do this.
Following are guidelines on some of the ways
that this can be accomplished.
</t><t>
At the very least, to provide basic compatibility between 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).
</t><t>
For Case 2, the email client should support multiple email accounts and allow the user to switch the From address at any time during composition of the message.
</t><t>
For Case 3, several mechanisms may be required to provide compatibility support. These are outlined in the following sub-sections.
</t>
<section title="Address Book">
<t>
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.
</t><t>
The user may not necessarily know if an ASCII address they enter in their address book is on a legacy server or not. If it is configured 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.
</t>
</section>
<section title="Message Mode">
<t>
Message composition should have "Message Mode" option to specify "Internationalized Mode" or "Legacy Mode".
</t><t>
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.
</t><t>
The user would typically first change the message mode to see if the warnings disappear.
</t><t>
When the mode is switched, the email client switches addresses in message header fields to match the mode, selecting from the list of addresses in each contact.
</t><t>
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.
</t><t>
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 to compose a message/rfc822 if any sender or recipient address is not ASCII.
</t><t>
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.
</t><t>
An option is provided when composing email to add a second message 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.
</t><t>
Following is an example of this for Case 3 above.
</t>
<artwork>
---------------------------------------------
Legacy Internationalized
From: IA1 From: I1
To: LA2 <---> To:
Cc: <---> Cc: I3
---------------------------------------------
Subject: ...
Body: ...
---------------------------------------------
</artwork>
</section>
<section title="Message Format">
<t>
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.
</t><t>
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 <xref target="RFC2045" />
or MIME header encoding <xref target="RFC2047" />.
Any 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 <xref target="RFC6530" />.
</t>
</section>
<section title="Error Handling">
<t>
If a message is rejected by the MSA with a response code
that indicates incompatibility with legacy email
described in Section 3.2 of <xref target="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.
</t><t>
Similarly, if a message bounces, the email client could parse the delivery status notifications and message disposition notifications <xref target="RFC6533" /> to determine if the failure was a compatibility problem and if so, which addresses caused the problem.
</t>
</section>
<section title="Examples">
<t>
The following examples illustrate most of the different possible cases.
</t><t>
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.
</t><t>
Sender: I0, IA0
</t><t>
Examples are not provided for the following cases:
</t><t>
a) Sender: I0, LA0
</t><t>
If the Sender has both Internationalized and Legacy addresses, then this is equivalent to the above.
</t><t>
b) Sender: I0
</t><t>
If the Sender has only Internationalized addresses, then it cannot send Legacy messages. The email client cannot provide an option to switch the Message Mode to Legacy.
</t><t>
c) Sender: LA0
</t><t>
If the Sender has only accounts on Legacy servers, then it cannot send Internationalized messages. The email client cannot provide an option to switch the Message Mode to Internationalized.
</t><t>
The address book has the following contacts with email addresses.
</t>
<artwork>
Contact1: I1, IA1
Contact2: I2
Contact3: IA3
Contact4: LA4
</artwork>
<t>
Example 1:
</t>
<artwork>
From: Sender
To: Contact1
CC: Contact2
</artwork>
<t>
This message can be sent in Internationalized mode.
</t><t>
In Legacy mode the email client would flag Contact2, who does not have an ASCII address.
</t><t>
Example 2:
</t>
<artwork>
From: Sender
To: Contact1
CC: Contact3
</artwork>
<t>
This message can be sent in either Internationalized or Legacy mode.
</t><t>
Example 3:
</t>
<artwork>
From: Sender
To: Contact1
CC: Contact4
</artwork>
<t>
This message cannot be sent in Internationalized mode. Contact4 would be flagged since it is not on an Internationalized server.
</t><t>
This message can be sent in Legacy mode.
</t><t>
Example 4:
</t>
<artwork>
From: Sender
To: Contact2
CC: Contact3
</artwork>
<t>
This message can be sent in either Internationalized mode or Legacy mode.
</t><t>
Example 5:
</t>
<artwork>
From: Sender
To: Contact2
CC: Contact4
</artwork>
<t>
This message cannot be sent in either mode.
</t><t>
Internationalized mode would flag Contact4 which is on a Legacy server. The user can remove Contact4 or use the send anyway option.
</t><t>
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.
</t>
</section>
<section title="Limitations">
<t>
In summary, the guidelines outlines in <xref target="Interoperability" /> and <xref target="Compatibility" /> will provide the following compatibility solutions:
</t><t>
1. When there is an ASCII address for all contacts in the message, then a single legacy compatible message can be sent to all recipients.
</t><t>
2. When some contacts in the message do not have an ASCII address and some have only ASCII addresses on legacy servers, then the 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.
</t><t>
These guidelines have a number of limitations.
</t><t>
a) Unknown Address Types
</t><t>
Message Mode is effective only if users are fairly disciplined about keeping addresses in their address book and configuring the type correctly as Internationalized or Legacy.
</t><t>
When replying to an email, the message may have addresses that are not in the address book. The user may also enter addresses directly during message composition that are not in the address book.
</t><t>
The email client may determine by inspection that some addresses are Internationalized. If an address contains any non-ASCII character, then it must be Internationalized. However, an ASCII address may be on either an Internationalized server or a Legacy server and there is no way software can determine this automatically.
</t><t>
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.
</t><t>
b) Address Removal
</t><t>
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 <xref target="I-D.ietf-eai-popimap-downgrade" />.
</t><t>
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.
</t>
</section>
</section>
<section title="Mailbox Integration">
<t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
An option to view all mail from a group of accounts in one integrated folder should also be provided.
</t>
</section>
<section title="Character Encoding">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
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.
</t>
<t>
If the message type is rfc822, other considerations may apply, such
as using the system locale/language.
</t>
<t>
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.
</t>
</section>
<section title="Normalization">
<t>
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.
</t>
<t>
Normalization of email headers is specified in
Section 3.1 of <xref target="RFC6532" />.
The MUA SHOULD normalize all email addresses in the envelope and message
headers.
</t>
<t>
For message bodies that contain UTF-8 characters (message/global),
the "Net-Unicode" standardized text transmission format specified in
<xref target="RFC5198" /> SHOULD be followed. It covers both normalization and
control characters that may affect display of text.
</t>
<t>
If the MUA saves email addresses (such as in an address book), they
SHOULD be stored in normalized form.
</t>
<t>
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 ".".
</t>
</section>
<section title="Security Considerations">
<t>
This document does not introduce any security considerations beyond
those already covered by the normative references for Email Address
Internationalization (EAI).
</t>
</section>
<section title="IANA Considerations">
<t>
IANA changes are covered by the normative references for Email
Address Internationalization (EAI).
</t>
</section>
<section title="Acknowledgments">
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.ANSI.X3-4.1968" ?>
<?rfc include="reference.RFC.2045" ?>
<?rfc include="reference.RFC.2047" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.RFC.6409" ?>
<?rfc include="reference.RFC.5068" ?>
<?rfc include="reference.RFC.5198" ?>
<?rfc include="reference.RFC.5321" ?>
<?rfc include="reference.RFC.5322" ?>
<?rfc include="reference.RFC.5598" ?>
<?rfc include="reference.RFC.5890" ?>
<?rfc include="reference.RFC.6530" ?>
<?rfc include="reference.RFC.6531" ?>
<?rfc include="reference.RFC.6532" ?>
<?rfc include="reference.RFC.6533" ?>
<?rfc include="reference.I-D.ietf-eai-rfc5721bis" ?>
<?rfc include="reference.I-D.ietf-eai-5738bis" ?>
<?rfc include="reference.I-D.ietf-eai-popimap-downgrade" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:51 |