Internet Engineering Task Force (IETF)                       K. Fujiwara
Request for Comments: 5825                                          JPRS
Category: Experimental                                          B. Leiba
ISSN: 2070-1721                                      Huawei Technologies
                                                              April 2010
        
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.

本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

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.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问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.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

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 ....................................................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
1. 介绍

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.

电子邮件地址国际化(UTF8SMTP)扩展文档集[RFC4952][RFC5336][RFC5335][RFC5337]扩展了电子邮件地址结构、语法和电子邮件头格式。为避免拒绝国际化电子邮件,当传递路径中的服务器不支持UTF8SMTP扩展时,降级机制[RFC5504]将国际化邮件转换为传统电子邮件。降级邮件是传统的电子邮件邮件,但邮件的标题字段为“降级-”。

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.

降级的完美反向功能不存在,因为[RFC2047]中定义的编码不完全可逆,并且“接收”标题字段降级可能会删除子句信息。降级恢复应在降级邮件的最终目的地(如邮件用户代理(MUA)或IMAP服务器)执行一次。本文档描述了在MUA中显示降级消息的恢复方法。

2. Terminology
2. 术语

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

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

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

本规范中使用的专用术语在EAI概述[RFC4952]或[RFC5321]、[RFC5322]或MIME文档[RFC2045]、[RFC2047]、[RFC2183]和[RFC2231]中定义。

This document depends on [RFC5335] and [RFC5504]. Key words used in those documents are used in this document, too.

本文件取决于[RFC5335]和[RFC5504]。这些文件中使用的关键词也在本文件中使用。

The term "MIME decode" is used for both "encoded-word" decoding defined by [RFC2047] and MIME parameter value decoding defined by [RFC2231].

术语“MIME解码”用于[RFC2047]定义的“编码字”解码和[RFC2231]定义的MIME参数值解码。

3. Converting Downgraded Message Headers for Display
3. 转换降级的邮件标题以进行显示
3.1. Considerations
3.1. 考虑

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.

某些标题字段(如“Resent-*”字段)的顺序很重要。从降级字段重新生成原始字段的过程不得对字段重新排序。

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

在重建特定降级标题字段失败的任何情况下,消息中应保留两个标题字段(“降级YYY”标题字段和“YYY”标题字段)。MUA可以选择将情况告知用户(参见“安全注意事项”部分)。

3.2. The Process
3.2. 过程

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.

MUA可以解码并重新生成邮件的原始标头字段(邮件传输代理(MTA)和邮件传递代理(MDA)不应尝试这样做;它应该留给MUA处理)。此过程可用于大致反转降级过程,但并不总是准确构造原始标题字段。

Three types of downgraded header fields are described in Section 3 of [RFC5504]:

[RFC5504]第3节中描述了三种类型的降级报头字段:

1. "Envelope Information Preservation Header Fields", described in RFC5504 Section 3.1 and in Section 3.2.1, below.

1. RFC5504第3.1节和第3.2.1节中描述的“信封信息保存标题字段”。

2. "Address Header Fields' Preservation Header Fields", described in RFC5504 Section 3.2 and in Section 3.2.2, below.

2. RFC5504第3.2节和第3.2.2节中描述的“地址头字段的保存头字段”。

3. "Unknown Header Fields' Preservation Header Fields", described in RFC5504 Section 3.3 and in Section 3.2.3, below.

3. RFC5504第3.3节和第3.2.3节中描述的“未知标题字段的保存标题字段”。

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

处理降级的报头字段后,解码所有报头字段,如[RFC2047]和[RFC2231]中所述。

3.2.1. No Reconstruction of the Envelope Information Preservation Header Fields

3.2.1. 信封信息保存头字段不重建

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

3.2.2. 重建地址头字段的保留头字段

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.

重建地址头字段的保留头字段是可选的,并且可以单独对每个字段作出决定。特别是,处理“Resent-*”头字段可能不太重要,因此实现可能会选择跳过这些字段。

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:

1. 在编辑缓冲区中,创建新的标题字段:

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

(a) 对于字段名,从降级字段名中删除“降级-”前缀。例如,“降级自”变为“自”,而“降级的重新发送到”变为“重新发送到”。

(b) For the field value, decode the MIME-encoded value of the downgraded field according to [RFC2047].

(b) 对于字段值,根据[RFC2047]解码降级字段的MIME编码值。

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.

