[要約] RFC 5504は、電子メールアドレスの国際化のダウングレードメカニズムに関するものであり、国際化されたメールアドレスを非国際化する方法を提供しています。このRFCの目的は、国際化されたメールアドレスをサポートするシステムと非国際化されたシステム間の互換性を確保することです。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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文字のみを処理します。メールアドレスInternationalization（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ヘッダーフィールドで使用できます。ここで指定されているダウングレードメカニズムは、メールヘッダーフィールドとMIMEヘッダーフィールドをASCIIに変換します。
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].
このドキュメントは、新しいヘッダーフィールドを定義することを除いて、プロトコルを変更しません。[RFC4952]、[RFC5335]、および[RFC5336]で定義されている国際化された電子メールエンベロープ/メッセージから[RFC5321]および[RFC5322]で定義された従来の電子メールエンベロープ/メッセージへの変換方法について説明します。
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クライアントはUTF8SMTPエンベロープまたは国際化されたメッセージをSMTPサーバーに送信してはなりません。このセクションには、この場合の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.
格下げは、SMTPクライアントとして機能するメールユーザーエージェント（MUAS）、メール提出エージェント（MSA）、およびメール輸送エージェント（MTA）に実装できます。また、メッセージストアを含む非UTF8SMTP準拠システムにUTF8SMTPエンベロープまたは国際化されたメッセージを保存または提供するメッセージ配信エージェント（MDA）、郵便局プロトコル（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 SMTPダウングレードoメールヘッダーフィールドのダウングレードo MIMEヘッダーフィールドダウングレード
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では、「ダウングレード」から始まる多くのヘッダーフィールドが導入されています。元のエンベロープ情報と元のヘッダーフィールドを保存します。
SMTP downgrading is described in Section 4. It generates ASCII-only envelope information from a UTF8SMTP envelope.
SMTPのダウングレードはセクション4で説明されています。UTF8SMTPエンベロープからASCII-ONLYエンベロープ情報を生成します。
Email header field downgrading is described in Section 5. It generates ASCII-only header fields.
電子メールヘッダーフィールドの格下げについては、セクション5で説明します。これは、Ascii-Only Headerフィールドを生成します。
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ヘッダーフィールドの格下げについては、セクション6で説明しています。これは、Ascii-Only Mimeヘッダーフィールドを生成します。
Displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields is described in an another document ([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].
この仕様で使用されるすべての専門用語は、メールアドレス国際化（EAI）概要[RFC4952]、メール仕様[RFC5321] [RFC5322]、またはMIME文書[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.
「ダウングレード」から始まる新しいヘッダーフィールドは、UTF-8文字を含むオリジナルのエンベロープとメールのヘッダーフィールド値を保持するためにここで定義されています。ダウングレード中に、UTF8SMTPをサポートしていないサーバーに渡すことができない、元のエンベロープまたはメールヘッダーフィールドごとに1つの新しい「ダウングレード」ヘッダーフィールドが追加されます。元のエンベロープまたはメールヘッダーフィールドが削除または書き換えられます。ASCII以外の文字を含むエンベロープとメールのヘッダーフィールドのみが影響を受けます。このプロセスの結果は、既存の電子メール仕様[RFC5321]および[RFC5322]に準拠したメッセージです。元の国際化された情報は、追加された「ダウングレード」ヘッダーフィールドを調べることで取得できます。
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 Envelope Downgraded Information <Downgraded-Envelope-Addr>は、元の非ASCIIアドレスと格下げされた全ASCIIアドレスで構成されています。ABNF [RFC5234]構文は次のとおりです。
downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
FWS "<" Mailbox ">" ">" [CFWS]
<uMailbox> is defined in [RFC5336]; <Mailbox> and <A-d-l> are defined in Section 4.1.2 of [RFC5321].
<umailbox>は[rfc5336]で定義されています。<mailbox>および<a-dl>は、[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:
2つのヘッダーフィールド「ダウングレード型メールからの格下げ」と「ダウングレードされたRCPT-to：」は、SMTPエンベロープダウングレードされた情報を保持するために定義されています。ヘッダーフィールドの構文は、次のように指定されています。
fields =/ downgradedmailfrom / downgradedrcptto
downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF
downgradedMailfrom = "ダウングレードされたメールから："非構造化CRLF
downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF
downgradedRcptto = "downgraded-rcpt-to："非構造化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]は必要に応じてエンコード（およびcharset 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
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 preserve a header field in a "Downgraded-" header field:
ヘッダーフィールドを「格下げ」ヘッダーフィールドに保存するには：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1. 元のヘッダーフィールド値である値を持つ新しい「格下げ」ヘッダーフィールドを生成します。
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. 生成されたヘッダーフィールドコンテンツをまるで構造化されていないかのように扱い、必要に応じてcharset utf-8でエンコードして、結果がASCIIになるように扱います。
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文字を含む元のヘッダーフィールドをカプセル化するために定義されており、この仕様ではそうでない場合は規定されていません。カプセル化ヘッダーのフィールド名は、「ダウングレード」と元の名前の連結です。値フィールドは、元のヘッダーフィールド値を保持します。
The header field syntax is specified as follows:
ヘッダーフィールドの構文は、次のように指定されています。
fields =/ unknown-downgraded-headers ":" unstructured CRLF
unknown-downgraded-headers = "Downgraded-" original-header-field-name
不明な等級付けされたヘッド= "downgraded-" Original-header-field-name
original-header-field-name = field-name
field-name = 1*ftext
ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and ":".
To encapsulate a header field in a "Downgraded-" header field:
「ダウングレードされた」ヘッダーフィールドでヘッダーフィールドをカプセル化するには：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1. 元のヘッダーフィールド値である値を持つ新しい「格下げ」ヘッダーフィールドを生成します。
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. 生成されたヘッダーフィールドコンテンツを非構造化されているかのように扱い、必要に応じてcharset utf-8でエンコードする[RFC2047]を適用して、結果はASCIIになります。
3. Remove the original header field.
3. 元のヘッダーフィールドを削除します。
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 <Reverse-Path>コマンドo <forward-path> of rcptのコマンドo <forward-path> o orcptパラメーターのrcptパラメーターをコマンドにする
<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.
コマンドへのメールとRCPTの<Path>を格下げすると、[RFC5336]で定義されているAlt-Addressパラメーターを使用します。<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文字を含むメッセージヘッダーフィールドとメッセージボディマイムヘッダーフィールドを格下げする必要があることに注意してください。これについては、セクション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].
セクション3で定義されている「ダウングレードされたRCPT-to」ヘッダーフィールドは、XTEXT [RFC3461]としてエンコードされるため、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.
受信者アドレスの開示を避けるために、ダウングレードプロセスは、SMTPのダウングレードが複数の受信者をターゲットにする場合、「ダウングレードRCPT-TO：」ヘッダーフィールドを追加してはなりません。詳細については、セクション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].
「RCPT to」コマンドは、配信ステータス通知（DSN）拡張[RFC3461]がサポートされている場合、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要素<MailBox>、<Word>、<Comment>、<Untructured>を説明しています。[RFC2045]は、ABNF要素<value>を説明しています。
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.
ヘッダーのフィールド名が「受信」と「」と句にはASSASCII以外のアドレスが含まれている場合、ヘッダーフィールドから句を削除します。他の部分（<comment> sをカウントしない）は、ASSASCII以外の値を含めるべきではありません。
If the header field has an <unstructured> field that contains non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダーフィールドに非ASCII文字を含む<非構造化>フィールドがある場合、charset utf-8でエンコードする[RFC2047]を適用します。
If the header field has any <word> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダーフィールドに非ASCII文字を含む<Word>フィールドがある場合、CharSet UTF-8でエンコードする[RFC2047]を適用します。
If the header field has any <comment> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
ヘッダーフィールドに、非ASCII文字を含む<comment>フィールドがある場合は、charset 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.
ヘッダーフィールドに[RFC2045]によって定義された<value>要素があり、要素が非ASCII文字を含む場合、[RFC2231]に従って<値>要素をcharset utf-8にエンコードし、言語情報を空にします。<value>要素が<quoted-string>であり、dquoteの外側に<cfws>が含まれている場合は、この変換の前に<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.
ヘッダーフィールドに<アドレス>（<mailbox>または<group>）要素があり、非ASCII文字を含む<display-name>要素がある場合、[RFC2047]に従って<display-name>要素をCharsetでエンコードします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.
<mailbox>要素には、非ASCIIアドレスと同等の形式はありません。ヘッダーフィールドに非ASCII文字を含む<mailbox>要素がある場合、セクション3.2で定義されている対応する「ダウングレード」ヘッダーフィールドにヘッダーフィールドを保存し、各<メールボックス>要素をAscii-only形式に書き換えます。ASSASCII以外の文字を含む<mailbox>要素は、3つの形式の1つです。
o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
Rewrite it as: [ Display-name ] "<" Addr-spec ">"
それを書き換えます：[display-name] "<" addr-spec ">"
o [ Display-name ] "<" Utf8-addr-spec ">" o Utf8-addr-spec
o [display-name] "<" utf8-addr-spec ">" o utf8-addr-spec
Rewrite both as: [ Display-name ] "Internationalized Address " Encoded-word " Removed:;" where the <Encoded-word> is the original <Utf8-addr-spec> encoded according to [RFC2047].
両方を書き換えます：[display-name]「国際化アドレス」エンコードワード「削除：;」ここで、<エンコードワード>は[RFC2047]に従ってエンコードされた元の<UTF8-ADDR-SPEC>です。
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で最後の手段として説明されているように、「格下げされた」ヘッダーフィールドにカプセル化します。
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-TYPE-ADDR>が含まれており、<UTF-8-Type-ADDR>に生の非ASCII文字が含まれている場合、UTF-8-ADDRESSフォームにあります。セクション4.2で説明されているように、UTF-8-ADDR-XTEXTフォームに変換します。この場合、コメントの格下げも実行されます。アドレスタイプが認識されていない場合、ヘッダーフィールドに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: Reply-To: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Bcc: Resent-Reply-To: Return-Path: Disposition-Notification-To:
FROM：送信者：TO：CC：BCC：REPLY-TO：RESENT-FROM：RESENT-SENDER：RESENT-TO：RESENT-BCC：RESENT-REPLY-TO：RETURN-PATH：REATION-NOTIFICIATION：
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以外のアドレスを含む<メールボックス>要素が含まれている場合、変換前にヘッダーフィールドを「格下げされた」ヘッダーフィールドに保存します。次に、コメントの格下げ、ディスプレイ名のダウングレード、メールボックスの格下げを実行します。
Original-Recipient: Final-Recipient:
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:
日付：Message-ID：Resent-Message-ID：In-Reply-to：References：Resent-Date：Resent-Message-ID：Mime-version：content-id：content-transfer-encoding：content-language：Accept-言語：Auto-Submitted：
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文字が含まれている場合は、コメントの格下げを実行します。
Received:
受け取った：
Perform COMMENT downgrading and RECEIVED downgrading.
コメントの格下げを実行し、格下げを受信します。
Content-Type: Content-Disposition:
コンテンツタイプ：コンテンツディスポジション：
Perform MIME-VALUE downgrading and COMMENT downgrading.
Mime-Valueの格下げを実行し、コメントの格下げします。
Subject: Comments: Content-Description:
件名：コメント：コンテンツデスクリプリ：
Perform UNSTRUCTURED downgrading.
構造化されていない格下げを実行します。
Keywords:
キーワード：
Perform WORD downgrading.
単語の格下げを実行します。
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 ONLYヘッダーフィールドへの変換方法を定義します。すべてのレベルでメッセージ本体のmime構造を解析し、各mimeヘッダーフィールドをチェックして、ASCII以外の文字が含まれているかどうかを確認します。ヘッダーフィールドにヘッダーフィールド値に非ASCII文字が含まれている場合、ヘッダーフィールドはMIMEボディパートヘッダーフィールドの格下げのターゲットです。各MIMEヘッダーフィールドのダウングレード方法については、以下に説明します。コメントの格下げ、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.
Content-ID：「Content-ID：」ヘッダーフィールドには、コメントを除いて非ASCII文字が含まれていません。ヘッダーフィールドにコメントにUTF-8文字が含まれている場合は、コメントの格下げを実行します。
Content-Type:
コンテンツタイプ：
Content-Disposition: Perform MIME-VALUE downgrading and COMMENT downgrading.
コンテンツ拡張：MIME値の格下げを実行し、コメントの格下げします。
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文字のみが含まれています。しかし、それらには、非ASSASCII UTF-8文字を含むMime-Apsuclusted Headerフィールドが含まれています。さらに、身体部分にはUTF-8文字が含まれている場合があります。インターネットメッセージの解析の実装は、MIMEエンコードされたUTF-8ボディパーツと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.
ヘッダーフィールドの書き換えは、悪意のある送信者による検出されないスプーフィングの機会を増やします。ただし、書き換えられたヘッダーフィールドはダウングレードされた*ヘッダーフィールドに保存され、格下げされた*ヘッダーフィールドを解析することで、格下げによって引き起こされるスプーフィングの検出が可能になります。
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.
メッセージヘッダーフィールドに表示されないアドレスは、いくつかの理由でRCPTコマンドにSMTPサーバーに表示される場合があります。エンベロープからヘッダーフィールドに情報をコピーすると、不注意な情報開示がリスクされます（[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.
ここで説明する手法は、エンベロープまたはメッセージの一部のデジタル署名に依存するメソッドを無効にします。これには、トップレベルのヘッダーフィールドとボディパートヘッダーフィールドが含まれます。格下げされている特定のメッセージに応じて、次の手法が破損する可能性があります。ドメインキー識別されたメール（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.
「ダウングレード」）情報の損失を回避するには、これらのヘッダーフィールドを落とし、その後の意味を特定する必要があります。特に、「格下げされた」ヘッダーフィールドがドロップされている場合、どの時点でも元の情報を再構築する可能性はありません（配達前、配達前、または配達後）。このようなゲートウェイは[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).
通常、電子メールヘッダーフィールドの情報は疑いで扱う必要がありますが、現在の電子メールシステムは一般に、さまざまなメカニズムとプロトコルを使用して情報をより信頼できるものにします。現在、新しい格下げされた*ヘッダーフィールドの情報は通常、これらのメカニズムによって検査されず、従来のヘッダーフィールドよりも信頼性が低い場合があります。ダウングレードされた - *ヘッダーフィールドは、悪意のある意図（および従来のヘッダーフィールドとは無関係のコンテンツ）で挿入されている可能性があることに注意してください。
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が、ディスプレイ目的のメッセージを単に「アップグレード」しようとする場合（つまり、従来のヘッダーフィールドの代わりにダウングレードされた*ヘッダーフィールドに情報を表示する）、展開されたメカニズムとプロトコルの有効性はおそらく削減され、ユーザーは追加のリスクにさらされる可能性があります。格下げされたメッセージを表示する方法に関する詳細なガイダンスは、[表示]に記載されています。
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.
格下げされた*ヘッダーフィールドの信頼性に関する懸念は、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]には、隣接するエンコードされた単語でWhitespaceを扱う特定のアルゴリズムがありますが、アルゴリズムを正しく実装できない多くの展開された実装があります。その結果、複数のエンコードされた単語が使用されると、実際には白面の動作がやや予測できません。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エンベロープの非ASSASCIIアドレスをサポートしておらず、アドレスヘッダーフィールド、不明なヘッダーフィールドのダウングレード、またはMIMEボディパートヘッダーフィールドの格下げをアドレスしません。それはサポートしています：
o some simple header field downgrading: Subject o comments and display name downgrading: From, To, Cc o trace header field downgrading: Received
o いくつかのシンプルなヘッダーフィールドの格下げ：件名oコメントとディスプレイ名のダウングレード：from、cc 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電子メールアドレスを使用せずにASSASCII文字を含むメールメッセージをメールで送信します。これらのメールメッセージには、通常、SMTPエンベロープとそのヘッダーフィールドにASCII以外のメールアドレスが含まれていません。ただし、UTF8SMTP-UnaWare 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ビット」または「バイナリ」データをサポートしていません。実装者は、「8ビット」データを「base64」または「引用符で囲まれた」エンコードされたフォームに変換し、それに応じて「コンテンツトランスファーエンコード」ヘッダーフィールドを調整することを検討する必要があります。ボディに複数の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)
ヘッダーフィールド名：適用可能なプロトコルからダウングレードされたメール：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Rcpt-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレード型RCPTから適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-From Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：該当するプロトコルからダウングレード：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Sender Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレードされたセンダー適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：dawngraded-to該当するプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Cc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレード-CC適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Reply-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-From Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：適用可能なプロトコルから格下げされたレセント：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Resent-Sender Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：格下げ式センダー適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Resent-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレードされた該当するプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Resent-Cc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレード-Resent-CC適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Resent-Bcc Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレード-Resent-BCC適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Resent-Reply-To Applicable protocol: mail Status: experimental Author/change controller: IETF Specification document(s): This document (Section 3)
ヘッダーフィールド名：ダウングレードレセントレプリーに適用可能なプロトコル：メールステータス：実験著者/変更コントローラー：IETF仕様文書：このドキュメント（セクション3）
Header field name: Downgraded-Return-Path
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Disposition-Notification-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 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は、「格下げ」から始まるすべてのフィールド名の登録を拒否するように要求されています。未知のヘッダーフィールドの場合、セクション3.3で説明したダウングレード方法を使用して、既存のIETFアクティビティとの競合を回避します（電子メールアドレス国際化）。
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.
ジョン・クレンシン、ハラルド・アルベスランド、クリス・ニューマン、ランドール・ゲレンズ、チャールズ・リンジー、マルコス・サンツ、アレクシー・メルニコフ、フランク・エラーマン、エドワード・ルイス、S。ムーネミー、ジェットメンバーから重要なコメントと提案が受け取られました。
[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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、RFC 2231、1997年11月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979] Freed、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] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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. Palme、「郵便およびMIMEヘッダーフィールドの登録」、RFC 4021、2005年3月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y。、「国際化された電子メールヘッダー」、RFC 5335、2008年9月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336] Yao、J。およびW. Mao、「国際化された電子メールアドレスのSMTP拡張」、RFC 5336、2008年9月。
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337] Newman、C。およびA. Melnikov、「国際化された配送状況と処分通知」、RFC 5337、2008年9月。
[DISPLAY] Fujiwara, K., "Displaying Downgraded Messages for Email Address Internationalization", Work in Progress, March 2009.
[ディスプレイ] Fujiwara、K。、「電子メールアドレス国際化のための格下げされたメッセージの表示」、2009年3月、進行中の作業。
[DSNBIS] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", Work in Progress, December 2008.
[DSNBIS] Newman、C。およびA. Melnikov、「国際化された配送状況と気質通知」、2008年12月、進行中の作業。
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 送信者アドレスは「nonascii-local@example.com」であり、これはASSASCII以外のアドレスです。ASCIIの代替品は「ascii-local@example.com」であり、そのディスプレイ名は「ディスプレイローカル」です。
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 「to：」アドレスは「nonascii-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".
o 「CC：」アドレスは、ASCIIの代替アドレスなしで、ASCII以外のアドレス「非ASCII-remote2@example.org」です。そのディスプレイ名は「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.
o 「to：」受信者のMTA（example.net）がUTF8SMTPをサポートしていないと仮定します。
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レシピエントがいます。1つは「to：」、もう1つは「cc：」です。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に示します。リターンパスヘッダーフィールドは、最終的な宛先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
MAIL_BODY
mail_body
Figure 3: Downgraded message (example 1)
図3：ダウングレードされたメッセージ（例1）
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 送信者アドレスは「nonascii-local@example.com」であり、これはASSASCII以外のアドレスです。そのASCIIの代替品は「ascii-local@example.com」です。非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 「to：」アドレスは「ascii-remote1@example.net」です。非ASCII文字を含むディスプレイ名「DisplayRemote1」があります。
o The "Subject:" header field is "NON-ASCII-SUBJECT", which contains non-ASCII characters.
o 「件名：」ヘッダーフィールドは「非ASCIIサブジェクト」であり、非ASCII文字を含む。
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
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
Kazunori Fujiwara（編集者）Japan Registry Services Co.、Ltd。Chiyoda First Bldg。イースト13F、3-8-1西カンダチヨーダクー、東京101-0065日本
Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp
Yoshiro Yoneya (editor) Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
Yoshiro Yoneya（編集者）Japan Registry Services Co.、Ltd。Chiyoda First Bldg。イースト13F、3-8-1西カンダチヨーダクー、東京101-0065日本
Phone: +81 3 5215 8451
EMail: yone@jprs.co.jp