[要約] RFC 5825は、メールアドレスの国際化に関するダウングレードされたメッセージの表示についてのガイドラインです。その目的は、メールクライアントが国際化されたメールアドレスを適切に表示できるようにすることです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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]は、メールアドレス構造、構文、および電子メールヘッダー形式を拡張します。国際化された電子メールメッセージの拒否を回避するために、格下げメカニズム[RFC5504]は、配信パスのサーバーがUTF8SMTP拡張機能をサポートしていない場合、国際化されたメッセージを従来の電子メールメッセージに変換します。格下げされたメッセージは、メッセージが「ダウングレードされた」ヘッダーフィールドを除いて、従来の電子メールメッセージです。
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]で定義されているエンコーディングが正確に可逆的ではなく、「受信」ヘッダーフィールドのダウングレードが句情報の「受信」ヘッダーフィールドのダウングレードが削除されるため、格下げの完全な逆機能は存在しません。格下げの修復は、メールユーザーエージェント（MUAS）やIMAPサーバーなどの格下げメッセージの最終目的地で一度行う必要があります。このドキュメントでは、MUASに格下げされたメッセージを表示するための復元方法について説明します。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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パラメーター値デコードの両方に使用されます。
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は、状況をユーザーに伝えることを選択する場合があります（「セキュリティ上の考慮事項」セクションを参照）。
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]で説明されているように、すべてのヘッダーフィールドをデコードします。
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.
エンベロープ情報保存ヘッダーフィールドは、ダウングレードプロセスによって追加された可能性のある新しいフィールドです。それらは元のメッセージに表示されたフィールドを表していないため、このプロセスはそれらに適用できません。
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つからヘッダーフィールドの表示可能なコピーを構築するには、次の手順に従ってください。
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) フィールド名については、格下げされたフィールド名から「ダウングレード - 」プレフィックスを削除します。たとえば、「ダウングレードから」は「from」になり、「格下げされた逆」が「resティから」になります。
(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で定義されている「電子メールヘッダーフィールドダウングレード」を編集バッファーのフィールドに適用します。このプロセスは2つのヘッダーフィールドを生成します。1つはASCIIヘッダーフィールドで、もう1つはアドレスヘッダーフィールドの保存ヘッダーフィールドです。生成された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> separator "、"の前に1つのスペース文字があり、1つのスペース文字があることを確認してください。スペース文字が欠落している場合は、挿入します。
3. Ensure that there is one space character before and one after each <comment>. If a space character is missing, insert one.
3. 前に1つのスペース文字があり、それぞれ<コメント>の後に1つのスペース文字があることを確認してください。スペース文字が欠落している場合は、挿入します。
4. Decode each <encoded-word> whose charset is "UTF-8".
4. チャーセットが「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.
5. 1つ以上の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のヘッダーフィールドを比較バッファーのヘッダーフィールドと比較します。それらが一致する場合は、ステップ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に進みます。1つが見つからない場合は、停止します。メッセージに置き換えが見つからないため、この格下げフィールドを使用できません。
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. 配置されたヘッダーフィールドを編集バッファーのヘッダーフィールドに置き換えます。これを行うときは、ヘッダーフィールドを並べ替えてはいけません。同じ場所でフィールドを交換することが重要です。メッセージヘッダーのターゲット格下げヘッダーフィールドを削除します。
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の手順と同様の手順を使用する場合があります。（いくつかのヘッダーフィールドには、Whitespace Canonicalizationルールが適用されない可能性があることに注意してください。）
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は「線から」を変更できるため、組織の外部から到着するメッセージが内部メールと簡単に区別できます。その書き換えの結果、「From」ヘッダーフィールドは、「ダウングレードされた」ヘッダーフィールドと一致しない可能性があります。
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]の「セキュリティ上の考慮事項」セクションを参照してください。
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 WGで開発されました。ジョン・クレンシン、ハラルド・アルベスランド、クリス・ニューマン、ランドール・ゲレンズ、チャールズ・リンジー、マルコス・サンツ、アレクセイ・メルニコフ、パシ・エロネン、フランク・エラーマン、エドワード・ルイス、S。ムーナミー、ジェットメンバーから重要なコメントと提案が受け取られました。
[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、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：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、「インターネットメッセージでのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、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 2231、1997年11月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y。、「国際化された電子メールヘッダー」、RFC 5335、2008年9月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504] Fujiwara、K。およびY. Youneya、「電子メールアドレス国際化のための格下げメカニズム」、RFC 5504、2009年3月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336] Yao、J。およびW. Mao、「国際化された電子メールアドレスのSMTP拡張」、RFC 5336、2008年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月。
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」と3つのヘッダーフィールド、「未知のフィールド」、「resent-from」、および「resent-to」から掲載されています。UTF8SMTPメッセージの例を図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
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
MAIL_BODY
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-decodedメッセージを示しています。受信者は、オリジナルの「from」、「 "to」、「cc」、「resent from」、「resent」、および" unknown-field」ヘッダーフィールドを読み取ることができます。「ダウングレードから「ダウングレード」、「ダウングレード」、「ダウングレード-CC」、「格下げされたレセント」、「格下げされたレセント」、および「ダウングレードされた未知のフィールド」ヘッダーフィールド。
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
mail_body
Figure 3: MIME-decoded message
図3：MIME-DECODEDメッセージ
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>>?=
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.
2つのフィールド、「ダウングレード型メールからのメイル」と「ダウングレード-RCPT-to」は、エンベロープ情報保存ヘッダーフィールドであり、再構築されません。1つのフィールド、「格下げされていないフィールド」は、未知のヘッダーフィールドの保存ヘッダーフィールドであり、再構築されません。これにより、アドレスヘッダーフィールドの保存ヘッダーフィールドが再構築されます。
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
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>>
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>
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の比較を実行します。5つのヘッダーフィールド、 "from"、 "to"、 "cc"、 "resent-from"、 "Resent-to"フィールドが一致し、ステップ8に進みます（ステップ7、反復はこれには適用されません。例。
Perform step 8, replacing all applicable fields, without changing the order. Then, do MIME decoding on everything, for display.
順序を変更せずに、適用されるすべてのフィールドを置き換えるステップ8を実行します。次に、ディスプレイのために、すべてをすべてにデコードします。
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-to、および格下げされていないフィールドです。
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
Kazunori Fujiwara Japan Registry Services Co.、Ltd。Chiyoda First Bldg。イースト13F、3-8-1西カンダチヨーダクー、東京101-0065日本
Phone: +81-3-5215-8451
EMail: fujiwara@jprs.co.jp
Barry Leiba Huawei Technologies
Barry Leiba Huawei Technologies
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/