Email Address Internationalization                           K. Fujiwara
(EAI)                                                               JPRS
Internet-Draft                                               Sep 8, 2009                                                  B. Leiba
Intended status: Experimental                        Huawei Technologies
Expires: March 12, June 4, 2010                                   December 1, 2009

 Displaying Downgraded Messages for Email Address Internationalization
                draft-ietf-eai-downgraded-display-02.txt
                draft-ietf-eai-downgraded-display-03.txt

Abstract

   This document describes a method for displaying downgraded messages
   which originally contained internationalized E-mail addresses or
   internationalized header fields.

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, June 4, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   This  Code Components extracted from this document describes a method for displaying downgraded messages
   which originally contained internationalized E-mail addresses or
   internationalized header fields. 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 BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Consideration of displaying  Converting downgraded message headers for display  . . . . . .  3
     3.1.  Considerations . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  The process  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Displaying downgraded message
       3.2.1.  No reconstruction of the Envelope Information
               Preservation Header Fields . . . . . . . . . . . . . .  4
       3.2.2.  Reconstructing the Address Header Fields'
               Preservation Header Fields . . . . . . . . . . . . . .  4
   5.
       3.2.3.  The Unknown Header Fields' Preservation Header
               Fields . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  6
   6.
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  6
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  6
   7.  Change History . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  6
     7.1.  draft-fujiwara-eai-downgraded-display: Version 00  . . . .  7
     8.2.
     7.2.  draft-ietf-eai-downgraded-display: Version 00  . . . . . .  7
     8.3.
     7.3.  draft-ietf-eai-downgraded-display: Version 01  . . . . . .  7
     8.4.
     7.4.  draft-ietf-eai-downgraded-display: Version 02  . . . . . .  7
   9.
     7.5.  draft-ietf-eai-downgraded-display: Version 03  . . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  7
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  7
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . .  9  8
     A.1.  Displaying example . . . . . . . . . . . . . . . . . . . . 12
   Author's Address .
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

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 for 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].

3.  Consideration of displaying  Converting downgraded message

   Displaying downgraded message is mostly performed by MIME decoding
   according to [RFC2047] and [RFC2231].  As a result of MIME decoding,
   the header headers for display

3.1.  Considerations

   The order of the message still contains "Downgraded-" header fields,
   but the header field bodies are MIME decoded.  These decoded
   "Downgraded-" some header fields contain the original header field name
   and the original header field values. (such as "Resent-*" fields) is
   significant.  The recipient can read them.
   But the recipient's MUA cannot use process of regenerating 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 ones MUST NOT be used because
   of reorder the following reasons.
   o  [RFC5322] section 3.6 defines number of times each fields.

   In order to regenerate a field may occur from a specific downgraded header
   field, it's necessary to find the corresponding replacement in the header section of a message and
   current message.  If the maximum number for
      "From", "Sender", "To", "Cc", "Bcc" header fields is 1.  It
      violates [RFC5322].
   o  Users cannot distinguish which is corresponding field can not be found, the original
   downgraded header field in question can not be regenerated and which is the generated header field.
   o used.

3.2.  The "Downgraded-" header field and corresponding header field may
      not have relations.

