[要約] RFC 6857は、国際化されたメールメッセージの配信後のメッセージのダウングレードに関する規格です。その目的は、メールの受信者が受け取ったメッセージを適切に理解できるようにするため、国際化されたメッセージを非国際化する方法を提供することです。
Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 6857 JPRS
Category: Standards Track March 2013
ISSN: 2070-1721
Post-Delivery Message Downgrading for Internationalized Email Messages
国際化された電子メールメッセージの配信後メッセージのダウングレード
Abstract
概要
The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.
SMTPの電子メールアドレス国際化（SMTPUTF8）拡張機能により、UTF-8でエンコードされたUnicode文字と、メールヘッダーフィールドのASCIIレパートリー外でのUnicode文字が許可されます。アップグレードされたPOPおよびIMAPサーバーは、国際化されたメッセージをサポートします。 POPまたはIMAPクライアントが電子メールアドレスの国際化をサポートしていない場合、POPまたはIMAPサーバーはクライアントに国際化されたメッセージを配信できず、メッセージを削除できません。この状況を回避するために、このドキュメントでは、国際化されたメッセージを従来のメッセージ形式に変換するメカニズムについて説明します。変換プロセスの一部として、国際化された処理を必要とするメッセージ要素が再コード化または削除され、受信者は、国際化された要素を処理できない場合でも、そのような要素を含むメッセージを受信したことを認識できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6857.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6857で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 4
1.3. Approach Taken in This Specification . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Email Message Header Field Downgrading . . . . . . . . . . . . 7
3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7
3.1.1. Unstructured Downgrading . . . . . . . . . . . . . . . 7
3.1.2. Word Downgrading . . . . . . . . . . . . . . . . . . . 7
3.1.3. Comment Downgrading . . . . . . . . . . . . . . . . . 7
3.1.4. MIME-Value Downgrading . . . . . . . . . . . . . . . . 7
3.1.5. Display-Name Downgrading . . . . . . . . . . . . . . . 7
3.1.6. Domain Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.7. Group Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.8. Mailbox Downgrading . . . . . . . . . . . . . . . . . 8
3.1.9. Type-Addr Downgrading . . . . . . . . . . . . . . . . 9
3.1.10. Encapsulation: A Last Resort . . . . . . . . . . . . . 9
3.2. Downgrading Method for Each Header Field . . . . . . . . . 10
3.2.1. Address Header Fields That Contain <address>
Elements . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Non-ASCII Strings in <comment> Elements . . . . . . . 11
3.2.3. Message-ID Header Fields . . . . . . . . . . . . . . . 11
3.2.4. Received Header Field . . . . . . . . . . . . . . . . 11
3.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 12
3.2.6. Non-ASCII Characters in <unstructured> Elements . . . 12
3.2.7. Non-ASCII Characters in <phrase> Elements . . . . . . 12
3.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 12
4. MIME Body Parts and Delivery Status Notifications . . . . . . 12
4.1. MIME Body Part Header Field Downgrading . . . . . . . . . 13
4.2. Delivery Status Notification Downgrading . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Implementation Note: Encoded-Word Encoding . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Obsolescence of Existing Downgraded-* Header Fields . . . 15
7.2. Registration of New Downgraded-* Header Fields . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Downgrading Example . . . . . . . . . . . . . . . . . 19
Traditional (legacy) mail systems, which are defined by the Internet Message Format [RFC5322] and other specifications, allow only ASCII characters in mail header field values. The SMTPUTF8 extension [RFC6530] [RFC6531] [RFC6532] allows Unicode characters encoded in UTF-8 [RFC3629] in these mail header fields. "Raw non-ASCII strings" refers to strings of those characters in which at least one of them is not part of the ASCII repertoire.
インターネットメッセージフォーマット[RFC5322]およびその他の仕様で定義されている従来の（レガシー）メールシステムでは、メールヘッダーフィールドの値に使用できるのはASCII文字のみです。 SMTPUTF8拡張[RFC6530] [RFC6531] [RFC6532]では、これらのメールヘッダーフィールドで、UTF-8 [RFC3629]でエンコードされたUnicode文字を使用できます。 「生の非ASCII文字列」とは、少なくとも1つの文字列がASCIIレパートリーの一部ではない文字列を指します。
If a header field contains non-ASCII strings, a POP or IMAP server cannot deliver internationalized messages to legacy clients that do not send UTF8 commands or have UTF8 capability. Also, because they have no obvious or standardized way to explain what is going on to clients, a POP or IMAP server cannot even safely discard the message.
ヘッダーフィールドに非ASCII文字列が含まれている場合、POPまたはIMAPサーバーは、UTF8コマンドを送信しない、またはUTF8機能を持たないレガシークライアントに国際化されたメッセージを配信できません。また、クライアントに何が起こっているかを説明する明確な方法や標準化された方法がないため、POPサーバーやIMAPサーバーはメッセージを安全に破棄することもできません。
There are four plausible approaches to the problem. The preferred approach depends on the particular circumstances and relationship among the delivery SMTP server, the mail store, the POP or IMAP server, and the users and their Mail User Agent (MUA) clients. The four approaches are as follows:
この問題に対するもっともらしいアプローチは4つあります。推奨されるアプローチは、配信SMTPサーバー、メールストア、POPサーバーまたはIMAPサーバー、ユーザーとそのメールユーザーエージェント（MUA）クライアント間の特定の状況と関係によって異なります。 4つのアプローチは次のとおりです。
1. If the delivery Mail Transport Agent (MTA) has sufficient knowledge about the POP or IMAP server and the clients being used, the message may be rejected as undeliverable.
1. 配信メールトランスポートエージェント（MTA）がPOPまたはIMAPサーバーおよび使用されているクライアントについて十分な知識を持っている場合、メッセージは配信不能として拒否される可能性があります。
2. A new, surrogate, message may be created by downgrading the original one in the POP or IMAP server in a way that preserves maximum information at the expense of some complexity and that does not create security or operational problems in the mail system. These surrogate messages are referred to as "downgraded" in this specification and as "surrogate messages" elsewhere.
2. POPサーバーまたはIMAPサーバーで元のメッセージをダウングレードすることにより、新しい代理メッセージを作成できます。これは、複雑さを犠牲にして最大の情報を保持し、メールシステムのセキュリティまたは運用上の問題を引き起こさない方法で行います。これらのサロゲートメッセージは、この仕様では「ダウングレード」と呼ばれ、他の場所では「サロゲートメッセージ」と呼ばれます。
3. Some intermediate downgrading may be applied that balances additional information loss against lower complexity and greater ease of implementation.
3. 追加の情報損失と複雑さの軽減および実装の容易さのバランスをとる中間ダウングレードが適用される場合があります。
4. The POP or IMAP server may fabricate a message that is intended to notify the client that an internationalized message is waiting but cannot be delivered until an upgraded client is available.
4. POPまたはIMAPサーバーは、国際化されたメッセージが待機しているが、アップグレードされたクライアントが利用可能になるまで配信できないことをクライアントに通知することを目的としたメッセージを作成する場合があります。
This specification describes the second of these options. It is worth noting that, at least in the general case, none of these options preserves sufficient information to guarantee that it is possible to reply to an incoming message without loss of information, so the choice may be considered one of the available "least bad" options. While this document specifies a well-designed mechanism, it is only an interim solution while clients are being upgraded [RFC6855] [RFC6856].
この仕様では、これらのオプションの2番目について説明します。少なくとも一般的なケースでは、これらのオプションのいずれも、情報を失うことなく着信メッセージに返信できることを保証するのに十分な情報を保持しないため、選択は利用可能な「最低不良」の1つと見なされる場合があります。 "オプション。このドキュメントは適切に設計されたメカニズムを指定していますが、クライアントがアップグレードされている間の暫定的なソリューションにすぎません[RFC6855] [RFC6856]。
This message downgrading mechanism converts mail header fields to an all-ASCII representation. The POP or IMAP server can use the downgrading mechanism and then deliver the internationalized message in a traditional form, which allows receivers to know whether a message is internationalized or unknown or broken.
このメッセージダウングレードメカニズムは、メールヘッダーフィールドをすべてASCIIの表現に変換します。 POPサーバーまたはIMAPサーバーは、ダウングレードメカニズムを使用して、国際化されたメッセージを従来の形式で配信できます。これにより、受信者はメッセージが国際化されているか、不明か、壊れているかを知ることができます。
The Internationalized Mail Header specification [RFC6532] allows UTF-8 characters (see Section 2) to be used in mail header fields and MIME header fields. The Internationalized Mail Transport specification [RFC6531] allows UTF-8 characters to be used in some trace header fields. The message downgrading mechanism specified here describes the method by which internationalized messages [RFC6530] [RFC6532] are converted to traditional email messages [RFC5322].
国際化メールヘッダー仕様[RFC6532]では、UTF-8文字（セクション2を参照）をメールヘッダーフィールドとMIMEヘッダーフィールドで使用できます。 Internationalized Mail Transport仕様[RFC6531]では、一部のトレースヘッダーフィールドでUTF-8文字を使用できます。ここで指定されたメッセージダウングレードメカニズムは、国際化されたメッセージ[RFC6530] [RFC6532]を従来の電子メールメッセージ[RFC5322]に変換する方法を説明しています。
This document provides a precise definition of the minimum-information-loss message downgrading process.
このドキュメントでは、情報損失の少ないメッセージのダウングレードプロセスの正確な定義を提供します。
Downgrading consists of the following two parts:
ダウングレードは、次の2つの部分で構成されています。
o Email header field downgrading
o メールヘッダーフィールドのダウングレード
o MIME header field downgrading
o MIMEヘッダーフィールドのダウングレード
Email header field downgrading is described in Section 3. It generates ASCII-only header fields.
電子メールヘッダーフィールドのダウングレードについては、セクション3で説明します。ASCIIのみのヘッダーフィールドが生成されます。
Header fields starting with Downgraded- are introduced in Section 3.1.10. They preserve the information that appeared in the original header fields.
Downgraded-で始まるヘッダーフィールドは、セクション3.1.10で導入されています。元のヘッダーフィールドに表示された情報を保持します。
The definition of MIME header fields in internationalized messages is described in RFC 6532. A delivery status notification may contain non-ASCII addresses. MIME header field downgrading is described in Section 4.1. Delivery status notification downgrading is described in Section 4.2. It generates ASCII-only MIME header fields.
国際化メッセージのMIMEヘッダーフィールドの定義は、RFC 6532で説明されています。配信ステータス通知には、非ASCIIアドレスが含まれる場合があります。 MIMEヘッダーフィールドのダウングレードについては、セクション4.1で説明しています。配信ステータス通知のダウングレードについては、セクション4.2で説明します。 ASCIIのみのMIMEヘッダーフィールドを生成します。
Displaying downgraded messages that originally contained internationalized header fields is out of scope of this document. A POP or IMAP client that does not support UTF8 extensions as defined for POP3 "UTF8 command" and IMAP "ENABLE UTF8=ACCEPT command" does not recognize the internationalized message format [RFC6532].
国際化されたヘッダーフィールドが元々含まれていたダウングレードされたメッセージの表示は、このドキュメントの範囲外です。 POP3 "UTF8コマンド"およびIMAP "ENABLE UTF8 = ACCEPTコマンド"に定義されているUTF8拡張をサポートしないPOPまたはIMAPクライアントは、国際化されたメッセージ形式[RFC6532]を認識しません。
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]で説明されているように解釈されます。
Many of the specialized terms used in this specification are defined in other documents. They include "Overview and Framework for Internationalized Email" [RFC6530], the Internet Message Format specification [RFC5322], and some of the basic MIME documents [RFC2045] [RFC2183]. This specification makes extensive use of the MIME Message Header Extensions [RFC2047] and extended MIME parameter encodings [RFC2231]. For convenience, both are described as "encoded-words" or "encoded-word encoding". All of the encoded-words generated according to this specification use UTF-8 as their charset.
この仕様で使用される専門用語の多くは、他のドキュメントで定義されています。 「国際化電子メールの概要とフレームワーク」[RFC6530]、インターネットメッセージフォーマット仕様[RFC5322]、およびいくつかの基本的なMIMEドキュメント[RFC2045] [RFC2183]が含まれます。この仕様では、MIMEメッセージヘッダー拡張[RFC2047]と拡張MIMEパラメータエンコーディング[RFC2231]を幅広く使用しています。便宜上、どちらも「encoded-words」または「encoded-word encoding」として説明されています。この仕様に従って生成されたすべてのエンコードされた単語は、文字セットとしてUTF-8を使用します。
The terms "U-label", "A-label", and "IDNA" are used as defined in the IDNA Definitions document [RFC5890]. The terms "ASCII address", "non-ASCII address", "SMTPUTF8", "message", and "internationalized message" are used as defined RFC 6530. The term "non-ASCII string" is used with the definition provided in the Internationalized Email Headers document [RFC6532]. The term "UTF-8 character" is used informally in this document to denote a Unicode character, encoded in UTF-8, outside the ASCII repertoire. Such characters are more formally described using the ABNF element <UTF8-non-ascii>, defined in RFC 6532.
「Uラベル」、「Aラベル」、および「IDNA」という用語は、IDNA定義ドキュメント[RFC5890]で定義されているとおりに使用されます。 「ASCIIアドレス」、「非ASCIIアドレス」、「SMTPUTF8」、「メッセージ」、および「国際化されたメッセージ」という用語は、RFC 6530の定義として使用されます。「非ASCII文字列」という用語は、国際化された電子メールヘッダードキュメント[RFC6532]。このドキュメントでは、「UTF-8文字」という用語を非公式に使用して、ASCIIレパートリー以外のUTF-8でエンコードされたUnicode文字を示します。このような文字は、RFC 6532で定義されているABNF要素<UTF8-non-ascii>を使用してより正式に説明されています。
This document refers to the Augmented Backus-Naur Form (ABNF) [RFC5234] elements that appear in RFC 5322 and RFC 2045. RFC 5322 describes the ABNF elements <CFWS>, <comment>, <display-name>, <group>, <id-left>, <id-right>, <mailbox>, <quoted-string>, <unstructured>, and <word>. RFC 2045 describes the ABNF element <value>. Section 3.3 of the Internationalized Mail Transport specification [RFC6531] and Section 3.2 of the Internationalized Email Headers document [RFC6532] updated <domain> to allow non-ASCII characters.
このドキュメントは、RFC 5322およびRFC 2045に記載されているAugmented Backus-Naur Form（ABNF）[RFC5234]要素を参照しています。RFC5322では、ABNF要素<CFWS>、<comment>、<display-name>、<group>、 <id-left>、<id-right>、<mailbox>、<quoted-string>、<unstructured>、および<word>。 RFC 2045には、ABNF要素<値>が記述されています。国際化メールトランスポート仕様[RFC6531]のセクション3.3および国際化メールヘッダードキュメント[RFC6532]のセクション3.2は、非ASCII文字を許可するように<domain>を更新しました。
Some additional terms are defined locally in-line below.
いくつかの追加の用語は、ローカルで以下に定義されています。
This section defines the method for converting each header field that may contain non-ASCII strings into ASCII. Section 3.1 describes the methods for rewriting each ABNF element. Section 3.2 describes the methods for rewriting each header field.
このセクションでは、非ASCII文字列を含む可能性がある各ヘッダーフィールドをASCIIに変換する方法を定義します。セクション3.1では、各ABNF要素を書き換える方法について説明します。セクション3.2では、各ヘッダーフィールドを書き換える方法について説明します。
Header field downgrading is defined below for each ABNF element. Conversion of the header field terminates when no characters other than those in the ASCII repertoire remain in the header field.
ヘッダーフィールドの格下げは、各ABNF要素に対して以下に定義されています。ヘッダーフィールドにASCIIレパートリー以外の文字が残っていない場合、ヘッダーフィールドの変換は終了します。
If the header field has an <unstructured> field that contains non-ASCII strings, apply encoded-word encoding.
ヘッダーフィールドに非ASCII文字列を含む<unstructured>フィールドがある場合は、encoded-wordエンコーディングを適用します。
If the header field has any <word> fields that contain non-ASCII strings, apply encoded-word encoding.
ヘッダーフィールドに非ASCII文字列を含む<word>フィールドがある場合は、エンコードされたワードエンコーディングを適用します。
If the header field has any <comment> fields that contain non-ASCII strings, apply encoded-word encoding.
ヘッダーフィールドに非ASCII文字列を含む<comment>フィールドがある場合は、エンコードされた単語のエンコーディングを適用します。
If the header field has any <value> elements [RFC2045] that contain non-ASCII strings, remove any <CFWS> that appear outside DQUOTE [RFC5234] that appear in those elements, then encode the <value> elements as extended MIME parameter encodings [RFC2231] and leave the language information empty.
ヘッダーフィールドに非ASCII文字列を含む<value>要素[RFC2045]がある場合は、それらの要素にあるDQUOTE [RFC5234]の外側にある<CFWS>を削除し、<value>要素を拡張MIMEパラメーターエンコーディングとしてエンコードします。 [RFC2231]そして言語情報を空のままにします。
If the header field has any <address> (<mailbox> or <group>) elements, and they have <display-name> elements that contain non-ASCII strings, encode the <display-name> elements as encoded-words. Display-Name downgrading uses the same algorithm as Word downgrading.
ヘッダーフィールドに<address>（<mailbox>または<group>）要素があり、非ASCII文字列を含む<display-name>要素がある場合、<display-name>要素をエンコードされた単語としてエンコードします。 Display-Nameダウングレードは、Wordダウングレードと同じアルゴリズムを使用します。
If the header field has any <domain> elements that contain U-labels, rewrite the non-ASCII domain name into an ASCII domain name using A-labels [RFC5891].
ヘッダーフィールドにUラベルを含む<domain>要素がある場合は、Aラベルを使用して非ASCIIドメイン名をASCIIドメイン名に書き換えます[RFC5891]。
<group> is defined in Section 3.4 of the Internet Message Format specification [RFC5322]. The <group> element may contain <mailbox> elements that contain non-ASCII addresses.
<group>は、インターネットメッセージフォーマット仕様[RFC5322]のセクション3.4で定義されています。 <group>要素には、非ASCIIアドレスを含む<mailbox>要素を含めることができます。
If a <group> element contains <mailbox> elements and one of those
<mailbox> elements contains a non-ASCII <local-part>, rewrite the
<group> element as
display-name " " ENCODED_WORD " :;"
表示名 "" ENCODED_WORD "：;"
where the <ENCODED_WORD> is the original <group-list> encoded as encoded-words.
ここで、<ENCODED_WORD>は、encoded-wordsとしてエンコードされた元の<group-list>です。
Otherwise, the <group> element contains an ASCII-only <local-part>. If the <group> element contains non-ASCII <mailbox> elements, they contain non-ASCII domain names. Rewrite the non-ASCII domain names into ASCII domain names using A-labels [RFC5891]. Generated <mailbox> elements contain ASCII addresses only.
それ以外の場合、<group>要素にはASCIIのみの<local-part>が含まれます。 <group>要素に非ASCIIの<mailbox>要素が含まれている場合、それらには非ASCIIドメイン名が含まれています。 Aラベルを使用して非ASCIIドメイン名をASCIIドメイン名に書き換えます[RFC5891]。生成された<mailbox>要素には、ASCIIアドレスのみが含まれます。
If the <local-part> of the <mailbox> element contains no characters other than those in the ASCII repertoire, the <domain> element may contain non-ASCII characters. Rewrite the non-ASCII domain names into ASCII domain names using A-labels [RFC5891].
<mailbox>要素の<local-part>にASCIIレパートリーの文字以外の文字が含まれていない場合、<domain>要素には非ASCII文字が含まれている可能性があります。 Aラベルを使用して非ASCIIドメイン名をASCIIドメイン名に書き換えます[RFC5891]。
Otherwise, the <local-part> may contain non-ASCII characters. The <local-part> that contains characters outside the ASCII repertoire has no equivalent format for ASCII addresses. The <addr-spec> element that contains non-ASCII strings may appear in two forms as:
そうしないと、<local-part>に非ASCII文字が含まれる可能性があります。 ASCIIレパートリー外の文字を含む<local-part>には、ASCIIアドレスに対応する形式はありません。非ASCII文字列を含む<addr-spec>要素は、次の2つの形式で表示されます。
"<" addr-spec ">"
"<" addr-spec ">"
or
または
addr-spec
addr-spec
Rewrite both as:
両方を次のように書き換えます。
ENCODED-WORD " :;" where the <ENCODED-WORD> is the original <addr-spec> encoded as encoded-words.
エンコードされた単語 "：;"ここで、<ENCODED-WORD>は、encoded-wordsとしてエンコードされた元の<addr-spec>です。
If the header field contains <utf-8-type-addr> and the <utf-8-type-addr> contains raw non-ASCII strings (<UTF8-non-ascii>), it is in utf-8-address form [RFC6533]. Convert it to utf-8-addr-xtext form [RFC6533]. Comment downgrading is also performed in this case. If the address type is unrecognized and the header field contains non-ASCII strings, then fall back to using Encapsulation on the entire header field as specified in Section 3.1.10.
ヘッダーフィールドに<utf-8-type-addr>が含まれ、<utf-8-type-addr>に生の非ASCII文字列（<UTF8-non-ascii>）が含まれている場合、それはutf-8-address形式です。 [RFC6533]。 utf-8-addr-xtext形式[RFC6533]に変換します。この場合、コメントの格下げも行われます。アドレスタイプが認識されず、ヘッダーフィールドに非ASCII文字列が含まれている場合は、セクション3.1.10で指定されているように、ヘッダーフィールド全体でカプセル化を使用するようにフォールバックします。
As a last resort, when header fields cannot be converted as discussed in the previous subsection, the fields are deleted and replaced by specialized new header fields. Those fields are defined to preserve, in encoded form, as much information as possible from the header field values of the incoming message. This mechanism is known as Encapsulation downgrading in this specification because it preserves the original information in a different form. The syntax of these new header fields is:
最後の手段として、前のサブセクションで説明したようにヘッダーフィールドを変換できない場合、フィールドは削除され、特殊な新しいヘッダーフィールドに置き換えられます。これらのフィールドは、着信メッセージのヘッダーフィールド値から可能な限り多くの情報をエンコードされた形式で保持するように定義されています。このメカニズムは、元の情報を別の形式で保持するため、この仕様ではカプセル化ダウングレードと呼ばれています。これらの新しいヘッダーフィールドの構文は次のとおりです。
fields =/ downgraded
フィールド= /ダウングレード
downgraded = "Downgraded-Message-Id:" unstructured CRLF /
"Downgraded-Resent-Message-Id:" unstructured CRLF /
"Downgraded-In-Reply-To:" unstructured CRLF /
"Downgraded-References:" unstructured CRLF /
"Downgraded-Original-Recipient:" unstructured CRLF /
"Downgraded-Final-Recipient:" unstructured CRLF
Applying this procedure to the "Received:" header field is prohibited. Encapsulation downgrading is allowed for "Message-ID:", "In-Reply-To:", "References:", "Original-Recipient:", and "Final-Recipient:" header fields.
この手順を "Received："ヘッダーフィールドに適用することは禁止されています。カプセル化のダウングレードは、「Message-ID：」、「In-Reply-To：」、「References：」、「Original-Recipient：」、および「Final-Recipient：」ヘッダーフィールドで許可されています。
To preserve a header field in a Downgraded- header field:
Downgraded-ヘッダーフィールドのヘッダーフィールドを保持するには：
1. Generate a new header field.
1. 新しいヘッダーフィールドを生成します。
* The field name is a concatenation of Downgraded- and the original field name.
* フィールド名は、ダウングレードされたフィールド名と元のフィールド名を連結したものです。
* The initial new field value is the original header field value.
* 初期の新しいフィールド値は、元のヘッダーフィールド値です。
2. Treat the initial new header field value as if it were unstructured, and then apply the encoded-word encoding as necessary so that the resulting new header field value is completely in ASCII.
2. 構造化されていないかのように最初の新しいヘッダーフィールド値を扱い、必要に応じてエンコードされたワードエンコーディングを適用して、結果の新しいヘッダーフィールド値が完全にASCIIになるようにします。
3. Remove the original header field.
3. 元のヘッダーフィールドを削除します。
The Mail and MIME Header Fields document [RFC4021] establishes a registry of header fields. This section describes the downgrading method for each header field listed in that registry as of the date of publication of this specification.
メールおよびMIMEヘッダーフィールドドキュメント[RFC4021]は、ヘッダーフィールドのレジストリを確立します。このセクションでは、この仕様の公開日現在、そのレジストリにリストされている各ヘッダーフィールドのダウングレード方法について説明します。
If the entire mail header field contains no characters other than those in the ASCII repertoire, 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：Sender：To：Cc：Bcc：Reply-To：Resent-From：Resent-Sender：Resent-To：Resent-Cc：Resent-Bcc：Resent-Reply-To：Return-Path：Disposition-Notification-To：
If the header field contains non-ASCII characters, first perform Comment downgrading and Display-Name downgrading as described in the corresponding subsections of Section 3.1. If the header field still contains non-ASCII characters, complete the following two steps:
ヘッダーフィールドに非ASCII文字が含まれている場合は、まず、セクション3.1の対応するサブセクションで説明されているように、コメントのダウングレードと表示名のダウングレードを実行します。ヘッダーフィールドに非ASCII文字がまだ含まれている場合は、次の2つの手順を実行します。
1. If the header field contains <group> elements that contain non-ASCII addresses, perform Group downgrading on those elements.
1. ヘッダーフィールドに非ASCIIアドレスを含む<group>要素が含まれている場合は、それらの要素に対してグループのダウングレードを実行します。
2. If the header field contains <mailbox> elements that contain non-ASCII addresses, perform Mailbox downgrading on those elements.
2. ヘッダーフィールドに非ASCIIアドレスを含む<mailbox>要素が含まれている場合は、それらの要素に対してメールボックスのダウングレードを実行します。
This procedure may generate empty <group> elements in the "From:" and "Sender:" header fields. The Group Syntax document [RFC6854] updates the Internet Message Format specification [RFC5322] to allow (empty) <group> elements in the "From:" and "Sender:" header fields.
この手順では、「From：」および「Sender：」ヘッダーフィールドに空の<group>要素が生成される場合があります。グループ構文ドキュメント[RFC6854]は、インターネットメッセージフォーマット仕様[RFC5322]を更新して、「From：」および「Sender：」ヘッダーフィールドの<空の> <group>要素を許可します。
Date: Resent-Date: MIME-Version: Content-ID: Content-Transfer-Encoding: Content-Language: Accept-Language: Auto-Submitted:
日付：Resent-Date：MIME-Version：Content-ID：Content-Transfer-Encoding：Content-Language：Accept-Language：Auto-Submitted：
Except in comments, these header fields do not contain characters other than those in the ASCII repertoire. If the header field contains UTF-8 characters in comments, perform Comment downgrading.
コメントを除き、これらのヘッダーフィールドには、ASCIIレパートリー以外の文字は含まれません。ヘッダーフィールドのコメントにUTF-8文字が含まれている場合は、コメントのダウングレードを実行します。
Message-ID: Resent-Message-ID: In-Reply-To: References:
メッセージID：再送信メッセージID：返信先：参照：
If there are non-ASCII strings in <id-left> or <id-right> elements, perform Encapsulation. Otherwise, the header field contains UTF-8 characters in comments and Comment downgrading should be performed.
<id-left>または<id-right>要素に非ASCII文字列がある場合は、カプセル化を実行します。それ以外の場合、ヘッダーフィールドにはコメントにUTF-8文字が含まれており、コメントのダウングレードを実行する必要があります。
Received:
受け取った：
If <domain> elements or <mailbox> elements contain U-labels, perform Domain downgrading as specified in Section 3.1.6. Comments may contain non-ASCII strings; if so, perform Comment downgrading.
<domain>要素または<mailbox>要素にUラベルが含まれている場合は、セクション3.1.6で指定されているようにドメインのダウングレードを実行します。コメントには非ASCII文字列を含めることができます。その場合は、コメントのダウングレードを実行してください。
After the Domain downgrading and the Comment downgrading, if the "FOR" clause contains a non-ASCII <local-part>, remove the FOR clause. If the "ID" clause contains a non-ASCII value, remove the ID clause.
ドメインのダウングレードとコメントのダウングレードの後、「FOR」句に非ASCII <local-part>が含まれている場合は、FOR句を削除します。 「ID」句に非ASCII値が含まれている場合は、ID句を削除します。
Content-Type: Content-Disposition:
Content-Type：Content-Disposition：
If there are non-ASCII strings in <value> or <CFWS> elements, perform MIME-Value and Comment downgrading.
<値>または<CFWS>要素に非ASCII文字列がある場合は、MIME値とコメントのダウングレードを実行します。
Subject: Comments: Content-Description:
件名：コメント：コンテンツ説明：
If non-ASCII strings are present in <unstructured> elements, perform Unstructured downgrading.
非ASCII文字列が<unstructured>要素に存在する場合は、非構造化ダウングレードを実行します。
Keywords:
キーワード：
If non-ASCII strings are present in <phrase> elements, perform Word downgrading.
非ASCII文字列が<phrase>要素に存在する場合は、Wordのダウングレードを実行します。
Other header fields that are not covered in this document (such as implementation-specific or user-defined fields) might also contain non-ASCII strings. Any header field that does not have a conversion method defined above will be in this category and treated as follows.
このドキュメントで説明されていない他のヘッダーフィールド（実装固有のフィールドやユーザー定義のフィールドなど）にも、ASCII以外の文字列が含まれている場合があります。上記で定義された変換メソッドを持たないヘッダーフィールドは、このカテゴリに含まれ、次のように扱われます。
If there are non-ASCII strings present in the header fields, perform Unstructured downgrading.
ヘッダーフィールドに非ASCII文字列が存在する場合は、非構造化ダウングレードを実行します。
If the software understands the header field's structure and a downgrading algorithm other than Unstructured is applicable, that software SHOULD use that algorithm; Unstructured downgrading is used when there is no other option.
ソフトウェアがヘッダーフィールドの構造を理解し、Unstructured以外のダウングレードアルゴリズムが適用できる場合、そのソフトウェアはそのアルゴリズムを使用する必要があります（SHOULD）。非構造化ダウングレードは、他に選択肢がない場合に使用されます。
Mailing list header fields (those that start in "List-") are part of this category.
メーリングリストのヘッダーフィールド（「List-」で始まるフィールド）は、このカテゴリの一部です。
Both the MIME body part header fields [RFC2045] [RFC6532] and the contents of a delivery status notification [RFC6533] may contain non-ASCII characters.
MIMEボディパーツヘッダーフィールド[RFC2045] [RFC6532]と配信ステータス通知のコンテンツ[RFC6533]の両方に非ASCII文字が含まれている可能性があります。
RFC 6532 specifies an extension that permits MIME header fields, including body part header fields, to contain non-ASCII strings. This section defines the conversion method to ASCII-only header fields for each MIME header field that contains non-ASCII strings. Parse the message body's MIME structure at all levels and check each MIME header field to see whether it contains non-ASCII strings. If the header field contains non-ASCII strings in the header field value, the header field is a target of the MIME body part header field's downgrading. The downgrading methods used for the MIME body part header fields Content-ID, Content-Type, Content-Disposition, and Content-Description are the same as those used for the header fields of the same name described in Section 3.2
RFC 6532は、ボディパーツヘッダーフィールドを含むMIMEヘッダーフィールドに非ASCII文字列を含めることを許可する拡張を指定しています。このセクションでは、非ASCII文字列を含むMIMEヘッダーフィールドごとに、ASCIIのみのヘッダーフィールドへの変換方法を定義します。すべてのレベルでメッセージ本文のMIME構造を解析し、各MIMEヘッダーフィールドをチェックして、非ASCII文字列が含まれているかどうかを確認します。ヘッダーフィールドのヘッダーフィールド値に非ASCII文字列が含まれている場合、ヘッダーフィールドはMIMEボディパーツヘッダーフィールドのダウングレードのターゲットです。 MIMEボディパーツのヘッダーフィールドであるContent-ID、Content-Type、Content-Disposition、およびContent-Descriptionに使用されるダウングレード方法は、セクション3.2で説明されている同じ名前のヘッダーフィールドに使用されるものと同じです。
If the message contains a delivery status notification (see Section 6 of the SMTP DSN Extension [RFC3461]), perform the following tests and conversions.
メッセージに配信ステータス通知が含まれている場合（SMTP DSN拡張[RFC3461]のセクション6を参照）、次のテストと変換を実行します。
If there are "Original-Recipient:" and "Final-Recipient:" header fields, and the header fields contain non-ASCII strings, perform Type-Addr downgrading.
「Original-Recipient：」および「Final-Recipient：」ヘッダーフィールドがあり、ヘッダーフィールドに非ASCII文字列が含まれている場合は、Type-Addrダウングレードを実行します。
The purpose of post-delivery message downgrading is to allow POP and IMAP servers to deliver internationalized messages to traditional POP and IMAP clients and to permit the clients to display those messages. Users that receive such messages can know that they were internationalized. It does not permit receivers to read the messages in their original form and, in general, will not permit generating replies, at least without significant user intervention.
配信後メッセージのダウングレードの目的は、POPおよびIMAPサーバーが国際化されたメッセージを従来のPOPおよびIMAPクライアントに配信し、クライアントがそれらのメッセージを表示できるようにすることです。このようなメッセージを受け取ったユーザーは、それらが国際化されたことを知ることができます。これは、受信者がメッセージを元の形式で読み取ることを許可せず、一般的には、少なくともユーザーの介入がなければ、応答の生成を許可しません。
After downgrading as specified in this document, the header fields of a message will contain ASCII characters only, some of them in encoded-word form. Nothing in this document or other SMTPUTF8 specifications [RFC6530] [RFC6531] alters the basic properties of MIME that allow characters outside the ASCII repertoire in encodings as specified for them. Thus, this document inherits the security considerations associated with MIME-encoded header fields as specified in RFC 2047 [RFC2047] and with UTF-8 itself as specified in RFC 3629 [RFC3629].
このドキュメントで指定されているようにダウングレードすると、メッセージのヘッダーフィールドにはASCII文字のみが含まれ、一部はエンコードされた単語形式になります。このドキュメントまたは他のSMTPUTF8仕様[RFC6530] [RFC6531]の何も、指定されたエンコーディングでASCIIレパートリーの外の文字を許可するMIMEの基本的なプロパティを変更しません。したがって、このドキュメントは、RFC 2047 [RFC2047]で指定されているMIMEエンコードされたヘッダーフィールドと、RFC 3629 [RFC3629]で指定されているUTF-8自体に関連するセキュリティの考慮事項を継承しています。
Rewriting header fields increases the opportunities for undetected spoofing by malicious senders. However, the rewritten header field values are preserved in equivalent MIME form or in newly defined header fields for which traditional MUAs have no special processing procedures.
ヘッダーフィールドを書き換えると、悪意のある送信者による検出されないスプーフィングの機会が増加します。ただし、書き換えられたヘッダーフィールド値は、同等のMIME形式、または従来のMUAに特別な処理手順がない新しく定義されたヘッダーフィールドに保存されます。
The techniques described here may invalidate methods that depend on digital signatures over any part of the message, which includes the top-level header fields and body part header fields. Depending on the specific message being downgraded, at least the following techniques are likely to break: DomainKeys Identified Mail (DKIM) and possibly S/MIME and Pretty Good Privacy (PGP). The downgrade mechanism SHOULD NOT remove signatures even if the signatures will fail validation after downgrading. As much of the information as possible from the original message SHOULD be preserved. In addition, MUAs may be able to use the presence of an Authentication-Results header field [RFC5451] to assess whether the digital signatures were valid before the header fields were downgraded.
ここで説明する手法は、トップレベルのヘッダーフィールドとボディパーツのヘッダーフィールドを含むメッセージの任意の部分のデジタル署名に依存するメソッドを無効にする場合があります。ダウングレードされる特定のメッセージに応じて、少なくとも次の手法が壊れる可能性があります：DomainKeys Identified Mail（DKIM）、およびおそらくS / MIMEおよびPretty Good Privacy（PGP）。ダウングレード後に署名が検証に失敗した場合でも、ダウングレードメカニズムは署名を削除しないでください。元のメッセージからできるだけ多くの情報を保存する必要があります。さらに、MUAは、Authentication-Resultsヘッダーフィールド[RFC5451]の存在を使用して、ヘッダーフィールドがダウングレードされる前にデジタル署名が有効であったかどうかを評価できる場合があります。
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. Information in the new Downgraded-* header fields is not inspected by traditional MUAs 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); however, traditional MUAs do not evaluate Downgraded-* header fields.
電子メールヘッダーフィールドの情報は通常、何らかの疑いを持って扱われるべきですが、現在の電子メールシステムは一般に、情報をより信頼できるものにするためにさまざまなメカニズムとプロトコルを採用しています。新しいDowngraded- *ヘッダーフィールドの情報は、従来のMUAによって検査されないため、従来のヘッダーフィールドよりも信頼性が低くなる可能性があります。 Downgraded- *ヘッダーフィールドは、悪意を持って（および従来のヘッダーフィールドとは無関係の内容で）挿入されている可能性があることに注意してください。ただし、従来のMUAはDowngraded- *ヘッダーフィールドを評価しません。
See the Security Considerations sections in the Group Syntax document [RFC6854] and the Internationalized Email Framework [RFC6530] for more discussion.
詳細については、グループ構文ドキュメント[RFC6854]および国際化電子メールフレームワーク[RFC6530]のセキュリティに関する考慮事項のセクションを参照してください。
While the specification of encoded-words includes specific rules for dealing with whitespace in adjacent encoded words [RFC2047], 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.
エンコードされた単語の仕様には、隣接するエンコードされた単語の空白を処理するための特定のルールが含まれていますが[RFC2047]、アルゴリズムを正しく実装できないいくつかの実装された実装があります。その結果、実際には、複数のエンコードされた単語が使用されている場合、空白の動作は多少予測できません。
While RFC 5322 states that implementations SHOULD limit lines to 78 characters or less, implementations MAY choose to allow overly long encoded words to work around faulty implementations of encoded-words. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters.
RFC 5322では、実装は行を78文字以下に制限する必要があると述べていますが、実装は、エンコードされた単語の誤った実装を回避するために、過度に長いエンコードされた単語を許可することを選択できます。そうすることを選択した実装には、行の長さを78文字に制限するオプションのメカニズムが必要です（SHOULD）。
The experimental specification from which this document was partially derived [RFC5504] specifies that no new header fields beginning with Downgraded- are to be registered. That restriction is now lifted, and this document makes a new set of registrations, replacing the experimental fields with standard ones.
このドキュメントの一部である実験仕様[RFC5504]は、Downgraded-で始まる新しいヘッダーフィールドを登録しないことを指定しています。この制限は解除され、このドキュメントは新しい登録セットを作成し、実験フィールドを標準フィールドに置き換えます。
The Downgraded-* header fields that were registered as experimental fields in RFC 5504 are no longer in use. IANA has changed the status from "experimental" to "obsoleted" for every name in the "Permanent Message Header Field Names" registry that began with Downgraded-.
RFC 5504で実験的フィールドとして登録されていたDowngraded- *ヘッダーフィールドは使用されなくなりました。 IANAは、Downgraded-で始まる「Permanent Message Header Field Names」レジストリ内のすべての名前のステータスを「実験的」から「廃止」に変更しました。
The following header fields have been registered in the "Permanent Message Header Field Names" registry, in accordance with the procedures set out in the Header Field Registration document [RFC3864].
以下のヘッダーフィールドは、ヘッダーフィールド登録ドキュメント[RFC3864]で説明されている手順に従って、「Permanent Message Header Field Names」レジストリに登録されています。
Header field name: Downgraded-Message-Id
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-In-Reply-To
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-References
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Original-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Final-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
This document draws heavily from the experimental in-transit message downgrading procedure described RFC 5504. The contributions of the coauthor of that earlier document, Y. Yoneya, are gratefully acknowledged. Significant comments and suggestions were received from John Klensin, Barry Leiba, Randall Gellens, Pete Resnick, Martin J. Durst, and other WG participants.
このドキュメントは、RFC 5504で説明されている実験的な送信中メッセージダウングレード手順から大きく引き出されています。その以前のドキュメントの共著者であるY. Yoneyaの貢献は、ありがたく認められています。 John Klensin、Barry Leiba、Randall Gellens、Pete Resnick、Martin J. Durst、およびその他のWG参加者から、重要なコメントと提案が寄せられました。
[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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、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、「Communicating Presentation Information in Internet Messages：The Content-Disposition Header Field」、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月。
[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 Notifications（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]クライン、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. Palme、「Registration of Mail and MIME Header Fields」、RFC 4021、2005年3月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、2010年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J。およびY. Ko、「Overview and Framework for Internationalized Email」、RFC 6530、2012年2月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, February 2012.
[RFC6531] Yao、J.およびW. Mao、「SMTP Extension for Internationalized Email」、RFC 6531、2012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、2012年2月。
[RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.
[RFC6533] Hansen、T.、Newman、C。、およびA. Melnikov、「Internationalized Delivery Status and Disposition Notifications」、RFC 6533、2012年2月。
[RFC6854] Leiba, B., "Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields", RFC 6854, March 2013.
[RFC6854] Leiba、B。、「 "From："および "Sender："ヘッダーフィールドでグループ構文を許可するためのインターネットメッセージ形式の更新」、RFC 6854、2013年3月。
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", RFC 6855, March 2013.
[RFC6855] Resnick、P。、編、Newman、C。、編、S。Shen、編、「IMAP Support for UTF-8」、RFC 6855、2013年3月。
[RFC6856] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "Post Office Protocol Version 3 (POP3) Support for UTF-8", RFC 6856, March 2013.
[RFC6856] Gellens、R.、Newman、C.、Yao、J。、およびK. Fujiwara、「Post Office Protocol Version 3（POP3）Support for UTF-8」、RFC 6856、2013年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 5451、2009年4月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504] Fujiwara、K. and Y. Yoneya、 "Downgrading Mechanism for Email Address Internationalization"、RFC 5504、March 2009。
This appendix shows a message downgrading example. Consider a received mail message where:
この付録では、メッセージのダウングレードの例を示します。受信したメールメッセージについて考えてみましょう。
o The sender address is a non-ASCII address, "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY-LOCAL".
o 送信者アドレスは非ASCIIアドレス、「NON-ASCII-LOCAL@example.com」です。その表示名は「DISPLAY-LOCAL」です。
o The "To:" header field contains two non-ASCII addresses, "NON-ASCII-REMOTE1@example.net" and "NON-ASCII-REMOTE2@example.com". Their display-names are "DISPLAY-REMOTE1" and "DISPLAY-REMOTE2".
o "To："ヘッダーフィールドには、 "NON-ASCII-REMOTE1@example.net"と "NON-ASCII-REMOTE2@example.com"の2つの非ASCIIアドレスが含まれています。それらの表示名は「DISPLAY-REMOTE1」と「DISPLAY-REMOTE2」です。
o The "Cc:" header field contains a non-ASCII address, "NON-ASCII-REMOTE3@example.org". Its display-name is "DISPLAY-REMOTE3".
o 「Cc：」ヘッダーフィールドには、非ASCIIアドレス「NON-ASCII-REMOTE3@example.org」が含まれています。その表示名は「DISPLAY-REMOTE3」です。
o Four display-names contain non-ASCII characters.
o 4つの表示名に非ASCII文字が含まれています。
o The "Subject:" header field is "NON-ASCII-SUBJECT", which contains non-ASCII strings.
o 「Subject：」ヘッダーフィールドは「NON-ASCII-SUBJECT」で、非ASCII文字列が含まれています。
o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", which contains non-ASCII strings.
o 「Message-Id：」ヘッダーフィールドには、非ASCII文字列を含む「NON-ASCII-MESSAGE_ID」が含まれています。
o There is an unknown header field "X-Unknown-Header:", which contains non-ASCII strings.
o 不明なヘッダーフィールド「X-Unknown-Header：」があり、非ASCII文字列が含まれています。
Return-Path: <NON-ASCII-LOCAL@example.com>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>
To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,
DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>
Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>
Subject: NON-ASCII-SUBJECT
Date: Mon, 30 Jul 2012 01:23:45 -0000
Message-Id: NON-ASCII-MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: NON-ASCII-CHARACTERS
MAIL_BODY
MAIL_BODY
Figure 1: Received Message in a Maildrop
図1：メールドロップで受信したメッセージ
The downgraded message is shown in Figure 2. "Return-Path:", "From:", "To:", and "Cc:" header fields are rewritten. "Subject:" and "X-Unknown-Header:" header fields are encoded as encoded-words. The "Message-Id:" header field is encapsulated as a "Downgraded-Message-Id:" header field.
ダウングレードされたメッセージを図2に示します。「Return-Path：」、「From：」、「To：」、および「Cc：」ヘッダーフィールドは書き換えられます。 「Subject：」および「X-Unknown-Header：」ヘッダーフィールドは、encoded-wordsとしてエンコードされます。 「Message-Id：」ヘッダーフィールドは、「Downgraded-Message-Id：」ヘッダーフィールドとしてカプセル化されます。
Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
Received: from ... by ...
Received: from ... by ...
From: =?UTF-8?Q?DISPLAY-LOCAL?=
=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
To: =?UTF-8?Q?DISPLAY-REMOTE1?=
=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
=?UTF-8?Q?DISPLAY-REMOTE2?=
=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=
=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Date: Mon, 30 Jul 2012 01:23:45 -0000
Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
MAIL_BODY
MAIL_BODY
Figure 2: Downgraded Message
図2：ダウングレードされたメッセージ
Author's Address
著者のアドレス
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
かずのり ふじわら じゃぱん れぎｓｔｒｙ せｒゔぃせｓ こ。、 Ｌｔｄ。 ちよだ ふぃｒｓｔ Ｂｌｄｇ。 えあｓｔ １３Ｆ、 ３ー８ー１ にしーかんだ ちよだーく、 ときょ １０１ー００６５ じゃぱん
Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp