Email Address Internationalization K. Fujiwara
(EAI) JPRS
Internet-Draft Sep 8, 2009
Intended status: Experimental
Expires: March 12, 2010
Displaying Downgraded Messages for Email Address Internationalization
draft-ietf-eai-downgraded-display-02.txt
Status of 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. 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 March 12, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or
Fujiwara Expires March 12, 2010 [Page 1]
Internet-Draft Displaying Downgraded Messages Sep 2009
internationalized header fields.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration of displaying downgraded message . . . . . . . . 4
4. Displaying downgraded message . . . . . . . . . . . . . . . . 4
5. Security considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7
8.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7
8.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7
8.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9
A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Fujiwara Expires March 12, 2010 [Page 2]
Internet-Draft Displaying Downgraded Messages Sep 2009
1. Introduction
The Email Address Internationalization (UTF8SMTP) extension document
set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address
structure, syntax and Email header format. To avoid rejection of
internationalized Email messages, the downgrading mechanism [RFC5504]
converts an internationalized message to a traditional Email message
when a server in the delivery path does not support the UTF8SMTP
extension. The downgraded message is a traditional Email message,
except the message has "Downgraded-" header fields.
A perfect reverse-function of the downgrading does not exist because
the encoding defined in [RFC2047] is not exactly reversible and
Received header field downgrading may remove FOR clause information.
The restoration of the downgrading should be done once at the final
destination of the downgraded message such as MUAs or IMAP servers.
This document describes the restoration methods as displaying
downgraded messages in MUAs.
2. Terminology
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 RFC 2119 [RFC2119].
Specialized terms used in this specification are defined in the EAI
overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045]
[RFC2047] [RFC2183] [RFC2231].
This document depends on [RFC5335] and [RFC5504]. Key words used in
these document are used in this document, too.
The term "non-ASCII" is an UTF-8 string which contains at least one
non-ASCII character.
The term "address header field" is used for a header field which
contains <mailbox> elements which is defined in [RFC5322]. "Address
header fields" contain "From", "Sender", "Reply-To", "To", "Cc",
"Bcc", "Resent-From", "Resent-Sender", "Resent-To", "Resent-Cc",
"Return-Path" header fields.
An "UTF8SMTP message" is an Email messages expanded by [RFC5335].
The term "MIME decode" is used for both "encoded-word" decoding
defined by [RFC2047] and MIME parameter value decoding defined by
[RFC2231].
Fujiwara Expires March 12, 2010 [Page 3]
Internet-Draft Displaying Downgraded Messages Sep 2009
3. Consideration of displaying downgraded message
Displaying downgraded message is mostly performed by MIME decoding
according to [RFC2047] and [RFC2231]. As a result of MIME decoding,
the header of the message still contains "Downgraded-" header fields,
but the header field bodies are MIME decoded. These decoded
"Downgraded-" header fields contain the original header field name
and the original header field values. The recipient can read them.
But the recipient's MUA cannot use the original header fields
automatically.
Additionally, A MUA can process "Downgraded-" header fields.
The easiest way to process "Downgraded-" header fields is to remove
"Downgraded-" from the decoded "Downgraded-" header fields' names.
Then, the "address header fields" may be displayed twice, one is from
downgraded header field and the other is from decoded "Downgraded-"
header field. Although it is very easy, it MUST NOT be used because
of the following reasons.
o [RFC5322] section 3.6 defines number of times each field may occur
in the header section of a message and the maximum number for
"From", "Sender", "To", "Cc", "Bcc" header fields is 1. It
violates [RFC5322].
o Users cannot distinguish which is the original downgraded header
field and which is the generated header field.
o The "Downgraded-" header field and corresponding header field may
not have relations.
4. Displaying downgraded message
A MUA MAY decode and re-generate the original header fields of the
message. This procedure can be used to reverse the Downgrade process
but will not construct exactly the original header fields in all
cases.
Displaying downgraded message is implemented by the following steps.
Input:
The input to this procedure is the header of the message as
received. Copy the entire header into an edit space.
Step 1:
Select the "Address Header Fields' Preservation Header Fields"
described in Section 3.2 of [RFC5504] in the edit space. These
header fields are "Downgraded-From", "Downgraded-Sender",
"Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc", "Downgraded-
Reply-To", "Downgraded-Resent-From", "Downgraded-Resent-Sender",
Fujiwara Expires March 12, 2010 [Page 4]
Internet-Draft Displaying Downgraded Messages Sep 2009
"Downgraded-Resent-To", "Downgraded-Resent-Cc", "Downgraded-
Resent-Bcc", "Downgraded-Resent-Reply-To", "Downgraded-Return-
Path" and "Downgraded-Disposition-Notification-To" header fields.
Step 2:
For each header field from the output of Step 1, generate a new
header field where the field name is the original header field
name and the field value is the result of MIME decoding header
field value.
Step 3:
Apply "Email Header Fields Downgrading" defined in section 5 of
[RFC5504] to the output of Step 2 without re-generating
"Downgraded-" header fields and copy the output into a new space
(hereafter, call it as a "comparison space").
Step 4:
Compare the header fields in the comparison space with the header
fields of the same name in the edit space. Before this
comparison, canonicalize each header field described below.
1. Unfold all header field continuation lines as described in
[RFC5322].
2. Insert a space character before and after <mailbox-list>
separator "," if there is no space character.
3. Insert a space character before and after <comment> if there
is no space character.
4. Decode each <encoded-word> whose charset is 'UTF-8'.
5. Convert all sequences of one or more WSP characters to a
single space character. WSP characters here include those
before and after a line folding boundary.
6. Delete all WSP characters at the end of each unfolded header
field value.
7. Delete any WSP characters remaining before and after the colon
separating the header field name from the header field value.
The colon separator MUST be retained.
For each header field, if the same header fields exist in the
comparison space and in the edit space, remove the original header
field in the edit space and the generated header field in the
comparison space.
Remaining header fields in the comparison space may be bogus or
broken "Address Header Fields' Preservation Header Fields" origin.
Fujiwara Expires March 12, 2010 [Page 5]
Internet-Draft Displaying Downgraded Messages Sep 2009
Step 5:
Decode all MIME encoded header fields according to [RFC2047] and
[RFC2231] in the edit space.
Step 6:
For each "Unknown Header Fields' Preservation Header Fields"
described in section 3.3 of [RFC5504] and "Address Header Fields'
Preservation Header Fields", generate a new header field where the
field name is the original header field name and the field value
is the result of MIME decoding header field value, then replace
the original "Downgraded-" header field by the generated header
field in the edit space. "Envelope Information Preservation
Header Fields" are not targets of this step.
The output of this procedure is an UTF8SMTP header in the edit space.
It will closely resemble the original header.
After this procedure, the MUA may decode MIME body part header fields
according to [RFC2047] and [RFC2231].
5. Security considerations
While information in any email header should usually treated with
some suspicion, current email systems commonly employ various
mechanisms and protocols to make the information more trustworthy.
For example, an organization's boundary MTA can modify "From:" lines
so that messages arriving from outside the organization are easily
distinguishable from internal emails. As a result of rewriting, the
"Downgraded-From" header field may not be decoded.
A MUA may emphasize bogus or broken "Downgraded-" header fields in
step 4 of Section 4.
Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if the
comparison done in step 4 of Section 4 is successful. To ensure that
no information is lost, a MUA SHOULD have a function that uses the
actual message that was received (with/without MIME decoding) to
render the message.
See "Security considerations" section in [RFC5504] and [RFC4952] for
more discussion.
Fujiwara Expires March 12, 2010 [Page 6]
Internet-Draft Displaying Downgraded Messages Sep 2009
6. IANA Considerations
This document makes no requests for IANA action. This section can be
removed by the RFC Editor before publication.
7. Acknowledgements
This document was separated from [RFC5504]. Both documents were
developed in the EAI WG. Significant comments and suggestions were
received from John Klensin, Harald Alvestrand, Chris Newman, Randall
Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank
Ellermann, Edward Lewis, S. Moonesamy and JET members.
8. Change History
This section is used for tracking the update of this document. Will
be removed after finalize.
8.1. draft-fujiwara-eai-downgraded-display: Version 00
o Initial version
o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt
8.2. draft-ietf-eai-downgraded-display: Version 00
o Submitted as a working group draft
8.3. draft-ietf-eai-downgraded-display: Version 01
o Prohibited and removed Displaying Technique 1
o Added new texts to Security Considerations
8.4. draft-ietf-eai-downgraded-display: Version 02
o updated by comments from Chair's review and AD's review
o Fixed references
o Rewrote section 4 to be more comprehensible
o Added bogus or broken "Downgraded-" header fields
o Added sentences in Security considerations
9. References
Fujiwara Expires March 12, 2010 [Page 7]
Internet-Draft Displaying Downgraded Messages Sep 2009
9.1. Normative References
[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.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", RFC 5504, March 2009.
9.2. Informative References
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337,
September 2008.
Fujiwara Expires March 12, 2010 [Page 8]
Internet-Draft Displaying Downgraded Messages Sep 2009
Appendix A. Examples
This section shows a example of displaying downgraded message.
First, an example of the original UTF8SMTP message and its downgraded
message are shown. They are the same as "Example 1" of [RFC5504].
The example UTF8SMTP message is shown in Figure 1.
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
Figure 1: Original message
Delivered downgraded message is shown in Figure 2. Return-Path
header will be added by the final destination MTA.
Fujiwara Expires March 12, 2010 [Page 9]
Internet-Draft Displaying Downgraded Messages Sep 2009
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
Figure 2: Downgraded message
Figure 3 shows MIME decoded message of Figure 2. The recipient can
read the original From, To, Cc header fields as Downgraded-From,
Downgraded-To, Downgraded-Cc header fields.
Fujiwara Expires March 12, 2010 [Page 10]
Internet-Draft Displaying Downgraded Messages Sep 2009
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <ASCII-local@example.com>
Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 Internationalized address
NON-ASCII-remote2@example.org removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
Figure 3: MIME decoded message
Fujiwara Expires March 12, 2010 [Page 11]
Internet-Draft Displaying Downgraded Messages Sep 2009
A.1. Displaying example
This example shows processes of 'Displaying downgraded message' for
Figure 2.
First, perform Step 1.
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Figure 4: Displaying: Output of Step 1
Then, perform Step 2.
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Figure 5: Displaying: Output of Step 2
Perform Step 3.
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Figure 6: Displaying: Output of Step 3
Perform Step 4. "From", "To", "Cc" header fields are removed in
Figure 7.
Fujiwara Expires March 12, 2010 [Page 12]
Internet-Draft Displaying Downgraded Messages Sep 2009
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
Figure 7: Displaying: Output of Step 4
Perform Step 5 and 6.
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: <NON-ASCII-local@example.com
<ASCII-local@example.com>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net>
<ASCII-remote1@example.net>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
Figure 8: Decoded message
Fujiwara Expires March 12, 2010 [Page 13]
Internet-Draft Displaying Downgraded Messages Sep 2009
As a result, in this simple example, all original header fields are
displayed in the original form. Differences between Figure 1 and
Figure 8 are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To
header fields only.
Author's Address
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
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
Fujiwara Expires March 12, 2010 [Page 14]