RFC 5825 - Displaying Downgraded Messages for Email Address Internationalization 日本語訳

URL : https://tools.ietf.org/html/rfc5825
タイトル : 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.

この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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で取得することができます。

著作権表示

著作権（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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

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]は電子メールアドレス構造、構文、および電子メールのヘッダフォーマットを拡張します。国際化電子メールメッセージの拒絶反応を回避するために、ダウングレードメカニズム[RFC5504]は配信パスでサーバーがUTF8SMTP拡張をサポートしていない従来の電子メールメッセージに国際化されたメッセージを変換します。メッセージは「Downgraded-」ヘッダフィールドを持っている以外格下げメッセージは、従来の電子メールメッセージです。

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

この文書のキーワード "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デコード」は、[RFC2231]で定義された両方の「エンコードされたワード」[RFC2047]で定義されたデコードおよび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]:

格下げヘッダフィールドの3つのタイプが[RFC5504]のセクション3に記載されています。

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

RFC5504の3.1節で、セクション3.2.1以下で説明1.「エンベロープ情報の保存ヘッダフィールド」、。

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

RFC5504 3.2節で、以下のセクション3.2.2で説明2.「アドレスヘッダフィールド保存ヘッダフィールド」、。

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

RFC5504 3.3節で、以下のセクション3.2.3で説明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:

編集バッファにおいて、新たなヘッダフィールドを作成します。

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

（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で定義された「電子メールヘッダフィールドのダウングレード」を、適用します。プロセスは、1つのASCIIヘッダーフィールドであり、他方はアドレスヘッダフィールド保存ヘッダフィールドであり、2つのヘッダフィールドを生成します。比較バッファ1内に生成されたASCIIヘッダーフィールドを置きます。

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

3.比較バッファ1のヘッダフィールドを正規化。

       1.  Unfold all header field continuation lines as described in
           [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.「」1スペースの前の文字と<メールボックス一覧>区切り後の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があることを確認してください。空白文字が欠落している場合は、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.

比較バッファ2両者が一致した場合にヘッダーフィールドと比較バッファ1内のヘッダフィールドを比較6. 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.メッセージのヘッダに対応するフィールドの次のインスタンスを見つけ。見つからなかった場合は1が見つかった場合は、手順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.編集バッファ内の1つで配置ヘッダフィールドを交換します。あなたがこれを行うときは、ヘッダフィールドを並べ替えてはなりません。それは、同じ場所にフィールドを交換することが重要です。メッセージヘッダにターゲット格下げヘッダフィールドを削除します。

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およびステップ7で行わ比較しMIMEデコードヘッダフィールドを生成する場合に成功している情報の損失を生じない「Downgraded-」ヘッダフィールドを使用するときに実際のヘッダフィールドからの情報を隠します。何の情報が失われないことを確実にするために、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 WGに開発されました。重要なコメントや提案はジョン・クレンシン、ハラルドAlvestrand、クリス・ニューマン、ランドールGellens、チャールズリンジー、マルコス・サンス、アレクセイ・メルニコフ、パシEronen、フランクEllermann、エドワード・ルイス、S. Moonesamy、およびJETのメンバーから受け取りました。

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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ドルナー、S.、およびK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、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]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。

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

