doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5825.txt b/doc/rfc/rfc5825.txt
new file mode 100644
index 0000000..3329495
--- /dev/null
+++ b/doc/rfc/rfc5825.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       K. Fujiwara
+Request for Comments: 5825                                          JPRS
+Category: Experimental                                          B. Leiba
+ISSN: 2070-1721                                      Huawei Technologies
+                                                              April 2010
+
+
+ Displaying Downgraded Messages for Email Address Internationalization
+
+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 Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5825.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.  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.
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 1]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Converting Downgraded Message Headers for Display ...............3
+      3.1. Considerations .............................................3
+      3.2. The Process ................................................3
+           3.2.1. No Reconstruction of the Envelope
+                  Information Preservation ............................4
+           3.2.2. Reconstructing the Address Header Fields'
+                  Preservation Header .................................4
+           3.2.3. The Unknown Header Fields' Preservation
+                  Header Fields .......................................5
+   4. Security Considerations .........................................6
+   5. Acknowledgements ................................................6
+   6. References ......................................................6
+      6.1. Normative References .......................................6
+      6.2. Informative References .....................................7
+   Appendix A.  Examples ..............................................8
+     A.1.  Displaying Example ........................................11
+
+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 Mail User
+   Agents (MUAs) or IMAP servers.  This document describes the
+   restoration methods 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].
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 2]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   Specialized terms used in this specification are defined in the EAI
+   overview [RFC4952] or in [RFC5321], [RFC5322], or the MIME documents
+   [RFC2045], [RFC2047], [RFC2183], and [RFC2231].
+
+   This document depends on [RFC5335] and [RFC5504].  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 [RFC2047] and MIME parameter value decoding defined by
+   [RFC2231].
+
+3.  Converting Downgraded Message Headers for Display
+
+3.1.  Considerations
+
+   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).
+
+3.2.  The Process
+
+   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 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", described in
+       RFC5504 Section 3.2 and in Section 3.2.2, below.
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 3]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   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, 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 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 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 [RFC2047].
+
+   2.  Apply "Email Header Fields Downgrading", defined in Section 5 of
+       [RFC5504], 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
+           [RFC5322].
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 4]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+       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.
+
+3.2.3.  The Unknown Header Fields' Preservation Header Fields
+
+   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 Section 3.2.2, above, for those fields about which
+   it knows.  (Note that the whitespace canonicalization rule might not
+   be applicable to some header fields.)
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 5]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+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,
+   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 Section 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 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 [RFC5504] and
+   [RFC4952].
+
+5.  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.
+
+6.  References
+
+6.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.
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 6]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   [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.
+
+6.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 & Leiba              Experimental                      [Page 7]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+Appendix A.  Examples
+
+   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 [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 8]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   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?<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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                      [Page 9]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   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
+    <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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                     [Page 10]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+A.1.  Displaying Example
+
+   This example shows how to display the message in Figure 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: 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?<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
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                     [Page 11]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   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
+    <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>>
+
+                  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
+    NON-ASCII-remote2@example.org 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                     [Page 12]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+   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
+    <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
+
+                        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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                     [Page 13]
+
+RFC 5825             Displaying Downgraded Messages           April 2010
+
+
+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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara & Leiba              Experimental                     [Page 14]
+