Internet DRAFT - draft-dainow-eai-email-clients
draft-dainow-eai-email-clients
Network Working Group E. Dainow
Internet-Draft Afilias
Intended status: Informational K. Fujiwara
Expires: August 15, 2008 JPRS
February 18, 2008
Guidelines for Internationalized Email Clients
draft-dainow-eai-email-clients-00
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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 July 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document provides some guidelines for electronic mail clients
that support Email Address Internationalization (EAI). A number of
interoperability cases between different versions of email components
are reviewed. Some User Interface recommendations are made that will
minimize discrepancies between the display of composed and received
email in different language environments.
Dainow & Fujiwara Expires August 18, 2008 [Page 1]
Internet-Draft Guidelines for EAI Email Clients February 2008
Table of Contents
1. Conventions used in this document..............................3
2. Introduction...................................................3
2.1. Terminology...............................................3
3. Version Interoperability.......................................4
3.1. Sending...................................................4
3.1.1. Downgrade............................................6
3.2. Receiving.................................................7
3.2.1. Display of Downgraded Headers........................7
3.3. Version Checks............................................8
4. Character Encoding.............................................8
5. Normalization..................................................8
6. Alternate Addresses............................................9
6.1. Sender....................................................9
6.2. Recipients................................................9
7. Security Considerations.......................................10
8. IANA Considerations...........................................10
9. Acknowledgments...............................................10
10. References...................................................10
10.1. Normative References....................................10
10.2. Informative References..................................11
Author's Addresses...............................................12
Intellectual Property Statement..................................12
Disclaimer of Validity...........................................13
Dainow & Fujiwara Expires August 18, 2008 [Page 2]
Internet-Draft Guidelines for EAI Email Clients February 2008
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].
These key words will be used when the statement derives from a
normative reference. Use of these key words in lower case is to be
interpreted as a recommendation within this informative guideline
where the implementer is not bound by the statement.
2. Introduction
RFC 4952, Overview and Framework for Internationalized Email
[RFC4952], 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 [I-
D.ietf-eai-utf8headers] and to the protocols SMTP [I-D.ietf-eai-
smtpext], POP [I-D.ietf-eai-pop] and IMAP [I-D.ietf-eai-imap-utf8].
This document provides guidelines for email clients that support
these specifications for Email Address Internationalization (EAI).
2.1. 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 [I-D.crocker-email-arch].
Dainow & Fujiwara Expires August 18, 2008 [Page 3]
Internet-Draft Guidelines for EAI Email Clients February 2008
sender -> MUA -> MSA -> MTA
...
MTA -> MDA -> MS -> FPI -> 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 (FPI) is either direct access to the
file system or to a POP or IMAP server. 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], [RFC5068].
"UTF8SMTP" is used to indicate email address internationalization as
specified by [RFC4952] and related documents.
"message/global" is an email message that contains UTF-8 characters
beyond 7 bit ASCII (note that UTF-8 includes the ASCII character set)
in message headers and/or body parts [I-D.ietf-eai-utf8headers].
"message/rfc822" is an email message that contains only 7 bit ASCII
and does not use any UTF8SMTP 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], MIME body
encoding [RFC2045] or MIME header encoding [RFC2047].
3. Version Interoperability
3.1. Sending
For an MUA that supports UTF8SMTP, there is a matrix of possibilities
based on whether the email envelope and the message contain non-ASCII
characters and whether the MSA supports the UTF8SMTP extensions or
not. The following table shows all the possible combinations. Y/N
indicates that the MSA does/does not support UTF8SMTP.
Dainow & Fujiwara Expires August 18, 2008 [Page 4]
Internet-Draft Guidelines for EAI Email Clients February 2008
Case|Envelope |Message |MSA |MUA sends
----+----------+---------+----+-----------------
1 |UTF8SMTP |global | Y |UTF8SMTP
2 |UTF8SMTP |rfc822 | Y |UTF8SMTP
3 |ASCII |global | Y |UTF8SMTP
4 |ASCII |rfc822 | Y |Traditional email
5 |UTF8SMTP |global | N |Downgrade/Options
6 |UTF8SMTP |rfc822 | N |Downgrade/Options
7 |ASCII |global | N |Downgrade/Options
8 |ASCII |rfc822 | N |Traditional email
----+----------+---------+----+-----------------
*TBD are cases 2 and 6 possible*
The Envelope and the Message type are considered separately because
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). Such email MUST NOT be sent to an MSA
which does not support UTF8SMTP.
Cases 1-3
Messages containing non-ASCII characters should be sent using the
UTF8SMTP extensions in preference to older encoding methods, such as
IDNA [RFC3490] and MIME header encoding [RFC2047]. If the message
body contains non-ASCII characters, it should be sent using 8BITMIME
[RFC1652] instead of MIME body encoding such as quoted-printable or
base64 [RFC2045].
Cases 5-8
This could be considered a configuration error. If the MSA does not
support UTF8SMTP, the user should upgrade the MSA or else use a
traditional email client. This is a reasonable approach in the case
of an organization, where an IT group would be expected to
synchronize MUA and MSA versions.
However, home users may end up in this situation when they have a
computer that came with UTF8SMTP email client software and their
Internet Service Provider (ISP) does not support UTF8SMTP. Many such
users would not know how to locate an appropriate "traditional" email
client and install it.
The MUA MUST NOT submit a message with UTF8SMTP headers if the MSA
does not support the UTF8SMTP extensions. There are four options for
this case described in section 2.2 of [I-D.ietf-eai-smtpext],
summarized briefly as:
Dainow & Fujiwara Expires August 18, 2008 [Page 5]
Internet-Draft Guidelines for EAI Email Clients February 2008
1. Rewrite the headers as ASCII (if the client contains the MSA).
2. Reject the message.
3. Find an alternate route to the destination (if the client
interfaces to the MTA).
4. "Downgrade" the message.
3.1.1. Downgrade
The MUA MAY support the "downgrade" option. This builds a message
with all ASCII headers so that it is compatible with email components
that don't support the UTF8SMTP extensions [I-D.ietf-eai-downgrade].
Downgrade is intended to provide a degree of downward compatibility
between email systems that do not upgrade to UTF8SMTP at the same
time. It is specified as an option for all email components MUA, MSA,
MTA and MDA.
Downgrade requires an Alternate Address that is all ASCII delivery
for each address that contains non-ASCII characters. This includes
both the From and the Recipient addresses. A "From" Alternate Address
is required so that if a message is downgraded, there will be a
return path for delivery error notifications.
Guidelines for handling Alternate Addresses are discussed further in
the section .6.
The following shows how a "From" header in a message sent from a non-
ASCII email address with an ASCII Alternate Address would be
downgraded.
Original header:
From: EAI Display <eai-addr@domain.idn <alt-addr@domain.ascii>>
Downgrade would change this to:
From: =?UTF-8?Q?EAI Display?= <alt-addr@domain.ascii>
Downgraded-From: =?UTF-8?Q?EAI Display?=
=?UTF-8?Q?<eai-addr@domain.idn?= <alt-addr@domain.ascii>>
Complete examples of Downgrade are shown in the Appendix of [I-
D.ietf-eai-downgrade].
Dainow & Fujiwara Expires August 18, 2008 [Page 6]
Internet-Draft Guidelines for EAI Email Clients February 2008
3.2. Receiving
The matrix of possibilities is based on the email message type and
whether IMAP/POP and the MUA support the UTF8SMTP extensions or
not(Y/N) [I-D.ietf-eai-imap-utf8], [I-D.ietf-eai-pop].
Case|Message |IMAP|MUA|Transfered |Displayed |Comment
| |/POP| |Message |Message |
----+-----------+----+---+-----------+-----------+-------------------
1 |global | Y | Y |global |global |All UTF8SMTP
2 |global | N | N | - | - |Configuration error
3 |global | Y | N |downgraded |downgraded |POP/IMAP downgrade
4 |downgraded |Y/N | Y |downgraded |global |Display original
5 |downgraded |Y/N | N |downgraded |downgraded |Traditional
6 |rfc822 |Y/N |Y/N|rfc822 |rfc822 |Traditional
----+-----------+----+---+-----------+-----------+-------------------
Cases 2-3
If the MUA does not support UTF8SMTP, direct maildrop access with
message/global is prohibited. IMAP or POP must support Downgrade for
this configuration.
Cases 4-6
An ASCII message may be received from either a UTF8SMTP or an ASCII
interface.
It is possible that the original message was a UTF8SMTP message that
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-".
The MUA may apply a conversion to restore the information contained
in the "Downgraded-" headers of a downgraded message. This is
separated out as Case 4.
3.2.1. Display of Downgraded Headers
*TBD include document here or keep as a separate reference* [I-
D.fujiwara-eai-downgraded-display].
Support for conversion of "Downgraded-" headers is a separate
consideration from support for Downgrade. If User A replies to a
downgraded message from User B without converting, the reply will be
sent to B's Alternate Address. If "Downgraded-" headers are
converted, then the reply will be sent to B's UTF8SMTP address.
Dainow & Fujiwara Expires August 18, 2008 [Page 7]
Internet-Draft Guidelines for EAI Email Clients February 2008
Assuming the UTF8SMTP address is the primary mail address of the
sender, then it is preferable to convert and use the email address
from the Downgraded headers.
*TBD* The MUA should remove all "Downgraded-" header fields when
replying to a downgraded message, even if it does not decode
downgraded messages.
3.3. Version Checks
When the configurations for the MSA/MTA or IMAP/POP interfaces are
set up or changed, these connections should be checked to see if
UTF8SMTP is supported. If not, a message should be given to users so
that they have advance warning that internationalized email cannot be
sent and/or received.
4. Character Encoding
Email text messages (message bodies) may be composed and displayed in
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. So displaying
received mail and forwarding/replying to mail should use the
character encoding of the received mail.
A UTF8SMTP compliant MUA should use UTF-8 as the default encoding for
mail message bodies. If email clients utilize this default, then
character conversions will be minimized and there will be less chance
that someone will receive mail in an unrecognized encoding.
Notwithstanding the above, there may be cases where the defaults do
not work well. The MUA should consider support for some local
encodings for the mail body and encoded-word encodings per each
destination because older MUAs may not be able to parse UTF-8. 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.
5. Normalization
*This section TBD*
Dainow & Fujiwara Expires August 18, 2008 [Page 8]
Internet-Draft Guidelines for EAI Email Clients February 2008
Normalization of UTF-8 text streams is specified in [I-D.klensin-net-
utf8].
Email addresses need additional considerations. The domain part of
the email address should be normalized by IDNA (dot-mapping and
NAMEPREP).
Special consideration is needed for the "@" symbol used to separate
the local name from the domain name. In the Japanese environment,
FULLWIDTH COMMERCIAL AT (U+FF20) needs to be treated/replaced as "@".
The MUA should normalize all non-ASCII email addresses. This would
apply to email addresses transmitted and addresses stored by the MUA
(such as in the address book).
6. Alternate Addresses
Even if the MUA does not implement Downgrade, it should provide for
Alternate Addresses. Otherwise, Downgrade cannot be done anywhere on
the path to the recipient if a non-UTF8SMTP email component is
encountered. Without Alternate Addresses for both the Sender and the
Recipient, Downgrade cannot be done.
6.1. Sender
The sender's email address is usually configured once and saved,
often under an "Account Settings" option. Thereafter it is
automatically used as the From address in mail that is sent. A
configuration field for "Alternate Address" should be added. Only
ASCII addresses are allowed in this field. If the sender's address is
ASCII, then entering an address in the Alternate Address field should
not be allowed.
The configured value of this field is used as an ALT-ADDRESS
parameter on the SMTP command "MAIL FROM:" and in From: message
headers.
6.2. Recipients
Many email clients provide a way for the user to save a list of email
addresses along with related information, typically called an
"Address Book".
A field for an Alternate Address should be added to each address book
entry. Only ASCII addresses are allowed in this field. A value for
this field does not have to be provided by the user as it is not a
requirement that a UTF8SMTP email address have an alternate ASCII
Dainow & Fujiwara Expires August 18, 2008 [Page 9]
Internet-Draft Guidelines for EAI Email Clients February 2008
address. If the main email address is ASCII, then entering an address
in the Alternate Address field should not be allowed.
When an email address that has an Alternate Address is selected from
the Address Book and entered in an email message, such as in the To:
field, it would be natural to display it in UTF8SMTP "double angle
bracket" format, for example:
Display Name <eai-addr@domain.idn <alt-addr@domain.ascii>>
The user should also be able to enter and edit the Alternate Address
in an email message before it is sent.
The recipient Alternate Address, if provided in an email composition,
is used as an ALT-ADDRESS parameter on the SMTP command "RCPT TO:"
and in message headers where the recipient address is used.
7. Security Considerations
As an Informational document, this does not introduce any additional
security considerations beyond those covered by the normative
references for Email Address Internationalization (EAI).
8. IANA Considerations
IANA changes are covered by the normative references for Email
Address Internationalization (EAI).
9. Acknowledgments
10. References
10.1. Normative References
[I-D.ietf-eai-downgrade] Yoneya, Y. and K. Fujiwara, "Downgrading
mechanism for Email Address Internationalization", draft-
ietf-eai-downgrade-05 (work in progress), November 2007.
[I-D.ietf-eai-imap-utf8] Resnick, P. and Newman, C., "IMAP Support
for UTF-8", draft-ietf-eai-imap-utf8-02 (work in progress),
November 2007.
[I-D.ietf-eai-pop] Newman, C. and Gellens, R., "POP3 Support for UTF-
8", draft-ietf-eai-pop-02 (work in progress), July 2007.
Dainow & Fujiwara Expires August 18, 2008 [Page 10]
Internet-Draft Guidelines for EAI Email Clients February 2008
[I-D.ietf-eai-smtpext] Yao, J. and W. Mao, "SMTP extension for
internationalized email address", draft-ietf-eai-smtpext-09
(work in progress), November 2007.
[I-D.ietf-eai-utf8headers] Yeh, J., "Internationalized Email
Headers", draft-ietf-eai-utf8headers-07 (work in progress),
September 2007.
[I-D.fujiwara-eai-downgraded-display] Fujiwara, K., "Displaying
Downgraded Messages for Email Address
Internationalization", draft-fujiwara-eai-downgraded-
display-00 (work in progress), January 2008.
[I-D.klensin-net-utf8] Klensin, J. and Padlipsky, M., "Unicode Format
for Network Interchange", draft-klensin-net-utf8-07 (work
in progress), January 2008.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[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.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
10.2. Informative References
[I-D.crocker-email-arch] D. Crocker, "Internet Mail Architecture",
draft-crocker-email-arch-09 (work in progress), 2007.
[RFC4409] Gellens, R. and Klensin, J., "Message Submission for Mail",
RFC 4409, 2006.
Dainow & Fujiwara Expires August 18, 2008 [Page 11]
Internet-Draft Guidelines for EAI Email Clients February 2008
[RFC5068] Hutzler, C.,Crocker, D., Resnick, P.,Allman, E. and Finch,
T., "Email Submission Operations: Access and Accountability
Requirements", RFC 5068, November 2007.
Author's Addresses
Ernie Dainow
Afilias Canada
4141 Yonge Street, Suite 204
Toronto, Ontario
Canada M2P 2A8
Email: edainow@ca.afilias.info
Kazunori Fujiwara
JPRS
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Dainow & Fujiwara Expires August 18, 2008 [Page 12]
Internet-Draft Guidelines for EAI Email Clients February 2008
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dainow & Fujiwara Expires August 18, 2008 [Page 13]