2. 将[RFC5504]第5节中定义的“电子邮件标题字段降级”应用于编辑缓冲区中的字段。该过程生成两个标头字段,一个是ASCII标头字段,另一个是地址标头字段的保留标头字段。将生成的ASCII标头字段放入比较缓冲区1。

3. Canonicalize the header field in the comparison buffer 1:

3. 规范化比较缓冲区1中的标头字段:

1. Unfold all header field continuation lines as described in [RFC5322].

1. 按照[RFC5322]中的说明展开所有标题字段续行。

2. Ensure that there is one space character before and one after the <mailbox-list> separator ",". If a space character is missing, insert one.

2. 确保<mailbox list>分隔符“,”前后各有一个空格字符。如果缺少空格字符,请插入一个。

3. Ensure that there is one space character before and one after each <comment>. If a space character is missing, insert one.

3. 确保每个<comment>前后各有一个空格字符。如果缺少空格字符,请插入一个。

4. Decode each <encoded-word> whose charset is "UTF-8".

4. 解码每个字符集为“UTF-8”的<encoded word>。

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.

5. 将一个或多个WSP字符的所有序列转换为单个空格字符。这里的WSP字符包括折线边界前后的字符。

6. Delete all WSP characters at the end of each unfolded header field value.

6. 删除每个展开的标题字段值末尾的所有WSP字符。

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.

7. 删除将标题字段名称与标题字段值分隔的冒号前后剩余的任何WSP字符,保留冒号分隔符。

4. Locate the first instance of the corresponding field in the message's headers.

4. 在消息头中找到相应字段的第一个实例。

5. Canonicalize the located field as in step 3, and put the result into comparison buffer 2.

5. 按照步骤3规范化定位的字段,并将结果放入比较缓冲区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.

6. 将比较缓冲区1中的标头字段与比较缓冲区2中的标头字段进行比较。如果匹配,请转至步骤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.

7. 在消息头中找到相应字段的下一个实例。如果找到一个,请转至步骤5。如果未找到任何字段,请停止:您无法使用此降级字段,因为在消息中找不到替换字段。

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.

8. 将定位的标题字段替换为编辑缓冲区中的标题字段。执行此操作时,不得对标题字段重新排序;在同一位置替换字段很重要。删除消息标头中的目标降级标头字段。

3.2.3. The Unknown Header Fields' Preservation Header Fields
3.2.3. 未知标头字段的保留标头字段

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

除非MUA对特定字段有特殊了解,否则未知标题字段的保存标题字段应保持原样。具备此类知识的MUA可使用类似于上文第3.2.2节中程序的程序,用于其知道的领域。(请注意,空白规范化规则可能不适用于某些标头字段。)

4. Security Considerations
4. 安全考虑

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.

虽然任何电子邮件头中的信息通常都应该受到怀疑,但当前的电子邮件系统通常采用各种机制和协议来提高信息的可信度。例如,组织的边界MTA可以修改“发件人”行,以便从组织外部收到的邮件可以很容易地与内部电子邮件区分开来。作为重写的结果,“发件人”标题字段可能与“降级发件人”标题字段不匹配。

A MUA MAY emphasize bogus or broken address header fields' preservation header fields found in step 7 of Section 3.2.2.

MUA可能强调第3.2.2节步骤7中发现的伪造或损坏的地址头字段的保存头字段。

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.

如果在第3.2.2节的步骤1中生成MIME解码的报头字段,并且在步骤7中进行的比较成功,则在使用“降级”报头字段时隐藏实际报头字段中的信息不会导致信息丢失。为了确保没有信息丢失,MUA应该有一个函数,该函数使用接收到的实际消息(有/没有MIME解码)来呈现消息。

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

在这里,我们将重点放在显示降级消息的问题上。有关一般降级和国际化消息的更多讨论,请参阅[RFC5504]和[RFC4952]中的“安全注意事项”部分。

5. Acknowledgements
5. 致谢

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.

本文件与[RFC5504]分开。这两个文件都是在EAI工作组中开发的。来自约翰·克莱辛、哈拉尔·阿尔韦斯特朗、克里斯·纽曼、兰德尔·盖伦斯、查尔斯·林赛、马科斯·桑兹、阿列克西·梅尔尼科夫、帕西·埃伦、弗兰克·埃勒曼、爱德华·刘易斯、S.穆内萨米和喷气机成员的重要评论和建议。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2045]Freed,N.和N.Borenstein,“多用途Internet邮件扩展(MIME)第一部分:Internet邮件正文格式”,RFC 20451996年11月。

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2047]Moore,K.,“MIME(多用途互联网邮件扩展)第三部分:非ASCII文本的消息头扩展”,RFC 2047,1996年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.