4.  Displaying downgraded message process

   A MUA MAY decode and re-generate the original header fields of the
   message.
   message (MTAs and 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 process, but it will not always 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 exactly.

   Three types of the message as
      received.  Copy the entire Downgraded header into an edit space.

   Step 1:
      Select the fields are described in section 3 of
   [RFC5504]:
   1.  "Envelope Information Preservation Header Fields", described in
       RFC5504 section 3.1 and in Section 3.2.1, below.
   2.  "Address Header Fields' Preservation Header Fields" Fields", described in Section
       RFC5504 section 3.2 of [RFC5504] and in the edit space.  These Section 3.2.2, below.
   3.  "Unknown Header Fields' Preservation Header Fields", described in
       RFC5504 section 3.3 and in Section 3.2.3, below.

   After processing Downgraded header fields fields, decode all header fields,
   as described in [RFC2047] and [RFC2231].

3.2.1.  No reconstruction of the Envelope Information Preservation
        Header Fields

   Envelope Information Preservation Header Fields are "Downgraded-From", "Downgraded-Sender",
      "Downgraded-To", "Downgraded-Cc", "Downgraded-Bcc", "Downgraded-
      Reply-To", "Downgraded-Resent-From", "Downgraded-Resent-Sender",
      "Downgraded-Resent-To", "Downgraded-Resent-Cc", "Downgraded-
      Resent-Bcc", "Downgraded-Resent-Reply-To", "Downgraded-Return-
      Path" 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.

3.2.2.  Reconstructing the Address Header Fields' Preservation Header
        Fields

   Reconstructing Address Header Fields' Preservation Header Fields is
   OPTIONAL, and "Downgraded-Disposition-Notification-To" header fields.

   Step 2:
      For 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 the output one of Step 1, generate these
   downgraded header fields, follow this procedure:
   1.   In an edit buffer, create a new header field where field:"
   1a.   For the field name is name, remove the original header "Downgraded-" prefix from the
      downgraded field
      name name.  For example, "Downgraded-From" becomes
      "From", and "Downgraded-Resent-To" becomes "Resent-To".

   1b.   For the field value is value, decode the result MIME-encoded value of MIME decoding the
      downgraded field according to [RFC2047].
   2.   If the header field value.

   Step 3: is one that can only appear once, according
      to the table in [RFC5322] section 3.6 ("From", "Sender", "To",
      "CC", "BCC", "Reply-To"), locate the corresponding field in the
      message's headers, and skip to step 9.  Otherwise, continue with
      step 3.
   3.   Apply "Email Header Fields Downgrading" Downgrading", defined in section 5 of
      [RFC5504]
      [RFC5504], to the output of Step 2 without re-generating
      "Downgraded-" header fields and copy field in the output into a new space
      (hereafter, call it as a "comparison space").

   Step 4:
      Compare edit buffer, but do not prepend the header fields in
      "Downgraded-" prefix.  Put the result into comparison space with buffer 1.
   4.   Canonicalize the header fields of the same name in the edit space.  Before this
      comparison, canonicalize each header field described below. comparison buffer:
      1.  Unfold all header field continuation lines as described in
          [RFC5322].
      2.  Insert a  Ensure that there is one space character before and one after
          the <mailbox-list> separator "," if there is no ",".  If a space character. character is
          missing, insert one.
      3.  Insert a  Ensure that there is one space character before and one after <comment> if there
          is no
          each <comment>.  If a space character. character is missing, insert one.
      4.  Decode each <encoded-word> whose charset is 'UTF-8'. "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 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 value,
          retaining the colon separator MUST be retained.

      For each header field, if separator.
   5.   Locate the same header fields exist in first instance of the
      comparison space and corresponding field in the edit space, remove
      message's headers.
   6.   Canonicalize the original header located field as in the edit space step 4, and put the result
      into comparison buffer 2.
   7.   Compare the generated header field in the comparison space.

      Remaining buffer 1 with the header fields
      field in the comparison space may be bogus or
      broken "Address Header Fields' Preservation Header Fields" origin.

   Step 5:
      Decode all MIME encoded header fields according buffer 2.  If they match, go to [RFC2047] and
      [RFC2231] in step 9.
   8.   Locate the edit space.

   Step 6:
      For each "Unknown Header Fields' Preservation Header Fields"
      described in section 3.3 next instance of [RFC5504] and "Address Header Fields'
      Preservation Header Fields", generate a new header field where the corresponding field name is in the original header
      message's headers.  If one is found, go to step 6.  If none is
      found, stop: you can not use this downgraded field name and because you
      can't find its replacement in the field value
      is message.
   9.   Replace the result of MIME decoding located header field value, then replace with the original "Downgraded-" header field by one in the edit
      buffer.  You MUST NOT reorder the generated header fields when you do this;
      it's important to replace the field in the edit space.  "Envelope Information place.

3.2.3.  The Unknown Header Fields' Preservation Header Fields" are not targets of this step. Fields

   The output Unknown Header Fields' Preservation Header Fields SHOULD be left
   as they are unless the MUA has special knowledge of this a particular
   field.  An MUA with such knowledge MAY use the 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
   Section 3.2.2, above, for those fields
   according to [RFC2047] and [RFC2231].

5. that it knows about.

4.  Security considerations

   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,
   it might not be possible to reconstruct the "Downgraded-From" header field may not be decoded.
   field.

   A MUA may MAY emphasize bogus or broken "Downgraded-" header fields Address Header Fields'
   Preservation Header Fields found in step 4 8 of Section 4. 3.2.2.

   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 Section 3.2.2 and
   the comparison done in step 4 of Section 4 is 8 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.

   See "Security considerations" section in [RFC5504] and [RFC4952] for
   more discussion.

6.

5.  IANA Considerations

   This document makes no requests for IANA action.  This section can be
   removed by the RFC Editor before publication.

7.

6.  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, Pasi Eronen,
   Frank Ellermann, Edward Lewis, S. Moonesamy and JET members.

8.

7.  Change History

   This section is used for tracking the update of this document.  Will
   be removed after finalize.

8.1.

7.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.

7.2.  draft-ietf-eai-downgraded-display: Version 00

   o  Submitted as a working group draft

8.3.

7.3.  draft-ietf-eai-downgraded-display: Version 01

   o  Prohibited and removed Displaying Technique 1
   o  Added new texts to Security Considerations

8.4.

7.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.

7.5.  draft-ietf-eai-downgraded-display: Version 03

   o  Section 3 (formerly 3 and 4) was rewritten by Barry Leiba.

8.  References
9.1.

8.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.

8.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.

Appendix A.  Examples

   This section shows a example of displaying a downgraded message.
   First, an example of the original UTF8SMTP message and its downgraded
   message are shown.  They are the same as  The example comes from "Example 1" of [RFC5504]. [RFC5504]
   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
    <ASCII-local@example.com>>
   To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
    <ASCII-remote1@example.net>>
   Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
   Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
    <ASCII-remote1@example.net>>
   Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
    <ASCII-reto@example.net>>
   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.  Some of 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?<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-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?<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>?=
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_<ASCII-remote1@example.net>>?=
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_<ASCII-reto@example.net>>?=
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 and Unknown-Field header fields as
   Downgraded-From, Downgraded-To, Downgraded-Cc and Downgraded-Unknown-
   Field header fields.

   Return-Path: <ASCII-local@example.com>
   Received: ...
   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
   Downgraded-Unknown-Field: NON-ASCII-Unknown
   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>
   Resent-From: DISPLAY-remote1 <ASCII-remote1@example.net>
   Downgraded-Resent-From: DISPLAY-remote1
    <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
   Resent-To: DISPLAY-reto <ASCII-reto@example.net>
   Downgraded-Resent-To: DISPLAY-reto
    <NON-ASCII-reto@example.net <ASCII-reto@example.net>>
   Date: DATE

   MAIL_BODY

                      Figure 3: MIME decoded message

A.1.  Displaying example

   This example shows processes of 'Displaying downgraded message' for how to display the message in Figure 2.

   First, perform Step 1. 2, above,
   using the process defined in Section 3.  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?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
 =?UTF-8?Q?<ASCII-remote1@example.net>>?=
Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?=
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>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
 =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=

                    Figure 4: Displaying: Output Downgraded header fields

   Two of Step 1

   Then, 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 these to be reconstructed, the Address
   Header Fields' Preservation Header Fields:

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>?=
Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?=
 =?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?=
 =?UTF-8?Q?<NON-ASCII-reto@example.net_<ASCII-reto@example.net>>?=
              Figure 5: Header fields for the reconstruction

   Now, perform Step 2. 1, creating temporary fields.

   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:;
   Resent-From: DISPLAY-remote1
    <NON-ASCII-remote1@example.net <ASCII-remote1@example.net>>
   Resent-To: DISPLAY-reto
    <NON-ASCII-reto@example.net <ASCII-reto@example.net>>

                        Figure 6: Displaying: Output of Step 3

   Perform Step 4. 1

   In step 2, we set aside the "From", "To", and "Cc" header fields, and
   continue to step 3 with just "Resent-From" and "Resent-To" (the
   fields are removed that may appear more than once).  The fields we set aside will
   be picked up again later, in
   Figure 7.

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 step 9.

   Perform Steps 3 and 4.  The edit buffer contains re-generated ASCII
   header fields, canonicalized.

   Resent-From: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
   Resent-To: =?UTF-8?Q?DISPLAY-reto?= <ASCII-reto@example.net>

               Figure 7: Displaying: Output The edit buffer (output of Step 4 4)

   Perform Step Steps 5 to 7, comparison, for each header field.  Both the
   Resent-From and 6. Resent-To fields will match, and we will proceed to
   step 9.  (Step 8, iteration, does not apply in this example.

   Perform step 9, 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
    <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
   Downgraded-Unknown-Field: NON-ASCII-Unknown
   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>
   Resent-From: DISPLAY-remote1 <NON-ASCII-remote1@example.net
    <ASCII-remote1@example.net>>
   Resent-To: DISPLAY-reto <NON-ASCII-reto@example.net
    <ASCII-reto@example.net>>
   Date: DATE

   MAIL_BODY

                        Figure 8: Decoded message The final result

   As a result, in this simple example, all some original header fields are
   now displayed in the their original form.  Differences between Figure 1
   and Figure 8 are Return-Path, Downgraded-Mail-From, Downgraded-Rcpt-To
   header fields only.

Author's Address
   Downgraded-Rcpt-To, and Downgraded-Unknown-Field.

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: fujiwara@jprs.co.jp
   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   Email: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/