Network Working Group K. Fujiwara, Ed.
Request for Comments: 5504 Y. Yoneya, Ed.
Category: Experimental JPRS
March 2009
Downgrading Mechanism for Email Address Internationalization
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.
従来のメールシステムはSMTPエンベロープとメールヘッダフィールドにASCII文字のみを扱います。メールアドレスの国際化（UTF8SMTP）拡張子はSMTPエンベロープとメールヘッダフィールドでUTF-8文字を可能にします。配信パスでサーバーがUTF8SMTP拡張をサポートしていないとき、国際化電子メールメッセージを拒否しないようにするには、変換機構のいくつかの並べ替えが必要です。この文書では、メールアドレスの国際化のためのダウングレードのメカニズムについて説明します。これは、ダウングレードする方法ではなく、トンネルであることに注意してください。表示またはダウングレードのメッセージに返信するとき国際電子メールクライアントは、元の国際化アドレスやその他のデータを使用する場合がありますが、何の関連するアップ変換機構は、ありません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. New Header Fields Definition ....................................5
3.1. Envelope Information Preservation Header Fields ............5
3.2. Address Header Fields' Preservation Header Fields ..........6
3.3. Unknown Header Fields' Preservation Header Fields ..........6
4. SMTP Downgrading ................................................7
4.1. Path Element Downgrading ...................................7
4.2. ORCPT downgrading ..........................................8
5. Email Header Fields Downgrading .................................8
5.1. Downgrading Method for Each ABNF Element ...................8
5.1.1. RECEIVED Downgrading ................................9
5.1.2. UNSTRUCTURED Downgrading ............................9
5.1.3. WORD Downgrading ....................................9
5.1.4. COMMENT Downgrading .................................9
5.1.5. MIME-VALUE Downgrading ..............................9
5.1.6. DISPLAY-NAME Downgrading ............................9
5.1.7. MAILBOX Downgrading .................................9
5.1.8. ENCAPSULATION Downgrading ..........................10
5.1.9. TYPED-ADDRESS Downgrading ..........................10
5.2. Downgrading Method for Each Header Field ..................10
5.2.1. Address Header Fields That Contain <address>s ......10
5.2.2. Address Header Fields with Typed Addresses .........11
5.2.3. Downgrading Non-ASCII in Comments ..................11
5.2.4. Received Header Field ..............................11
5.2.5. MIME Content Header Fields .........................12
5.2.6. Non-ASCII in <unstructured> ........................12
5.2.7. Non-ASCII in <phrase> ..............................12
5.2.8. Other Header Fields ................................12
6. MIME Body-Part Header Field Downgrading ........................12
7. Security Considerations ........................................13
8. Implementation Notes ...........................................14
8.1. RFC 2047 Encoding .........................................14
8.2. Trivial Downgrading .......................................15
8.3. 7bit Transport Consideration ..............................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................19
Appendix A. Examples .............................................20
A.1. Downgrading Example 1 .....................................20
A.2. Downgrading Example 2 .....................................22
Traditional mail systems, which are defined by [RFC5321] and [RFC5322], allow ASCII characters in SMTP envelope and mail header field values. The UTF8SMTP extension ([RFC4952], [RFC5335], and [RFC5336]) allows UTF-8 characters in SMTP envelope and mail header field values.
[RFC5321]及び[RFC5322]で定義されている伝統的なメールシステムは、SMTPエンベロープとメールヘッダフィールド値のASCII文字を許可します。 UTF8SMTP拡張（[RFC4952]、[RFC5335]及び[RFC5336]）はSMTPエンベロープとメールヘッダフィールド値のUTF-8文字を可能にします。
If an envelope address or header field contains non-ASCII characters, the message cannot be delivered unless every system in the delivery path supports UTF8SMTP. This document describes a downgrading mechanism to avoid rejection of such messages when a server that does not support the UTF8SMTP extension is encountered. This downgrading mechanism converts envelope and mail header fields to an all-ASCII representation.
エンベロープアドレスまたはヘッダフィールドに非ASCII文字が含まれている場合は配信パス内のすべてのシステムがUTF8SMTPをサポートしている場合を除き、メッセージを配信することができません。この文書では、UTF8SMTP拡張をサポートしていないサーバーが検出されたときにそのようなメッセージの拒絶反応を回避するための格下げのメカニズムについて説明します。このダウングレードメカニズムは、すべての-ASCII表現にエンベロープとメールヘッダフィールドを変換します。
[RFC5335] allows UTF-8 characters to be used in mail header fields and MIME header fields. The downgrading mechanism specified here converts mail header fields and MIME header fields to ASCII.
[RFC5335]は、UTF-8文字をメールヘッダフィールドとMIMEヘッダフィールドに使用されることを可能にします。ここで指定したダウングレードメカニズムは、ASCIIにメールヘッダフィールドおよびMIMEヘッダフィールドを変換します。
This document does not change any protocols except by defining new header fields. It describes the conversion method from the internationalized email envelopes/messages that are defined in [RFC4952], [RFC5335], and [RFC5336] to the traditional email envelopes/messages defined in [RFC5321] and [RFC5322].
この文書は、新しいヘッダフィールドを定義することによって以外の任意のプロトコルを変更しません。これは[RFC5321]及び[RFC5322]で定義された伝統的な電子メール封筒/メッセージへの変換[RFC4952]で定義されている電子メール封筒/メッセージ国際から方法、[RFC5335]及び[RFC5336]を記述する。
Section 3.2 of [RFC5336] defines when downgrading occurs. If the SMTP client has a UTF8SMTP envelope or an internationalized message and the SMTP server doesn't support the UTF8SMTP extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized message to the SMTP server. The section lists 4 choices in this case. The fourth choice is downgrading, as described here.
ダウングレードが発生したときに[RFC5336]のセクション3.2で定義しています。 SMTPクライアントがUTF8SMTPエンベロープや国際化されたメッセージを持っており、SMTPサーバがUTF8SMTP拡張をサポートしていない場合は、SMTPクライアントがSMTPサーバーにUTF8SMTPエンベロープや国際化されたメッセージを送ってはいけません。セクションは、この場合には4つの選択肢を示しています。ここで説明したように、第4の選択は、ダウングレードされます。
Downgrading may be implemented in Mail User Agents (MUAs), Mail Submission Agents (MSAs), and Mail Transport Agents (MTAs) that act as SMTP clients. It may also be implemented in Message Delivery Agents (MDAs), Post Office Protocol (POP) servers, and IMAP servers that store or offer UTF8SMTP envelopes or internationalized messages to non-UTF8SMTP-compliant systems, which include message stores.
ダウングレードは、メールユーザエージェント（MUA）、メール発信エージェント（MSAは）、およびSMTPクライアントとして動作するメール転送エージェント（MTA）で実施することができます。また、メッセージ配信エージェント（のMDA）メッセージストアを含める非UTF8SMTP準拠のシステムに提供するUTF8SMTP封筒や国際化されたメッセージまたはを格納し、ポストオフィスプロトコル（POP）サーバー、およびIMAPサーバに実装することができます。
This document tries to define the downgrading process clearly and it preserves the original internationalized email information as much as possible.
この文書は明らかにダウングレードプロセスを定義しようとすると、それは可能な限り、元の国際化電子メールの情報を保存します。
Downgrading in UTF8SMTP consists of the following four parts:
UTF8SMTPにダウングレードするには、次の4つの部分から成ります。
o New header field definitions o SMTP downgrading o Email header field downgrading o MIME header field downgrading
O新しいヘッダフィールドの定義OのMIMEヘッダフィールドのダウングレードダウングレードO SMTP格下げOメールヘッダフィールド
In Section 3 of this document, many header fields starting with "Downgraded-" are introduced. They preserve the original envelope information and the original header fields.
このドキュメントのセクション3において、「Downgraded-」で始まる多くのヘッダフィールドが導入されます。彼らは、元のエンベロープ情報とオリジナルのヘッダフィールドを保持します。
SMTP downgrading is described in Section 4. It generates ASCII-only envelope information from a UTF8SMTP envelope.
SMTPの格下げは、それがUTF8SMTPエンベロープからASCIIのみのエンベロープ情報を生成し、第4項に記載されています。
Email header field downgrading is described in Section 5. It generates ASCII-only header fields.
メールヘッダフィールドの格下げは、それはASCIIのみのヘッダフィールドを生成し、第5節に記載されています。
MIME header fields are expanded in [RFC5335]. MIME header field downgrading is described in Section 6. It generates ASCII-only MIME header fields.
MIMEヘッダフィールドは、[RFC5335]に展開されています。 MIMEヘッダフィールド格下げそれはASCIIのみのMIMEヘッダフィールドを生成セクション6に記載されています。
Displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields is described in an another document ([DISPLAY]).
元々国際メールアドレスや国際ヘッダフィールドを含ま格下げメッセージを表示する別の文書（[DISPLAY]）に記載されています。
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]に記載されているように解釈されます。
All specialized terms used in this specification are defined in the Email Address Internationalization (EAI) overview [RFC4952], in the mail specifications [RFC5321] [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" are used with the definitions from [RFC4952].
本明細書中で使用されるすべての専門用語は、メールの仕様[RFC5321] [RFC5322]で、またはMIME文書で、メールアドレスの国際化（EAI）の概要[RFC4952]で定義されている[RFC2045] [RFC2047] [RFC2183] [RFC2231] 。用語「ASCIIアドレス」、「国際化電子メールアドレス」、「非ASCIIアドレス」、「アドレスi18mail」、「UTF8SMTP」、「メッセージ」、および「メーリングリスト」は[RFC4952]からの定義で使用されています。
This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key words used in those documents are used in this document, too.
この文書では、[RFC5335]、[RFC5336]、および[RFC5337]に依存します。それらの文書で使用されるキーワードは、あまりにも、このドキュメントで使用されています。
The term "non-ASCII" refers to a UTF-8 string that contains at least one non-ASCII character.
用語「非ASCII」は、少なくとも1つの非ASCII文字を含むUTF-8文字列を指します。
A "UTF8SMTP envelope" has email originator/recipient addresses expanded by [RFC5336] and [RFC5337].
「UTF8SMTPエンベロープは、」[RFC5336]と[RFC5337]で拡張電子メールの発信元/受信者アドレスを持っています。
A "UTF8SMTP message" is an email message expanded by [RFC5335].
「UTF8SMTPメッセージは」[RFC5335]によって拡張電子メールメッセージです。
New header fields starting with "Downgraded-" are defined here to preserve those original envelope and mail header field values that contain UTF-8 characters. During downgrading, one new "Downgraded-" header field is added for each original envelope or mail header field that cannot be passed as-is to a server that does not support UTF8SMTP. The original envelope or mail header field is removed or rewritten. Only those envelope and mail header fields that contain non-ASCII characters are affected. The result of this process is a message that is compliant with existing email specifications [RFC5321] and [RFC5322]. The original internationalized information can be retrieved by examining the "Downgraded-" header fields that were added.
「Downgraded-」で始まる新しいヘッダフィールドはUTF-8文字を含むものを、元のエンベロープとメールヘッダーフィールド値を維持するためにここで定義されています。ダウングレード時には、1新しい「Downgraded-」ヘッダフィールドはUTF8SMTPをサポートしていないサーバにそのまま渡すことはできませんそれぞれのオリジナル封筒やメールヘッダーフィールドに追加されます。元のエンベロープ又はメールヘッダフィールドを削除または書き換えられます。非ASCII文字が含まれているもののみエンベロープとメールヘッダフィールドが影響を受けます。このプロセスの結果は、既存の電子メールの仕様[RFC5321]と[RFC5322]に準拠したメッセージです。元の国際化情報が追加された「Downgraded-」ヘッダフィールドを調べることによって取得することができます。
SMTP envelope downgraded information <downgraded-envelope-addr> consists of the original non-ASCII address and the downgraded all-ASCII address. The ABNF [RFC5234] syntax is as follows:
SMTPエンベロープは、<格下げエンベロープ-addrに>情報をダウングレード元の非ASCIIアドレスと格下げすべて-ASCIIアドレスで構成されています。 ABNF [RFC5234]の構文は次のとおりです。
downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox FWS "<" Mailbox ">" ">" [CFWS]
格下げエンベロープ-ADDR = [FWS] "<" [A-D-L "："] uMailbox FWS "<" メールボックス ">" ">" [CFWS]
<uMailbox> is defined in [RFC5336]; <Mailbox> and <A-d-l> are defined in Section 4.1.2 of [RFC5321].
<uMailbox> [RFC5336]で定義されています。 <メールボックス>と<-D-L>は、[RFC5321]のセクション4.1.2で定義されています。
Two header fields, "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:", are defined to preserve SMTP envelope downgraded information. The header field syntax is specified as follows:
二つのヘッダフィールドは、「からメール-ダウングレード：」と「ダウングレード-RCPT-TO：」、SMTPエンベロープを維持するために定義された情報を格下げしています。次のようにヘッダフィールドの構文は指定されています。
fields =/ downgradedmailfrom / downgradedrcptto
フィールド= / downgradedmailfrom / downgradedrcptto
downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF
downgradedmailfrom = "ダウングレードメール-から：" 非構造化CRLF
downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF
downgradedrcptto = "-RCPT-に格下げ：" 非構造化CRLF
The unstructured content is downgraded-envelope-addr and treated as if it were unstructured, with [RFC2047] encoding (and charset UTF-8) as needed.
非構造化コンテンツを格下げエンベロープ-ADDR、それは構造化されていないかのように、必要に応じて、[RFC2047]をコードする（および文字セットUTF-8）を用いて、処理されます。
The address header fields' preservation header fields are defined to preserve the original header field. Their value field holds the original header field value. The header field syntax is specified as follows:
アドレス・ヘッダ・フィールド保存ヘッダフィールドは、元のヘッダフィールドを保存するために定義されています。その値フィールドは、元のヘッダフィールドの値を保持しています。次のようにヘッダフィールドの構文は指定されています。
fields =/ known-downgraded-headers ":" unstructured CRLF
フィールド= /知ら-格下げ - ヘッダ "：" 非構造化CRLF
known-downgraded-headers = "Downgraded-" original-headers
既知格下げ-ヘッダー=「Downgraded-」原稿ヘッダー
original-headers = "From" / "Sender" / "To" / "Cc" / "Bcc" / "Reply-To" / "Resent-From" / "Resent-Sender" / "Resent-To" / "Resent-Cc" / "Resent-Bcc" / "Resent-Reply-To" / "Return-Path" / "Disposition-Notification-To"
= / "憤慨-TO" /「憤慨/ "から" / "CC" / "のBcc" / "返信先" / "憤慨-から" / "憤慨、送信者" / "送信者" の "From" のオリジナル・ヘッダ-cc」/ "憤慨し-BCC" / "憤慨し、返信先" / "リターンパスを" / "処分-通知-へ"
To preserve a header field in a "Downgraded-" header field:
「Downgraded-」ヘッダフィールドにヘッダフィールドを保持するには：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1.値が元のヘッダフィールド値である新しい「Downgraded-」ヘッダフィールドを生成します。
2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so that the result is ASCII.
2.それは構造化されていないかのように生成されたヘッダフィールドの内容を扱い、そしてその結果がASCIIであるように、必要に応じて文字セットUTF-8と[RFC2047]符号化を適用します。
The unknown header fields' preservation header fields are defined to encapsulate those original header fields that contain non-ASCII characters and are not otherwise provided for in this specification. The encapsulation header field name is the concatenation of "Downgraded-" and the original name. The value field holds the original header field value.
未知のヘッダフィールド保存ヘッダフィールドは、非ASCII文字が含まれており、そうでなければ、本明細書において提供されていないそれらの元のヘッダフィールドをカプセル化するために定義されています。カプセル化ヘッダフィールド名は「Downgraded-」と元の名前の連結です。値フィールドは、元のヘッダフィールド値を保持します。
The header field syntax is specified as follows:
次のようにヘッダフィールドの構文は指定されています。
fields =/ unknown-downgraded-headers ":" unstructured CRLF
フィールド= /未知格下げ - ヘッダ「：」非構造化CRLF
unknown-downgraded-headers = "Downgraded-" original-header-field-name
未知格下げ-ヘッダー=「Downgraded-」オリジナルヘッダフィールド名
original-header-field-name = field-name
元のヘッダフィールド名=フィールド名
field-name = 1*ftext ftext = %d33-57 / ; Any character except %d59-126 ; controls, SP, and ":".
フィールド名= 1 * FTEXT FTEXT =％d33-57 /。 ％のd59-126を除く任意の文字。コントロール、SP、および "："。
To encapsulate a header field in a "Downgraded-" header field:
「Downgraded-」ヘッダフィールドにヘッダフィールドをカプセル化するには：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1.値が元のヘッダフィールド値である新しい「Downgraded-」ヘッダフィールドを生成します。
2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so the result is ASCII.
2.それは構造化されていないかのように生成されたヘッダフィールドの内容を扱い、そしてその結果がASCIIであるので、必要に応じて文字セットUTF-8と[RFC2047]符号化を適用します。
The targets of downgrading elements in an SMTP envelope are below:
SMTPエンベロープ内の要素を格下げの対象は以下の通りです：
o <reverse-path> of MAIL FROM command o <forward-path> of RCPT TO command o ORCPT parameter of RCPT TO command
O RCPT TOコマンドのORCPTパラメータoをRCPT TOコマンドのコマンドO <フォワードパス>、MAIL FROMの<パスを逆転>
<reverse-path> and <forward-path> are described in [RFC5321] and [RFC5336]. The ORCPT parameter is described in [RFC3461] and [RFC5337].
<パスを逆>と<フォワードパス>は、[RFC5321]及び[RFC5336]に記載されています。 ORCPTパラメータは、[RFC3461]及び[RFC5337]に記載されています。
Downgrading the <path> of MAIL FROM and RCPT TO commands uses the ALT-ADDRESS parameter defined in [RFC5336]. An SMTP command is downgradable if the <path> contains a non-ASCII address and the command has an ALT-ADDRESS parameter that specifies an ASCII address. Since only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS value for an all-ASCII address is invalid for use with this specification, and no interpretation is assigned to it. This restriction allows for future extension of the specification even though no such extensions are currently anticipated.
コマンドにFROM MAILとRCPTの<path>をダウングレードすると、[RFC5336]で定義されたALT-ADDRESSパラメータを使用します。 <path>は、ASCII以外のアドレスが含まれていると、コマンドはASCIIアドレスを指定するALT-ADDRESSパラメータを持っている場合はSMTPコマンドがダウングレードです。唯一の非ASCIIアドレスがダウングレードされているので、すべての-ASCIIアドレスのALT-ADDRESS値を指定すると、この仕様で使用するために無効であり、そして何の解釈はそれに割り当てられていません。この制限は、そのような拡張は、現在予想されていないにもかかわらず、仕様の将来の拡張が可能になります。
Note that even if no downgrading is performed on the envelope, message header fields and message body MIME header fields that contain non-ASCII characters MUST be downgraded. This is described in Sections 5 and 6.
何の格下げは、非ASCII文字を含むエンベロープ、メッセージヘッダーフィールドとメッセージ本文のMIMEヘッダフィールド上で実行されていない場合でも、ダウングレードしなければならないことに注意してください。これは、セクション5及び6に記載されています。
When downgrading, replace each <path> that contains a non-ASCII mail address with its specified alternative ASCII address, and preserve the original information using "Downgraded-Mail-From" and
ダウングレードする場合、その指定された代替ASCIIアドレスを持つ非ASCIIのメールアドレスが含まれている各<パス>を交換し、「ダウングレードメール-から」を使用して、元の情報を保存し、
"Downgraded-Rcpt-To" header fields as defined in Section 3. Before replacing, decode the ALT-ADDRESS parameter value because it is encoded as xtext [RFC3461].
それはXTEXT [RFC3461]として符号化されるので、「ダウングレード-RCPT-する」ヘッダフィールドを交換する前に、セクション3で定義されるように、ALT-ADDRESSパラメータ値をデコード。
To avoid disclosing recipient addresses, the downgrading process MUST NOT add the "Downgraded-Rcpt-To:" header field if the SMTP downgrading targets multiple recipients. See Section 7 for more details.
受信者のアドレスを開示しないようにするには、ダウングレードプロセスは、「ダウングレード-RCPT-TO：」を追加してはならないヘッダフィールドをSMTPの格下げは、複数の受信者をターゲットにしている場合。詳細については、セクション7を参照してください。
As a result of the recipient address downgrading, the domain part of the recipient address prior to downgrading might be different from the domain part of the new recipient address. If the result of address resolution for the domain part of the new recipient address contains the server at the connection destination of the SMTP session for the recipient address prior to downgrading, the SMTP connection is valid for the new recipient address. Otherwise, the downgrading process MUST NOT send the downgraded message to the new recipient address via the connection and MUST try to send the downgraded message to the new recipient address.
受信者のアドレス格下げの結果、前格下げに受信者アドレスのドメイン部分には、新しい受信者アドレスのドメイン部分と異なる場合があります。新しい受信者アドレスのドメイン部分のアドレス解決の結果は、前のダウングレードに受信者のアドレスのためのSMTPセッションの接続先のサーバーが含まれている場合は、SMTP接続は、新たな受信者アドレスに対して有効です。それ以外の場合は、ダウングレード・プロセスは、接続を介して新しい受信者のアドレスに格下げメッセージを送ってはいけませんし、新しい受信者のアドレスに格下げメッセージを送信しようとしなければなりません。
The "RCPT TO" command can have an ORCPT parameter if the Delivery Status Notification (DSN) extension [RFC3461] is supported. If the ORCPT parameter contains a "utf-8" type address and the address contains raw non-ASCII characters, the address MUST be converted to utf-8-addr-xtext form. Those forms are described in [RFC5337] and clarified by successor documents such as [DSNBIS].
配信状態通知（DSN）拡張[RFC3461]がサポートされている場合、「RCPT TOは、」コマンドがORCPTパラメータを持つことができます。 ORCPTパラメータは、「UTF-8」タイプのアドレスが含まれており、アドレスは、生の非ASCII文字が含まれている場合、アドレスはUTF-8-addrに-XTEXT形式に変換する必要があります。これらのフォームは、[RFC5337]に記載のような[DSNBIS]として後継文書によって明らかにされています。
Before converting to utf-8-addr-xtext form, remove xtext encoding.
UTF-8-ADDR-XTEXT形式に変換する前に、XTEXTエンコーディングを取り除きます。
This section defines the conversion method to ASCII for each header field that may contain non-ASCII characters.
このセクションでは、非ASCII文字が含まれていてもよい各ヘッダフィールドのASCIIに変換する方法を定義します。
[RFC5335] expands "Received:" header fields; [RFC5322] describes ABNF elements <mailbox>, <word>, <comment>, <unstructured>; [RFC2045] describes ABNF element <value>.
ヘッダーフィールド;：[RFC5335]は "受信" 展開します[RFC5322]はABNF要素<メールボックス>、<ワード>、<コメント>、<非構造化>を記述する。 [RFC2045]はABNF要素<値>を記述する。
Header field downgrading is defined below for each ABNF element. Downgrading an unknown header field is also defined as ENCAPSULATION downgrading. Converting the header field terminates when no non-ASCII characters remain in the header field.
ヘッダフィールド格下げは、各ABNF要素については、以下に定義されます。未知のヘッダーフィールドをダウングレードすることも封入格下げとして定義されます。何の非ASCII文字は、ヘッダフィールドに残っていないとき、ヘッダフィールドを変換すると終了します。
If the header field name is "Received:" and the FOR clause contains a non-ASCII address, remove the FOR clause from the header field. Other parts (not counting <comment>s) should not contain non-ASCII values.
ヘッダーフィールド名「を受信：」されている場合とFOR句は、非ASCIIアドレスが含まれている、ヘッダフィールドからFOR句を削除します。その他の部品（S <コメント>数えていない）は、非ASCII値を含めることはできません。
If the header field has an <unstructured> field that contains non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダフィールドは非ASCII文字が含まれている<非構造化>フィールドがある場合、文字セットUTF-8と[RFC2047]符号化を適用します。
If the header field has any <word> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダフィールドは、非ASCII文字を含む任意の<ワード>フィールドを持っている場合、文字セットUTF-8と[RFC2047]符号化を適用します。
If the header field has any <comment> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダフィールドに非ASCII文字を含む任意の<コメント>フィールドを持っている場合は、文字セットUTF-8で[RFC2047]エンコーディングを適用します。
If the header field has any <value> elements defined by [RFC2045] and the elements contain non-ASCII characters, encode the <value> elements according to [RFC2231] with charset UTF-8 and leave the language information empty. If the <value> element is <quoted-string> and it contains <CFWS> outside the DQUOTE, remove the <CFWS> before this conversion.
ヘッダフィールドは、任意の<value>を持っている場合、[RFC2045]で定義された要素および要素は、非ASCII文字を含む文字セットUTF-8と[RFC2231]に記載の<値>要素を符号化し、空の言語情報を残します。 <値>要素は、<引用符で囲まれた文字列>であり、それは<CFWS> DQUOTE外に含まれている場合は、この変換の前に<CFWS>を削除します。
If the header field has any <address> (<mailbox> or <group>) elements and they have <display-name> elements that contain non-ASCII characters, encode the <display-name> elements according to [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as WORD downgrading.
ヘッダフィールドは、任意の<アドレス>（<メールボックス>または<グループ>）要素を有し、彼らが持っている場合、<表示名>非ASCII文字が含まれている要素は、文字セットと[RFC2047]に記載の<表示名>要素をコードUTF-8。 DISPLAY-NAMEの格下げは、ワード格下げと同じアルゴリズムです。
The <mailbox> elements have no equivalent format for non-ASCII addresses. If the header field has any <mailbox> elements that contain non-ASCII characters, preserve the header field in the corresponding "Downgraded-" header field, which is defined in Section 3.2, and rewrite each <mailbox> element to ASCII-only format. The <mailbox> element that contains non-ASCII characters is one of three formats.
<メールボックス>要素は、非ASCIIアドレスには同等の形式を持っていません。ヘッダフィールドは、非ASCII文字を含む任意の<メールボックス>要素がある場合、セクション3.2で定義されている対応する「Downgraded-」ヘッダフィールドにヘッダフィールドを保存し、ASCIIのみのフォーマットに各<メールボックス>要素を書き換え。非ASCII文字が含まれている<メールボックス>要素は3つの形式の一つです。
o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
O [表示名] "<" UTF8-addrにスペック1つの* FCS "<" ADDRスペック ">>"
Rewrite it as:
[ Display-name ] "<" Addr-spec ">"
o [ Display-name ] "<" Utf8-addr-spec ">" o Utf8-addr-spec
O [表示名] "<" UTF8-ADDR-スペック ">" O UTF8-ADDR-スペック
Rewrite both as:
[ Display-name ] "Internationalized Address " Encoded-word
" Removed:;"
where the <Encoded-word> is the original <Utf8-addr-spec>
encoded according to [RFC2047].
If the header field contains non-ASCII characters and is such that no rule is given above, encapsulate it in a "Downgraded-" header field as described in Section 3.3 as a last resort.
ヘッダフィールドは非ASCII文字が含まれており、ルールが上記指定されていないようなものである場合、最後の手段として、セクション3.3で説明したように、「Downgraded-」ヘッダフィールドでそれをカプセル化します。
Applying this procedure to "Received:" header field is prohibited.
ヘッダフィールドは禁止されている：「受信」するために、この手順を適用します。
If the header field contains <utf-8-type-addr> and the <utf-8-type-addr> contains raw non-ASCII characters, it is in utf-8-address form. Convert it to utf-8-addr-xtext form as described in Section 4.2. COMMENT downgrading is also performed in this case. If the address type is unrecognized and the header field contains non-ASCII characters, then fall back to using ENCAPSULATION downgrading on the entire header field.
ヘッダフィールドは<UTF-8型-ADDR>を含み、<UTF-8型-ADDR>生非ASCII文字が含まれている場合は、UTF-8でアドレス形式です。セクション4.2で説明したように、UTF-8-ADDR-XTEXT形式に変換。 COMMENTの格下げは、この場合にも行われます。アドレスタイプが認識されないヘッダフィールドが非ASCII文字が含まれている場合、全体のヘッダフィールドにカプセル化ダウングレードを使用してにフォールバック。
Header fields are listed in [RFC4021]. This section describes the downgrading method for each header field.
ヘッダフィールドは、[RFC4021]に記載されています。このセクションでは、各ヘッダフィールドのダウングレード方法を説明します。
If the whole mail header field does not contain non-ASCII characters, email header field downgrading is not required. Each header field's downgrading method is described below.
全体のメールヘッダフィールドに非ASCII文字が含まれていない場合は、電子メールのヘッダフィールドのダウングレードが必要とされていません。各ヘッダフィールドのダウングレード方法について説明します。
From: Sender: To: Cc: Bcc:
投稿者：送信者：宛先：Ccと：Bccの：
Reply-To: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Bcc: Resent-Reply-To: Return-Path: Disposition-Notification-To:
返信先：憤慨し-から：憤慨し、送信者：憤慨し-TO：憤慨し-CC：憤慨し-のBcc：憤慨し、返信先：リターンパス：処分-通知-TO：
If the header field contains <mailbox> elements that contain non-ASCII addresses, preserve the header field in a "Downgraded-" header field before the conversion. Then perform COMMENT downgrading, DISPLAY-NAME downgrading, and MAILBOX downgrading.
ヘッダーフィールドは、ASCII以外のアドレスを含む<メールボックス>要素が含まれている場合は、変換前「Downgraded-」ヘッダフィールドにヘッダフィールドを保持します。そして、COMMENTの格下げ、DISPLAY-NAMEの格下げ、およびメールボックスのダウングレードを行います。
Original-Recipient: Final-Recipient:
オリジナル・受信者：最終受信者：
If the header field contains non-ASCII characters, perform TYPED-ADDRESS downgrading.
ヘッダフィールドに非ASCII文字が含まれている場合は、型指定されたアドレスダウングレードを行います。
Date: Message-ID: Resent-Message-ID: In-Reply-To: References: Resent-Date: Resent-Message-ID: MIME-Version: Content-ID: Content-Transfer-Encoding: Content-Language: Accept-Language: Auto-Submitted:
日付：メッセージID：憤慨し、メッセージID：イン返信先：参考文献：憤慨し-日：憤慨し、メッセージID：MIME-バージョン：コンテンツID：コンテンツ転送 - エンコード：コンテンツ言語：なAccept-言語：自動提出：
These header fields do not contain non-ASCII characters except in comments. If the header field contains UTF-8 characters in comments, perform COMMENT downgrading.
これらのヘッダフィールドは、コメントを除き、非ASCII文字が含まれていません。ヘッダフィールドはコメントでUTF-8文字が含まれている場合、COMMENTのダウングレードを行います。
Received:
受信：
Perform COMMENT downgrading and RECEIVED downgrading.
COMMENTの格下げし、受信したダウングレードを実行します。
Content-Type: Content-Disposition:
コンテンツタイプ：コンテンツディスポジション：
Perform MIME-VALUE downgrading and COMMENT downgrading.
MIME-VALUEの格下げとCOMMENTのダウングレードを実行します。
Subject: Comments: Content-Description:
件名：コメント：コンテンツの説明：
Perform UNSTRUCTURED downgrading.
非構造化ダウングレードを実行します。
Keywords:
キーワード：
Perform WORD downgrading.
WORDのダウングレードを実行します。
For all other header fields that contain non-ASCII characters, are user-defined, and are missing from this document or future defined header fields, perform ENCAPSULATION downgrading.
非ASCII文字が含まれている他のすべてのヘッダーフィールドについては、ユーザ定義されており、この文書または将来定義されたヘッダフィールドから欠落している、カプセル化ダウングレードを行います。
If the software understands the header field's structure and a downgrading algorithm other than ENCAPSULATION is applicable, that software SHOULD use that algorithm; ENCAPSULATION downgrading is used as a last resort.
ソフトウェアは、ヘッダフィールドの構造を理解し、カプセル以外の格下げアルゴリズムが適用可能である場合、そのソフトウェアは、そのアルゴリズムを使用する必要があります。カプセル化格下げは、最後の手段として使用されています。
Mailing list header fields (those that start in "List-") are part of this category.
リストヘッダフィールドをメーリングリスト（「リスト - 」で始まるもの）は、このカテゴリの一部です。
MIME body-part header fields may contain non-ASCII characters [RFC5335]. This section defines the conversion method to ASCII-only header fields for each MIME header field that contains non-ASCII characters. Parse the message body's MIME structure at all levels and check each MIME header field to see whether it contains non-ASCII characters. If the header field contains non-ASCII characters in the header field value, the header field is a target of the MIME body-part header field's downgrading. Each MIME header field's downgrading method is described below. COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED downgrading are described in Section 5.
MIMEボディパートヘッダフィールドは、非ASCII文字[RFC5335]を含んでいてもよいです。このセクションでは、非ASCII文字が含まれている各MIMEヘッダフィールドのためのASCIIのみのヘッダフィールドに変換する方法を定義します。すべてのレベルでメッセージ本体のMIME構造を解析し、それが非ASCII文字が含まれているかどうかを確認するために、各MIMEヘッダフィールドを確認してください。ヘッダーフィールドがヘッダーフィールド値に非ASCII文字が含まれている場合は、ヘッダフィールドはMIMEボディパートヘッダフィールドの格下げの対象です。各MIMEヘッダフィールドのダウングレード方法について説明します。 COMMENTの格下げ、MIME値格下げ、非構造化格下げはセクション5に記載されています。
Content-ID: The "Content-ID:" header field does not contain non-ASCII characters except in comments. If the header field contains UTF-8 characters in comments, perform COMMENT downgrading.
コンテンツID：「コンテンツID：」ヘッダフィールドはコメント以外で非ASCII文字が含まれていません。ヘッダフィールドはコメントでUTF-8文字が含まれている場合、COMMENTのダウングレードを行います。
Content-Type:
コンテンツタイプ：
Content-Disposition: Perform MIME-VALUE downgrading and COMMENT downgrading.
コンテンツディスポジション：MIME-VALUEの格下げとCOMMENTのダウングレードを実行します。
Content-Description: Perform UNSTRUCTURED downgrading.
コンテンツの説明：構造化されていないダウングレードを実行します。
A downgraded message's header fields contain ASCII characters only. But they still contain MIME-encapsulated header fields that contain non-ASCII UTF-8 characters. Furthermore, the body part may contain UTF-8 characters. Implementations parsing Internet messages need to accept UTF-8 body parts and UTF-8 header fields that are MIME-encoded. Thus, this document inherits the security considerations of MIME-encoded header fields ([RFC2047] and [RFC3629]).
格下げメッセージのヘッダフィールドは、ASCII文字のみが含まれています。しかし、彼らはまだ非ASCII UTF-8文字を含むMIMEカプセル化ヘッダフィールドを含みます。さらに、ボディ部は、UTF-8文字が含まれていてもよいです。インターネットメッセージを解析実装は、UTF-8の本体部とMIMEエンコードされているUTF-8ヘッダーフィールドを受け入れる必要があります。したがって、この文書は、MIMEエンコードされたヘッダフィールド（[RFC2047]及び[RFC3629]）のセキュリティ問題を継承します。
Rewriting header fields increases the opportunities for undetected spoofing by malicious senders. However, rewritten header fields are preserved into Downgraded-* header fields, and parsing Downgraded-* header fields enables the detection of spoofing caused by downgrading.
ヘッダフィールドを書き換えることは、悪意のある送信者が未検出スプーフィングの機会を増加させます。しかし、書き換えられたヘッダフィールドはDowngraded- *ヘッダフィールドに保存され、そして*ヘッダフィールドをDowngraded-解析するダウングレードによって引き起こさなりすましの検出を可能にしています。
Addresses that do not appear in the message header fields may appear in the RCPT commands to an SMTP server for a number of reasons. Copying information from the envelope into the header fields risks inadvertent information disclosure (see [RFC5321] and Section 4 of this document). Mitigating inadvertent information disclosure is also discussed in these locations.
メッセージヘッダーフィールドに表示されていないアドレスは、多くの理由からSMTPサーバにRCPTコマンドで表示されてもよいです。ヘッダフィールドに封筒から情報をコピーする（[RFC5321]とこのドキュメントのセクション4を参照）不注意による情報開示のリスク。不注意による情報開示を緩和することは、これらの場所で議論されています。
The techniques described here invalidate methods that depend on digital signatures over the envelope or any part of the message, which includes the top-level header fields and body-part header fields. Depending on the specific message being downgraded, the following techniques are likely to break: DomainKeys Identified Mail (DKIM), and possibly S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations are to stick to 7-bit transport when using these techniques (as most/all of them presently require) or to make sure to have UTF8SMTP end-to-end when needed.
ここで説明される技術は、エンベロープまたはトップレベルのヘッダフィールドとボディパートヘッダフィールドを含むメッセージの任意の部分の上にデジタル署名に依存するメソッドを無効。格下げされている特定のメッセージに応じて、以下の技術が壊れる可能性がある：のDomainKeysはメール（DKIM）を同定し、そしておそらくS / MIMEおよびプリティグッドプライバシー（PGP）。 2つの明白な緩和策は、これらの技術を使用している場合（それらのほとんど/すべては、現在必要とされる）7ビットの輸送に固執したり、必要なときにUTF8SMTPのエンド・ツー・エンドを持っていることを確認します。
Many gateways and servers on the Internet will discard header fields with which they are not familiar. To the extent to which the downgrade procedures depend on new header fields (e.g.,
インターネット上の多くのゲートウェイおよびサーバは、彼らが慣れていないされてヘッダフィールドを破棄します。ダウングレード手順は、新たなヘッダフィールド（例えば、依存する程度に
"Downgraded-") to avoid information loss, the risk of having those header fields dropped and subsequent implications must be identified. In particular, if the "Downgraded-" header fields are dropped, there is no possibility of reconstructing the original information at any point (before, during, or after delivery). Such gateways violate [RFC2979] and can be upgraded to correct the problem.
「Downgraded-」）は情報の損失を回避するために、それらのヘッダフィールドを有する危険性が低下し、その後の影響が特定されなければなりません。 「Downgraded-」ヘッダフィールドがドロップされる場合は特に、いずれかの時点で元の情報を復元する可能性がない（前、中、または送達後）。このようなゲートウェイは、[RFC2979]を違反し、問題を修正するためにアップグレードすることができます。
Even though the information is not lost, the original message cannot be perfectly reconstructed because some downgrading methods remove information (see Sections 5.1.1 and 5.1.5). Hence, downgrading is a one-way process.
情報が失われていないにもかかわらず、いくつかの格下げ方法は情報を削除（セクション5.1.1と5.1.5を参照）ので、元のメッセージが完全に再構築することはできません。したがって、ダウングレードは、一方向のプロセスです。
While information in any email header field should usually be treated with some suspicion, current email systems commonly employ various mechanisms and protocols to make the information more trustworthy. Currently, information in the new Downgraded-* header fields is usually not inspected by these mechanisms, and may be even less trustworthy than the traditional header fields. Note that the Downgraded-* header fields could have been inserted with malicious intent (and with content unrelated to the traditional header fields).
任意のメールヘッダフィールド内の情報は、通常、いくつかの疑いで治療すべきであるが、現在の電子メールシステムは、一般に、情報をより信頼できるものにするために種々の機構及びプロトコルを採用しています。現在、新しいDowngraded- *ヘッダフィールド内の情報は、通常、これらのメカニズムによって検査されていない、とさえあまり信頼できる伝統的なヘッダフィールドよりかもしれません。 Downgraded- *ヘッダフィールドは悪意で挿入されていることに留意されたい（および従来のヘッダーフィールドとは無関係なコンテンツを含みます）。
If an internationalized MUA would simply try to "upgrade" the message for display purposes (that is, display the information in the Downgraded-* header fields instead of the traditional header fields), the effectiveness of the deployed mechanisms and protocols is likely to be reduced, and the user may be exposed to additional risks. More guidance on how to display downgraded messages is given in [DISPLAY].
国際MUAは、単に表示目的のためにメッセージを「アップグレード」しようとする場合（つまり、代わりに伝統的なヘッダフィールドのDowngraded- *ヘッダフィールド内の情報を表示する）、展開メカニズムとプロトコルの有効性があると思われます減少、およびユーザーは、追加のリスクにさらされてもよいです。格下げメッセージを表示する方法についての詳しい案内は[DISPLAY]で与えられています。
Concerns about the trustworthiness of the Downgraded-* header fields are not limited to displaying and replying in MUAs, and should be carefully considered before using such header fields for other purposes as well.
Downgraded- *ヘッダフィールドの信頼性に関する懸念は表示とのMUAで返信に限定されるものではなく、かつ慎重に、同様に他の目的のために、このようなヘッダフィールドを使用する前に考慮すべきです。
See the "Security Considerations" section in [RFC4952] for more discussion.
より多くの議論のための[RFC4952]で「セキュリティの考慮事項」を参照してください。
While [RFC2047] has a specific algorithm to deal with whitespace in adjacent encoded words, there are a number of deployed implementations that fail to implement the algorithm correctly. As a result, whitespace behavior is somewhat unpredictable in practice when multiple encoded words are used. While RFC 5322 states that implementations SHOULD limit lines to not more than 78 characters, implementations MAY choose to allow overly long encoded words in order to work around faulty [RFC2047] implementations. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters.
[RFC2047]は、隣接する符号化された言葉で空白に対処するための特定のアルゴリズムを有しているが、正確なアルゴリズムを実装することができない展開の実装が多数存在します。複数のエンコードされた単語が使用される場合、結果として、空白の挙動は、実際には幾分予測不可能です。 RFC 5322は、実装は以上78文字の行を制限すべきと述べているが、実装は約故障[RFC2047]の実装を動作させるために過度に長い符号化された単語を可能にするために選ぶかもしれ。そうすることを選択した実装は、78個の文字に行の長さを制限するためのオプションの仕組みを持っているべきです。
Downgrading is an alternative to avoid the rejection of messages that require UTF8SMTP support by a server that does not provide such support. Implementing the full specification of this document is desirable, but a partial implementation is also possible.
ダウングレードは、このようなサポートを提供していませんサーバーによってUTF8SMTPサポートを必要とするメッセージの拒絶反応を回避するための代替手段です。この文書の完全な仕様を実装することが望ましいが、部分的な実装も可能です。
If a partial downgrading implementation confronts an unsupported downgrading target, the implementation MUST NOT send the message to a server that does not support UTF8SMTP. Instead, it MUST either reject the message or generate a notification of non-deliverability.
部分的格下げの実装がサポートされていない格下げの対象に直面した場合、実装はUTF8SMTPをサポートしていないサーバーにメッセージを送ってはいけません。代わりに、メッセージを拒否または非デリバリーの通知を生成する必要があります。
A partial downgrading, trivial downgrading, is discussed. It does not support non-ASCII addresses in SMTP envelope and address header fields, unknown header field downgrading, or the MIME body-part header field downgrading. It supports:
部分的格下げ、些細な格下げは、議論されています。これは、SMTPエンベロープとアドレスヘッダフィールド、未知のヘッダフィールド格下げ、またはMIMEボディパートヘッダフィールドの格下げに非ASCIIアドレスをサポートしていません。それはサポートしています。
o some simple header field downgrading: Subject o comments and display name downgrading: From, To, Cc o trace header field downgrading: Received
、からのCC Oトレースヘッダフィールドの格下げ、へ：受け取ったコメントと表示名の格下げO件名：Oいくつかの簡単なヘッダフィールド格下げ
Otherwise, the downgrading fails.
それ以外の場合は、ダウングレードは失敗します。
Trivial downgrading targets mail messages that are generated by UTF8SMTP-aware MUAs and contain non-ASCII characters in comments, display names, and unstructured parts without using non-ASCII email addresses. These mail messages usually do not contain non-ASCII email addresses in the SMTP envelope and its header fields. But it is not deliverable via a UTF8SMTP-unaware SMTP server. Implementing full specification downgrading may be hard, but trivial downgrading saves mail messages without using non-ASCII addresses.
些細な格下げはUTF8SMTP認識のMUAによって生成され、非ASCIIの電子メールアドレスを使用せずに、コメント、表示名、および非構造化部分に非ASCII文字が含まれているメールメッセージをターゲットにしています。これらのメールメッセージは通常、SMTPエンベロープ内の非ASCIIの電子メールアドレスとそのヘッダフィールドを含んでいません。しかし、それはUTF8SMTP非対応SMTPサーバを経由して配信可能ではありません。フルスペックダウングレードを実装することは難しいことが、些細な格下げは、非ASCIIアドレスを使用せずに電子メールメッセージを保存します。
The SMTP client may encounter a SMTP server that does not support the 8BITMIME SMTP extension [RFC1652]. The server does not support "8bit" or "binary" data. Implementers need to consider converting "8bit" data to "base64" or "quoted-printable" encoded form and adjust the "Content-Transfer-Encoding" header field accordingly. If the body contains multiple MIME parts, this conversion MUST be performed for each MIME part.
SMTPクライアントは、8BITMIME SMTP拡張[RFC1652]をサポートしていないSMTPサーバーが発生する可能性があります。サーバーは、「8ビット」または「バイナリ」のデータをサポートしていません。実装は「BASE64」または「引用符で囲まれた印刷可能」符号化されたフォームに「8ビット」のデータを変換検討し、それに応じて、「Content-Transfer-Encoding」ヘッダフィールドを調整する必要があります。本体は、複数のMIME部分が含まれている場合、この変換は、各MIME部分に対して実行されなければなりません。
IANA has registered the following header fields in the Permanent Message Header Field registry, in accordance with the procedures set out in [RFC3864].
IANAは、[RFC3864]に記載された手順に従って、永久メッセージヘッダーフィールドレジストリ内の次のヘッダフィールドが登録されています。
Header field name: Downgraded-Mail-From Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレードメール-から適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Rcpt-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-RCPT-TO適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-From Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-から適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Sender Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-送信者適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-に適用されるプロトコル：メールステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Cc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-CC適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Bcc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-のBcc適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Reply-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-返信先に適用されるプロトコル：メールステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-From Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-のResent-から適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-Sender Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-憤慨し、送信者適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-憤慨し-に適用されるプロトコル：メールステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-Cc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-憤慨し-CC適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-Bcc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-憤慨し-BCC適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Resent-Reply-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：該当プロトコルに格下げ-のResent-返信：メールのステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Return-Path Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-リターンパス適用可能プロトコル：Mailステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Header field name: Downgraded-Disposition-Notification-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダフィールド名：ダウングレード-処分 - 通知 - に適用されるプロトコル：メールステータス：実験著者/変更コントローラ：IETF仕様書（S）：この文書（第3節）
Furthermore, IANA is requested to refuse registration of all field names that start with "Downgraded-". For unknown header fields, use the downgrading method described in Section 3.3 to avoid conflicts with existing IETF activity (Email Address Internationalization).
さらに、IANAは「Downgraded-」で始まるすべてのフィールド名の登録を拒否するように要求されます。未知のヘッダフィールドに、既存のIETF活動（メールアドレスの国際化）との競合を避けるために、3.3節に記載格下げメソッドを使用。
Significant comments and suggestions were received from John Klensin, Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. Moonesamy, and JET members.
重要なコメントや提案はジョン・クレンシン、ハラルドAlvestrand、クリス・ニューマン、ランドールGellens、チャールズリンジー、マルコス・サンス、アレクセイ・メルニコフ、フランクEllermann、エドワード・ルイス、S. Moonesamy、およびJETのメンバーから受け取りました。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[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月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.
[RFC4021] Klyne、G.とJ.パルメ、RFC 4021、2005年3月の "メールおよびMIMEヘッダフィールドの登録"。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[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月。
[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月。
[DISPLAY] Fujiwara, K., "Displaying Downgraded Messages for Email Address Internationalization", Work in Progress, March 2009.
[DISPLAY]藤原、K.、「メールアドレスの国際化のためにダウングレードメッセージの表示」、進歩、2009年3月に作業。
[DSNBIS] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", Work in Progress, December 2008.
[DSNBIS]ニューマン、C.とA.メルニコフ、「国際配送状況や処分通知」、進歩、2008年12月に作業。
Appendix A. Examples
付録A.例
A.1. Downgrading Example 1
A.1。例1のダウングレード
This appendix shows an SMTP downgrading example. Consider a mail message where:
この付録では、SMTPダウングレードの例を示します。どこメールメッセージを考えてみます。
o The sender address is "NON-ASCII-local@example.com", which is a non-ASCII address. Its ASCII alternative is "ASCII-local@example.com" and its display-name is "DISPLAY-local".
O送信者アドレスは、非ASCIIのアドレスである、「NON-ASCII-local@example.com」です。そのASCIIの選択肢は「ASCII-local@example.com」であり、その表示名は「DISPLAYローカル」です。
o The "To:" address is "NON-ASCII-remote1@example.net", which is a non-ASCII address. Its ASCII alternative is "ASCII-remote1@example.net" and its display-name is "DISPLAY-remote1".
O「にするには：」アドレスは、ASCII以外のアドレスである「NON-ASCII-remote1@example.net」、です。そのASCIIの選択肢は "ASCII-remote1@example.net" であり、その表示名は "DISPLAY-REMOTE1" です。
o The "Cc:" address is a non-ASCII address, "NON-ASCII-remote2@example.org", without an alternative ASCII address. Its display-name is "DISPLAY-remote2".
「CC：」Oアドレスが非ASCIIアドレスで、「NON-ASCII-remote2@example.org」、代替ASCIIアドレスを持ちません。その表示名は "DISPLAY-REMOTE2" です。
o Three display names contain non-ASCII characters.
O 3人の表示名には非ASCII文字が含まれています。
o The Subject header field is "NON-ASCII-SUBJECT", which contains non-ASCII characters.
O件名ヘッダフィールドは、非ASCII文字を含む「非ASCII被験者」、です。
o Assume the "To:" recipient's MTA (example.net) does not support UTF8SMTP.
受信者のMTA（example.net）UTF8SMTPをサポートしていません：o「のためには」とします。
o Assume the "Cc:" recipient's MTA (example.org) supports UTF8SMTP.
O想定 "CC：" 受信者のMTAは、（example.org）UTF8SMTPをサポートしています。
The first example SMTP envelope/message is shown in Figure 1. In this example, the "To:" recipient's session is the focus.
最初の例SMTPエンベロープ/メッセージは、この例では図1に示され、「TO：」受信者のセッションが焦点です。
MAIL FROM: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <NON-ASCII-remote1@example.net>
ALT-ADDRESS=ASCII-remote1@example.net
RCPT TO: <NON-ASCII-remote2@example.org>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
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>
Date: DATE
MAIL_BODY
MAIL_BODY
Figure 1: Original envelope/message (example 1)
図1：元のエンベロープ/メッセージ（実施例1）
In this example, there are two SMTP recipients; one is "To:", the other is "Cc:". The SMTP downgrading uses To: session downgrading. Figure 2 shows an SMTP downgraded example.
この例では、2人のSMTP受信者が存在します。 、他は「CC：」である：1は「へ」です。セッション格下げ：SMTPの格下げは、にを使用しています。図2は、SMTPは、例を格下げ示します。
MAIL FROM: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@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>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
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>
Date: DATE
MAIL_BODY
MAIL_BODY
Figure 2: SMTP downgraded envelope/message (example 1)
図2：SMTP格下げエンベロープ/メッセージ（実施例1）
After SMTP downgrading, header field downgrading is performed. The final downgraded message is shown in Figure 3. A Return-Path header field will be added by the final destination MTA.
SMTPダウングレード後、ヘッダーフィールド格下げが行われます。最終的なダウングレードメッセージ図3. Aリターンパスヘッダフィールドに示されているが、最終的な宛先MTAによって追加されるであろう。
Return-Path: <ASCII-local@example.com> Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= =?UTF-8?Q?<ASCII-local@example.com>>?= Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?= =?UTF-8?Q?<ASCII-remote1@example.net>>?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 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>?= Date: DATE
リターンパスを<ASCII-local@example.com>ダウングレードメール-から：？？？？？？？= 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？？？？。 ？>>ネット=メッセージ-ID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：= UTF-8 Q NON-ASCII-SUBJECT =から：？？？？= UTF-8 Q DISPLAY-ローカル= <ASCII-ローカル？？？？ @ example.com>ダウングレード-から：？？？？？？？= UTF-8 Q DISPLAY-、LOCAL_LISTENER <NON-ASCII-local@example.com _ = = UTF-8 Q <ASCII-local@example.com >> ？=へ：？？？= UTF-8 Q DISPLAY-REMOTE1 = <ASCII-remote1@example.net>ダウングレード-TO：？？？？？？？= 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> =日付：？DATE
MAIL_BODY
MAIL_BODY
Figure 3: Downgraded message (example 1)
図3：ダウングレードメッセージ（実施例1）
A.2. Downgrading Example 2
A.2。例2のダウングレード
In many cases, the sender wants to use a non-ASCII address and the recipient is a traditional mail user. The SMTP server handing mail for the recipient and/or the recipient's MUA does not support UTF8SMTP extension. Consider a mail message where:
多くの場合、送信者は、非ASCIIアドレスを使用したいと受信者は、伝統的なメール・ユーザーです。受信者および/または受信者のMUAのためのSMTPサーバの取り扱いメールはUTF8SMTP拡張をサポートしていません。どこメールメッセージを考えてみます。
o The sender address is "NON-ASCII-local@example.com", which is a non-ASCII address. Its ASCII alternative is "ASCII-local@example.com". It has a display-name "DISPLAY-local", which contains non-ASCII characters.
O送信者アドレスは、非ASCIIのアドレスである、「NON-ASCII-local@example.com」です。そのASCIIの選択肢は「ASCII-local@example.com」です。なお、表示名「DISPLAY-ローカル」、非ASCII文字が含まれています。
o The "To:" address is "ASCII-remote1@example.net", which is ASCII-only. It has a display-name, "DISPLAY-remote1", which contains non-ASCII characters.
O「へ：」アドレスはASCIIのみである「ASCII-remote1@example.net」、です。これは、非ASCII文字が含まれている表示名、 "DISPLAY-REMOTE1" を、持っています。
o The "Subject:" header field is "NON-ASCII-SUBJECT", which contains non-ASCII characters.
"件名：" Oヘッダフィールドは、非ASCII文字が含まれている "NON-ASCII-SUBJECT"、です。
The second example envelope/message is shown in Figure 4.
第2の実施のエンベロープ/メッセージは、図4に示されています。
MAIL From: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <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
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL_BODY
MAIL_BODY
Figure 4: Original message (example 2)
図4：元のメッセージ（例2）
In this example, SMTP session is downgradable. Figure 5 shows an SMTP downgraded envelope/message.
この例では、SMTPセッションがダウングレードです。図5は、SMTP格下げエンベロープ/メッセージを示します。
MAIL From: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
?=UTF8?Q?<ASCII-local@example.com>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL_BODY
MAIL_BODY
Figure 5: SMTP downgraded envelope/message (example 2)
図5：SMTP格下げエンベロープ/メッセージ（実施例2）
After SMTP downgrading, header field downgrading is performed. The downgraded example is shown in Figure 6.
SMTPダウングレード後、ヘッダーフィールド格下げが行われます。ダウングレード例が図6に示されています。
Return-Path: <ASCII-local@example.com> Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?= =?UTF8?Q?<ASCII-local@example.com>>?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?= =?UTF-8?Q?<ASCII-local@example.com>>?= From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com> To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net> Date: DATE
リターンパスを<ASCII-local@example.com>ダウングレードメール-から：？？？？？？？= UTF8 Q <NON-ASCII-local@example.com _ = = UTF8 Q <ASCII-ローカル@ ？example.com >> =メッセージ-ID：MESSAGE_IDマイム・バージョン：1.0のContent-Type：text / plainの。文字セット= "UTF-8" コンテンツ転送エンコード：8ビット件名：= UTF-8 Q NON-ASCII-SUBJECT =ダウングレード-から：？？？？？？？= UTF-8 Q DISPLAY-、LOCAL_LISTENER <NON-ASCII ？-local@example.com_?= = UTF-8 Q <ASCII-local@example.com >> =から：？？？？？？= UTF-8 Q DISPLAY-ローカル= <ASCII-ローカル@例？。 COM>へ：？？？= UTF-8 Q DISPLAY-REMOTE1 = <ASCII-remote1@example.net>日付：？DATE
MAIL_BODY
MAIL_BODY
Figure 6: Downgraded message (example 2)
図6：ダウングレードメッセージ（実施例2）
Authors' Addresses
著者のアドレス
Kazunori Fujiwara (editor) 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
Yoshiro Yoneya (editor) 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: yone@jprs.co.jp
電話：+81 3 5215 8451 Eメール：yone@jprs.co.jp