5825
EXPERIMENTAL
Displaying Downgraded Messages for Email Address Internationalization (Obsoleted)
Authors: K. Fujiwara, B. Leiba
Date: April 2010
Area: app
Working Group: eai
Stream: IETF
Obsoleted by:
RFC 6530
Abstract
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.
RFC 5825
Obsoleted by: 6530 EXPERIMENTAL
Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 5825 JPRS
Category: Experimental B. Leiba
ISSN: 2070-1721 Huawei Technologies
April 2010
<span class="h1">Displaying Downgraded Messages for Email Address Internationalization</span>
Abstract
This document describes a method for displaying downgraded messages
that originally contained internationalized email addresses or
internationalized header fields.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc5825">http://www.rfc-editor.org/info/rfc5825</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Fujiwara & Leiba Experimental [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Converting Downgraded Message Headers for Display ...............<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Considerations .............................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. The Process ................................................<a href="#page-3">3</a>
3.2.1. No Reconstruction of the Envelope
Information Preservation ............................<a href="#page-4">4</a>
3.2.2. Reconstructing the Address Header Fields'
Preservation Header .................................<a href="#page-4">4</a>
3.2.3. The Unknown Header Fields' Preservation
Header Fields .......................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Acknowledgements ................................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. References ......................................................<a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. Normative References .......................................<a href="#page-6">6</a>
<a href="#section-6.2">6.2</a>. Informative References .....................................<a href="#page-7">7</a>
<a href="#appendix-A">Appendix A</a>. Examples ..............................................<a href="#page-8">8</a>
<a href="#appendix-A.1">A.1</a>. Displaying Example ........................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Email Address Internationalization (UTF8SMTP) extension document
set [<a href="./rfc4952" title=""Overview and Framework for Internationalized Email"">RFC4952</a>] [<a href="./rfc5336" title=""SMTP Extension for Internationalized Email Addresses"">RFC5336</a>] [<a href="./rfc5335" title=""Internationalized Email Headers"">RFC5335</a>] [<a href="./rfc5337" title=""Internationalized Delivery Status and Disposition Notifications"">RFC5337</a>] expands Email address
structure, syntax, and email header format. To avoid rejection of
internationalized email messages, the downgrading mechanism [<a href="./rfc5504" title=""Downgrading Mechanism for Email Address Internationalization"">RFC5504</a>]
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 [<a href="./rfc2047" title=""MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"">RFC2047</a>] 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 Mail User
Agents (MUAs) or IMAP servers. This document describes the
restoration methods for displaying downgraded messages in MUAs.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Fujiwara & Leiba Experimental [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Specialized terms used in this specification are defined in the EAI
overview [<a href="./rfc4952" title=""Overview and Framework for Internationalized Email"">RFC4952</a>] or in [<a href="./rfc5321" title=""Simple Mail Transfer Protocol"">RFC5321</a>], [<a href="./rfc5322" title=""Internet Message Format"">RFC5322</a>], or the MIME documents
[<a href="./rfc2045" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">RFC2045</a>], [<a href="./rfc2047" title=""MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"">RFC2047</a>], [<a href="./rfc2183" title=""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"">RFC2183</a>], and [<a href="./rfc2231" title=""MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"">RFC2231</a>].
This document depends on [<a href="./rfc5335" title=""Internationalized Email Headers"">RFC5335</a>] and [<a href="./rfc5504" title=""Downgrading Mechanism for Email Address Internationalization"">RFC5504</a>]. Key words used in
those documents are used in this document, too.
The term "MIME decode" is used for both "encoded-word" decoding
defined by [<a href="./rfc2047" title=""MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"">RFC2047</a>] and MIME parameter value decoding defined by
[<a href="./rfc2231" title=""MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"">RFC2231</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Converting Downgraded Message Headers for Display</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Considerations</span>
The order of some header fields (such as "Resent-*" fields) is
significant. The process of regenerating the original fields from
the downgraded ones MUST NOT reorder the fields.
In order to regenerate a field from a specific downgraded header
field, it's necessary to find the corresponding replacement in the
current message. If the corresponding field cannot be found, the
downgraded header field in question cannot be regenerated and used.
In any case where reconstruction of a particular downgraded header
field fails, both header fields (the "downgraded-YYY" header field
and the "YYY" header field) SHOULD be left in the message as they
are. The MUA MAY choose to communicate the situation to the user
(see the "Security Considerations" section).
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. The Process</span>
A MUA MAY decode and regenerate the original header fields of the
message (Mail Transport Agents (MTAs) and Mail Delivery Agents (MDAs)
SHOULD NOT attempt to do this; it SHOULD be left to the MUA). This
procedure can be used to approximately reverse the downgrade process,
but it will not always construct the original header fields exactly.
Three types of downgraded header fields are described in <a href="./rfc5504#section-3">Section 3 of
[RFC5504]</a>:
1. "Envelope Information Preservation Header Fields", described in
<a href="./rfc5504#section-3.1">RFC5504 Section 3.1</a> and in <a href="#section-3.2.1">Section 3.2.1</a>, below.
2. "Address Header Fields' Preservation Header Fields", described in
<a href="./rfc5504#section-3.2">RFC5504 Section 3.2</a> and in <a href="#section-3.2.2">Section 3.2.2</a>, below.
<span class="grey">Fujiwara & Leiba Experimental [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
3. "Unknown Header Fields' Preservation Header Fields", described in
<a href="./rfc5504#section-3.3">RFC5504 Section 3.3</a> and in <a href="#section-3.2.3">Section 3.2.3</a>, below.
After processing downgraded header fields, decode all header fields,
as described in [<a href="./rfc2047" title=""MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"">RFC2047</a>] and [<a href="./rfc2231" title=""MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations"">RFC2231</a>].
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. No Reconstruction of the Envelope Information Preservation</span>
<span class="h4"> Header Fields</span>
Envelope information preservation header fields are new fields that
might have been added by the downgrade process. Because they do not
represent fields that appeared in the original message, this process
is not applicable to them.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Reconstructing the Address Header Fields' Preservation Header</span>
<span class="h4"> Fields</span>
Reconstructing address header fields' preservation header fields is
OPTIONAL, and a decision MAY be made on each field, individually. In
particular, it might be less important to process the "Resent-*"
header fields, so an implementation MAY choose to skip those.
To construct a displayable copy of a header field from one of these
downgraded header fields, follow this procedure:
1. In an edit buffer, create a new header field:
(a) For the field name, remove the "Downgraded-" prefix from the
downgraded field name. For example, "Downgraded-From"
becomes "From", and "Downgraded-Resent-To" becomes
"Resent-To".
(b) For the field value, decode the MIME-encoded value of the
downgraded field according to [<a href="./rfc2047" title=""MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"">RFC2047</a>].
2. Apply "Email Header Fields Downgrading", defined in <a href="./rfc5504#section-5">Section 5 of
[RFC5504]</a>, to the field in the edit buffer. The process
generates two header fields, one is ASCII header field and the
other is the Address Header Fields' Preservation Header Field.
Put the generated ASCII header field into comparison buffer 1.
3. Canonicalize the header field in the comparison buffer 1:
1. Unfold all header field continuation lines as described in
[<a href="./rfc5322" title=""Internet Message Format"">RFC5322</a>].
<span class="grey">Fujiwara & Leiba Experimental [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
2. Ensure that there is one space character before and one after
the <mailbox-list> separator ",". If a space character is
missing, insert one.
3. Ensure that there is one space character before and one after
each <comment>. If a space character is missing, insert one.
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, retaining the colon separator.
4. Locate the first instance of the corresponding field in the
message's headers.
5. Canonicalize the located field as in step 3, and put the result
into comparison buffer 2.
6. Compare the header field in comparison buffer 1 with the header
field in comparison buffer 2. If they match, go to step 8.
7. Locate the next instance of the corresponding field in the
message's headers. If one is found, go to step 5. If none is
found, stop: you cannot use this downgraded field because you
can't find its replacement in the message.
8. Replace the located header field with the one in the edit buffer.
You MUST NOT reorder the header fields when you do this; it's
important to replace the field in the same place. Remove the
target downgraded header field in the message header.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. The Unknown Header Fields' Preservation Header Fields</span>
The unknown header fields' preservation header fields SHOULD be left
as they are unless the MUA has special knowledge of a particular
field. An MUA with such knowledge MAY use the procedure similar to
the procedure in <a href="#section-3.2.2">Section 3.2.2</a>, above, for those fields about which
it knows. (Note that the whitespace canonicalization rule might not
be applicable to some header fields.)
<span class="grey">Fujiwara & Leiba Experimental [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
While information in any email header should usually be 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 that rewriting,
the "From" header field might not match the "Downgraded-From" header
field.
A MUA MAY emphasize bogus or broken address header fields'
preservation header fields found in step 7 of <a href="#section-3.2.2">Section 3.2.2</a>.
Hiding the information from the actual header fields when using the
"Downgraded-" header fields does not cause loss of information if
generating MIME-decoded header fields in step 1 of <a href="#section-3.2.2">Section 3.2.2</a> and
the comparison done in step 7 are 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.
We have focused, here, on issues with displaying downgraded messages.
For more discussion of downgraded and internationalized messages in
general, see the "Security Considerations" section in [<a href="./rfc5504" title=""Downgrading Mechanism for Email Address Internationalization"">RFC5504</a>] and
[<a href="./rfc4952" title=""Overview and Framework for Internationalized Email"">RFC4952</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
This document was separated from [<a href="./rfc5504" title=""Downgrading Mechanism for Email Address Internationalization"">RFC5504</a>]. 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, Pasi Eronen,
Frank Ellermann, Edward Lewis, S. Moonesamy, and JET members.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2045">RFC2045</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", <a href="./rfc2045">RFC 2045</a>, November 1996.
[<a id="ref-RFC2047">RFC2047</a>] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
<a href="./rfc2047">RFC 2047</a>, November 1996.
<span class="grey">Fujiwara & Leiba Experimental [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2183">RFC2183</a>] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", <a href="./rfc2183">RFC 2183</a>, August 1997.
[<a id="ref-RFC2231">RFC2231</a>] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", <a href="./rfc2231">RFC 2231</a>,
November 1997.
[<a id="ref-RFC4952">RFC4952</a>] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", <a href="./rfc4952">RFC 4952</a>, July 2007.
[<a id="ref-RFC5322">RFC5322</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
October 2008.
[<a id="ref-RFC5335">RFC5335</a>] Abel, Y., "Internationalized Email Headers", <a href="./rfc5335">RFC 5335</a>,
September 2008.
[<a id="ref-RFC5504">RFC5504</a>] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
Email Address Internationalization", <a href="./rfc5504">RFC 5504</a>, March 2009.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC5321">RFC5321</a>] Klensin, J., "Simple Mail Transfer Protocol", <a href="./rfc5321">RFC 5321</a>,
October 2008.
[<a id="ref-RFC5336">RFC5336</a>] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", <a href="./rfc5336">RFC 5336</a>, September 2008.
[<a id="ref-RFC5337">RFC5337</a>] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", <a href="./rfc5337">RFC 5337</a>,
September 2008.
<span class="grey">Fujiwara & Leiba Experimental [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Examples</span>
This section shows an example of displaying a downgraded message.
First, an example of the original UTF8SMTP message and its downgraded
message are shown. The example comes from "Example 1" of [<a href="./rfc5504" title=""Downgrading Mechanism for Email Address Internationalization"">RFC5504</a>]
and three header fields, "Unknown-Field", "Resent-From", and
"Resent-To", are added. 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
Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com
<[email protected]>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
<[email protected]>>
Date: DATE
MAIL_BODY
Figure 1: Original message
<span class="grey">Fujiwara & Leiba Experimental [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
A delivered downgraded message is shown in Figure 2. A Return-Path
header will be added by the final destination MTA. Some "Received"
header fields may be added.
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<[email protected]>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<[email protected]>>?=
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-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
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?<[email protected]>>?=
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_<[email protected]>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
[email protected]?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<[email protected]>>?=
Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<[email protected]>>?=
Date: DATE
MAIL_BODY
Figure 2: Downgraded message
<span class="grey">Fujiwara & Leiba Experimental [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Figure 3 shows the MIME-decoded message of Figure 2. The recipient
can read the original "From", "To", "Cc", "Resent-From", "Resent-To"
and "Unknown-Field" header fields as "Downgraded-From",
"Downgraded-To", "Downgraded-Cc", "Downgraded-Resent-From",
"Downgraded-Resent-To", and "Downgraded-Unknown-Field" header fields.
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com
<[email protected]>>
Downgraded-Rcpt-To: <NON-ASCII-remote1@example.net
<[email protected]>>
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <ASCII-local@example.com>
Downgraded-From: DISPLAY-local <NON-ASCII-local@example.com
<[email protected]>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Cc: DISPLAY-remote2 Internationalized address
[email protected] removed:;
Downgraded-Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net>
Downgraded-Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <[email protected]>>
Resent-To: DISPLAY-reto <ASCII-reto@example.net>
Downgraded-Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <[email protected]>>
Date: DATE
MAIL_BODY
Figure 3: MIME-decoded message
<span class="grey">Fujiwara & Leiba Experimental [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Displaying Example</span>
This example shows how to display the message in Figure 2, above,
using the process defined in <a href="#section-3">Section 3</a>. For simplicity, we will show
the reconstruction of all the applicable fields at once.
Selecting all Downgraded-* fields gives this:
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<[email protected]>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<[email protected]>>?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<[email protected]>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<[email protected]>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<[email protected]>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<[email protected]>>?=
Figure 4: Downgraded header fields
Two of the fields, "Downgraded-Mail-From" and "Downgraded-Rcpt-To",
are envelope information preservation header fields, and will not be
reconstructed. One field, "Downgraded-Unknown-Field", is an unknown
header fields' preservation header field and will also not be
reconstructed. That leaves the address header fields' preservation
header fields to be reconstructed.
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<[email protected]>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<[email protected]>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<[email protected]>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
=?UTF-8?Q?<NON-ASCII-reto@example.net_<[email protected]>>?=
Figure 5: Header fields for the reconstruction
<span class="grey">Fujiwara & Leiba Experimental [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Now, perform step 1 to the downgraded header fields shown in Figure 5
and create an edit buffer.
From: DISPLAY-local <NON-ASCII-local@example.com
<[email protected]>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1
<NON-ASCII-remote1@example.net <[email protected]>>
Resent-To: DISPLAY-reto
<NON-ASCII-reto@example.net <[email protected]>>
Figure 6: edit buffer: Output of step 1
Apply "Email Header Fields Downgrading" to the "edit buffer". It
generates downgraded ASCII header fields and the address header
fields' preservation header fields. The latter fields are the same
as the downgraded header fields. Put the former fields into
"comparison buffer 1".
From:DISPLAY-local <ASCII-local@example.com>
To:DISPLAY-remote1 <ASCII-remote1@example.net>
Cc:DISPLAY-remote2 Internationalized address
[email protected] removed:;
Resent-From:DISPLAY-remote1 <ASCII-remote1@example.net>
Resent-To:DISPLAY-reto <ASCII-reto@example.net>
Figure 7: comparison buffer 1: Output of step 3
Perform steps 4 to 6, comparison, for each header field. Five header
fields, "From", "To", "Cc", "Resent-From" and "Resent-To" fields will
match, and we will proceed to step 8. (Step 7, iteration, does not
apply in this example.
<span class="grey">Fujiwara & Leiba Experimental [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Perform step 8, replacing all applicable fields, without changing the
order. Then, do MIME decoding on everything, for display.
Return-Path: <ASCII-local@example.com>
Received: ...
Downgraded-Mail-From: <NON-ASCII-local@example.com
<[email protected]>>
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
Downgraded-Unknown-Field: NON-ASCII-Unknown
From: DISPLAY-local <NON-ASCII-local@example.com
<[email protected]>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<[email protected]>>
Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
<[email protected]>>
Date: DATE
Figure 8: The final result
As a result, in this simple example, some original header fields are
now displayed in their original form. Differences between Figure 1
and Figure 8 are Return-Path, Downgraded-Mail-From,
Downgraded-Rcpt-To, and Downgraded-Unknown-Field.
<span class="grey">Fujiwara & Leiba Experimental [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc5825">RFC 5825</a> Displaying Downgraded Messages April 2010</span>
Authors' Addresses
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: [email protected]
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
EMail: [email protected]
URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a>
Fujiwara & Leiba Experimental [Page 14]
Annotations
Select text to annotate