[RFC2183]Troost,R.,Dorner,S.,和K.Moore,“在Internet消息中传递表示信息:内容处置头字段”,RFC 2183,1997年8月。

[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.

[RFC2231]Freed,N.和K.Moore,“MIME参数值和编码字扩展:字符集、语言和连续体”,RFC 22311997年11月。

[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.

[RFC4952]Klensin,J.和Y.Ko,“国际化电子邮件的概述和框架”,RFC 49522007年7月。

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

[RFC5322]Resnick,P.,Ed.“互联网信息格式”,RFC5222008年10月。

[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5335]Abel,Y.,“国际化电子邮件标题”,RFC 53352008年9月。

[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.

[RFC5504]Fujiwara,K.和Y.Yoneya,“电子邮件地址国际化的降级机制”,RFC 55042009年3月。

6.2. Informative References
6.2. 资料性引用

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5321]Klensin,J.,“简单邮件传输协议”,RFC 53212008年10月。

[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

[RFC5336]Yao,J.和W.Mao,“国际化电子邮件地址的SMTP扩展”,RFC 53362008年9月。

[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.

[RFC5337]Newman,C.和A.Melnikov,“国际化交付状态和处置通知”,RFC 5337,2008年9月。

Appendix A. Examples
附录A.示例

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.

本节显示显示降级消息的示例。首先,显示原始UTF8SMTP消息及其降级消息的示例。示例来自[RFC5504]的“示例1”,添加了三个标题字段,“未知字段”、“重新发送自”和“重新发送至”。图1显示了UTF8SMTP消息的示例。

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

图1:原始消息

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.

交付的降级消息如图2所示。最终目标MTA将添加返回路径标头。可以添加一些“已接收”标题字段。

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

图2:降级消息

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.

图3显示了图2的MIME解码消息。收件人可以将原始的“发件人”、“收件人”、“抄送”、“转发自”、“转发至”和“未知字段”标题字段读取为“降级自”、“降级至”、“降级抄送”、“降级转发自”、“降级转发至”和“降级未知字段”标题字段。

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

图3:MIME解码消息

A.1. Displaying Example
A.1. 显示示例

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.

此示例显示了如何使用第3节中定义的流程显示上面图2中的消息。为简单起见,我们将同时显示所有适用字段的重建。

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>>?=
        
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

图4:降级的标题字段

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.

其中两个字段“降级邮件发件人”和“降级Rcpt收件人”是信封信息保存头字段,将不会重新构造。其中一个字段“降级的未知字段”是未知标头字段的保留标头字段,也不会被重建。这使得地址头字段的保留头字段需要重新构造。

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>>?=
        
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

图5:重建的标题字段

Now, perform step 1 to the downgraded header fields shown in Figure 5 and create an edit buffer.

现在,对图5所示的降级标题字段执行步骤1,并创建一个编辑缓冲区。

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

图6:编辑缓冲区:步骤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".

将“电子邮件标题字段降级”应用于“编辑缓冲区”。它生成降级的ASCII头字段和地址头字段的保留头字段。后面的字段与降级标题字段相同。将前面的字段放入“比较缓冲区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>
        
   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

图7:比较缓冲区1:步骤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.

对每个标题字段执行步骤4至6“比较”。五个标题字段,“发件人”、“收件人”、“抄送”、“重新发送发件人”和“重新发送至”字段将匹配,我们将继续执行步骤8。(步骤7,迭代,不适用于本例。

Perform step 8, replacing all applicable fields, without changing the order. Then, do MIME decoding on everything, for display.

执行步骤8,替换所有适用字段,但不更改顺序。然后,对所有内容进行MIME解码,以便显示。

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

图8:最终结果

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.

因此,在这个简单的示例中,一些原始标题字段现在以其原始形式显示。图1和图8之间的区别在于返回路径、降级的邮件发件人、降级的Rcpt收件人和降级的未知字段。

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

日本东京101-0065西神田千代田区3-8-1号千代田第一大厦东13楼藤原和仁日本注册服务有限公司

   Phone: +81-3-5215-8451
   EMail: fujiwara@jprs.co.jp
        
   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/
        
   Phone: +1 646 827 0648
   EMail: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/