[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。

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

[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、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]藤原、K.とY.米谷、 "メールアドレスの国際化のためのメカニズムをダウングレード"、RFC 5504、2009年3月。

6.2. Informative References

6.2. 参考文献

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

[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。

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

[RFC5336]八尾、J.とW.真央、 "国際化メールアドレスのSMTP拡張"、RFC 5336、2008年9月。

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

[RFC5337]ニューマン、C.とA.メルニコフ、 "国際配送状況や処分通知"、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]と3つのヘッダフィールド、「不明場」、「憤慨-から」、および「憤慨-TO」の「例1」から来て、追加されます。例えば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

メッセージID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：NON-ASCII-SUBJECT不明-フィールド：NON-ASCII-不明者：DISPLAY-ローカル<NON-ASCII-local@example.com <ASCII-ローカル@ example.com >>へ：DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >> Ccの：DISPLAY-REMOTE2 <NON-ASCII-remote2@example.org>のResent-から： DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >>のResent-TO：DISPLAY-レト<NON-ASCII-reto@example.net <ASCII-reto@example.net >>日付：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.

送達格下げメッセージがAリターンパスヘッダが最終宛先MTAによって追加される図2に示されています。いくつかの「受信」ヘッダフィールドを追加してもよいです。

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

リターンパス：<ASCII-local@example.com>受付：...ダウングレードメールを-から：？？= UTF-8 Q <NON-ASCII-local@example.com _ = = UTF-8？？？？ Q <ASCII-local@example.com >> =-RCPT-に格下げ：？？？？？？？？？= UTF-8 Q <NON-ASCII-remote1@example.net _ = = UTF-8 Q <ASCII ？-remote1@example.net >> =メッセージ-ID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：= UTF-8 Q NON-ASCII-SUBJECT =ダウングレード - 不明 - フィールド：？？？？= UTF-8 Q NON-ASCII-不明？？？？=から：？？？= UTF-8 Q DISPLAY-ローカル= <ASCII-local@example.com>ダウングレード-から：？？？？= UTF-8 Q DISPLAY-、LOCAL_LISTENER <NON-ASCII-ローカル@例。？？？COM _ = = UTF-8 Q <ASCII-local@example.com >> =に：？？？？？？= UTF-8 Q DISPLAY-REMOTE1 = <ASCII-remote1@example.net>ダウングレード-へ：？？？？？？= UTF-8 Q DISPLAY-REMOTE1 _ = = UTF-8 Q <NON-ASCII-remote1@example.net_ <ASCII-remote1@example.net >> = Ccと：？？？= UTF- 8？Q？DISPLAY-REMOTE2？=国際アドレスが削除=?UTF-8?Q?NON-ASCII-remote2@example.org?= :;格下げ-CC：？？？？？？？= UTF-8 Q DISPLAY-REMOTE2 _ = = UTF-8 Q <NON-ASCII-remote2@example.org> =のResent-から：？？？= UTF-8 Q？？DISPLAY-REMOTE1 = <ASCII-remote1@example.net>ダウングレード-のResent-から：？？？？？？= UTF-8 Q DISPLAY-REMOTE1 _ = = UTF-8 Q <NON-ASCII-REMOTE1例@？。 net_ <ASCII-remote1@example.net >> =のResent-TO：？= UTF-8 Q DISPLAY-レト= <ASCII-reto@example.net>ダウングレード-のResent-TO：？？？？？= UTF-8 ？？？？？？Q DISPLAY-レト_ = = UTF-8 Q <NON-ASCII-reto@example.net_ <ASCII-reto@example.net >> =日：？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-復号されたメッセージを示し、「に」、「CC」、「憤慨-から」、「憤慨-TO」および「不明フィールド」などのヘッダフィールド、 "ダウングレード-TO"、 "ダウングレード-CC"、 "ダウングレード-憤慨-TO" "ダウングレード-憤慨-から" "から、ダウングレード"、および "ダウングレード-不明フィールド" ヘッダフィールド。

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

リターンパスを<ASCII-local@example.com>受信：...ダウングレードメール-から：<NON-ASCII-local@example.com <ASCII-local@example.com >>ダウングレード-RCPT-TO： <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >>メッセージ-ID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：ダウングレード - 不明 - フィールドをNON-ASCII-SUBJECT：NON-ASCII-不明者：DISPLAY-ローカル<ASCII-local@example.com>ダウングレード-から： DISPLAY-Localに<NON-ASCII-local@example.com <ASCII-local@example.com >>：DISPLAY-REMOTE1 <ASCII-remote1@example.net>ダウングレード-TO：DISPLAY-REMOTE1 <NON-ASCII-REMOTE1 @ example.net <ASCII-remote1@example.net >> Ccの：DISPLAY-REMOTE2国際アドレスNON-ASCII-remote2@example.org削除:;格下げ-CC：DISPLAY-REMOTE2 <NON-ASCII-remote2@example.org>のResent-から：DISPLAY-REMOTE1 <ASCII-remote1@example.net>格下げ-のResent-から：DISPLAY-REMOTE1 <NON-ASCII-REMOTE1 @ example.net <ASCII-remote1@example.net >>のResent-TO：DISPLAY-レト<ASCII-reto@example.net>-のResent-に格下げ：DISPLAY-レト<NON-ASCII-reto@example.net <ASCII -reto@example.net >>日：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- *フィールドを選択すると、これを提供します：

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

格下げメール-から：？？？？？？？？= UTF-8 Q <NON-ASCII-local@example.com _ = = UTF-8 Q <ASCII-local@example.com >> =格下げ-Rcpt- To：？？？？？？？= UTF-8 Q <NON-ASCII-remote1@example.net _ = = UTF-8 Q <ASCII-remote1@example.net >> =ダウングレード - 不明 - フィールド：？=？ UTF-8 Q NON-ASCII-不明=ダウングレード-から：？？？？？？？？？= UTF-8 Q DISPLAY-、LOCAL_LISTENER <NON-ASCII-local@example.comは_ = = UTF-8 Q <ASCII？ -local@example.com >> =-に格下げ：？？？？？？？？= UTF-8 Q DISPLAY-REMOTE1 _ = = UTF-8 Q <NON-ASCII-remote1@example.net_ <ASCII-REMOTE1 @ example.net >> =ダウングレード-CC：？？？？？？？？？= UTF-8 Q DISPLAY-REMOTE2 _ = = UTF-8 Q <NON-ASCII-remote2@example.org> =ダウングレード-のResent-から：？？？？？？？？= UTF-8 Q DISPLAY-REMOTE1 _ = = UTF-8 Q <NON-ASCII-remote1@example.net_ <ASCII-remote1@example.net >> =ダウングレード-のResent-TO： =？UTF-8？Q？DISPLAY-レト_？= =？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>>?=

格下げ-から：？？？？？？？？= UTF-8 Q DISPLAY-、LOCAL_LISTENER <NON-ASCII-local@example.com _ = = UTF-8 Q <ASCII-local@example.com >> =格下げ-へ：？？？？？？？？= UTF-8 Q DISPLAY-REMOTE1 _ = = UTF-8 Q <NON-ASCII-remote1@example.net_ <ASCII-remote1@example.net >> =ダウングレード-CC：=？ UTF-8 Q DISPLAY-REMOTE2 _ = = UTF-8 Q <NON-ASCII-remote2@example.org> =ダウングレード-のResent-から：？？？？？？？？？？= UTF-8 Q DISPLAY-remote1_？？= = UTF-8 Q <NON-ASCII-remote1@example.net_ <ASCII-remote1@example.net >> =ダウングレード-のResent-TO：？？？？？？？= UTF-8 Q DISPLAY-レト_ = =？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>>

投稿者：DISPLAY-ローカル<NON-ASCII-local@example.com <ASCII-local@example.com >>へ：DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >> CC：DISPLAY-REMOTE2 <NON-ASCII-remote2@example.org>のResent-から：DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >>のResent-TO：DISPLAY-レト<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>

投稿者：DISPLAY-ローカル<ASCII-local@example.com>へ：DISPLAY-REMOTE1 <ASCII-remote1@example.net> Ccの：DISPLAY-REMOTE2国際アドレスNON-ASCII-remote2@example.org削除:;再送-から：DISPLAY-REMOTE1 <ASCII-remote1@example.net>のResent-TO：DISPLAY-レト<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.

各ヘッダフィールドに、6、比較するステップ4を実行します。ファイブヘッダフィールド、「から」、「へ」、「CC」、「憤慨し-から」と「のResent-TO」フィールドが一致し、我々は8（ステップ7、反復は、この中には適用されないのステップに進みます例。

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

順序を変更せずに、適用可能なすべてのフィールドを置き換え、ステップ8を実行します。そして、表示のために、すべてのものの上にMIMEのデコードを行います。

リターンパスを<ASCII-local@example.com>受信：...ダウングレードメール-から：<NON-ASCII-local@example.com <ASCII-local@example.com >>ダウングレード-RCPT-TO： <NON-ASCII-remote1@example.net> <ASCII-remote1@example.net>メッセージ-ID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：ダウングレード - 不明 - フィールドをNON-ASCII-SUBJECT：NON-ASCII-不明者：DISPLAY-ローカル<NON-ASCII-local@example.com <ASCII- local@example.com >>へ：DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >> Ccの：DISPLAY-REMOTE2 <NON-ASCII-remote2@example.org>はResent-投稿者：DISPLAY-REMOTE1 <NON-ASCII-remote1@example.net <ASCII-remote1@example.net >>のResent-TO：DISPLAY-レト<NON-ASCII-reto@example.net <ASCII-reto@example.net >>日：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

かずのりふじわらじゃぱんれぎｓｔｒｙせｒゔぃせｓこ。、Ｌｔｄ。ちよだふぃｒｓｔＢｌｄｇ。えあｓｔ１３Ｆ、３ー８ー１にしーかんだちよだーく、ときょ１０１ー００６５じゃぱん

Phone: +81-3-5215-8451 EMail: fujiwara@jprs.co.jp

電話：+ 81-3-5215-8451 Eメール：fujiwara@jprs.co.jp

Barry Leiba Huawei Technologies

バリー・レイバ、華為技術

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

電話：+1 646 827 0648 Eメール：barryleiba@computer.org URI：http://internetmessagingtechnology.org/