[要約] RFC 6530は、国際化されたメールの概要とフレームワークを提供するものであり、国際的なメールの相互運用性を向上させることを目的としています。
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 6530 Y. Ko
Obsoletes: 4952, 5504, 5825 February 2012
Category: Standards Track
ISSN: 2070-1721
Overview and Framework for Internationalized Email
国際化された電子メールの概要とフレームワーク
Abstract
概要
Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published.
世界中で電子メールを完全に使用するには、（他の制約の対象となる）人々が、電子メールアドレスのメールボックス名として自分の名前（独自の言語やスクリプトで正しく書かれている）で密接なバリエーションを使用できることが必要です。このドキュメントでは、国際化された電子メールアドレスを完全にサポートするために必要なメカニズムとプロトコル拡張を定義する一連の仕様を紹介します。これらの変更には、UTF-8データに対応するためのSMTP拡張と電子メールヘッダー構文の拡張が含まれます。ドキュメントセットには、完全な国際化された電子メールの展開における重要な仮定と問題の議論も含まれています。このドキュメントは、RFC 4952の代替品です。その文書が公開されてから特定された追加の問題を反映しています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6530.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6530で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。あなたの権利と制限を尊重して説明しているので、これらの文書を注意深く確認してください
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.
この文書に。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing after Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18
11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
12. Key Changes from the Experimental Protocols and Framework . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . . 22
In order to use internationalized email addresses, it is necessary to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC5890], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 5322 [RFC5322] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant header fields. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all.
国際化されたメールアドレスを使用するには、ドメイン部分と電子メールアドレスのローカル部分の両方を国際化する必要があります。電子メールアドレスのドメイン部分はすでに国際化[RFC5890]ですが、ローカル部分はすでにありません。このドキュメントで指定された拡張機能がない場合、メールボックス名は7ビットASCII [RFC5321]のサブセットに制限されています。 MIME [RFC2045]は非ASCIIデータの輸送を可能にしますが、国際化された電子メールアドレスのメカニズムは提供されません。 RFC 2047 [RFC2047]では、MIMEは、ASCII以外のデータに対応するための特定のメッセージヘッダーフィールドのエンコードメカニズムを定義しています。ただし、ASCII以外の文字を含む電子メールアドレスの使用は許可されていません。ここで定義されている拡張機能、または同等のセットがない場合、電子メールアドレスのいずれかの部分に非ASCII文字を組み込む唯一の方法は、RFC 2047コーディングを使用して、RFC 5322 [RFC5322]が「ディスプレイ名」（既知のディスプレイ名」と呼ぶものにそれらを埋め込むことです。関連するヘッダーフィールドの「名前フレーズ」または他の用語で）として。ディスプレイ名にコード化された情報は、メッセージエンベロープでは見えません。多くの目的で、アドレスの一部ではありません。
This document is a replacement for RFC 4952 [RFC4952]; it reflects additional issues, shared terminology, and some architectural changes identified since that document was published. It obsoletes that document. The experimental descriptions of in-transit downgrading [RFC5504] [RFC5825] are now irrelevant and no longer needed due to the changes discussed in Section 12. The RFC Editor is requested to move all three of those documents to Historic.
このドキュメントは、RFC 4952 [RFC4952]の代替品です。これは、追加の問題、共有用語、およびその文書が公開されて以来特定されたいくつかのアーキテクチャの変更を反映しています。それはその文書を廃止します。輸送中の格下げ[RFC5504] [RFC5825]の実験的説明は現在無関係であり、セクション12で説明されている変更のためにもはや必要ありません。RFCエディターは、これらのドキュメントの3つすべてを歴史的に移動するように要求されています。
The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender.
代名詞「彼」と「彼女」は、不確定な性別の人間を示すために交換可能に使用されます。
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 BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
This document presents the overview and framework for an approach to the next stage of email internationalization. This new stage requires not only internationalization of addresses and header fields, but also associated transport and delivery models. A prior version of this specification, RFC 4952 [RFC4952], also provided an introduction to a series of experimental protocols [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This revised form provides overview and conceptual information for the Standards Track successors of a subset of those protocols. Details
このドキュメントでは、電子メール国際化の次の段階へのアプローチの概要とフレームワークを示します。この新しい段階では、住所とヘッダーフィールドの国際化だけでなく、関連する輸送および配信モデルも必要です。この仕様の以前のバージョンであるRFC 4952 [RFC4952]は、一連の実験プロトコル[RFC5335] [RFC5337] [RFC5337] [RFC5337] [RFC5721] [RFC5738] [RFC5825]の紹介も提供しました。この改訂されたフォームは、これらのプロトコルのサブセットの後継者を追跡する標準の概要と概念情報を提供します。詳細
of the documents and the relationships among them appear in Section 5 and a discussion of what was learned from the experimental protocols and their implementations appears in Section 6.
ドキュメントとそれらの間の関係は、セクション5に表示され、実験プロトコルとその実装から学んだことの議論がセクション6に表示されます。
Taken together, these specifications provide the details for a way to implement and support internationalized email. The document itself describes how the various elements of email internationalization fit together and the relationships among the primary specifications associated with message transport, header formats, and handling.
まとめると、これらの仕様は、国際化された電子メールを実装およびサポートする方法の詳細を提供します。ドキュメント自体は、電子メールの国際化のさまざまな要素がどのように合うか、メッセージトランスポート、ヘッダー形式、および処理に関連する主要な仕様間の関係を説明しています。
This document, and others that comprise the collection described above, assume a reasonable familiarity with the basic Internet electronic mail specifications and terminology [RFC5321] [RFC5322] and the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While not strictly required to implement this specification, a general familiarity with the terminology and functions of IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] are also assumed.
上記のコレクションを構成するこのドキュメントは、基本的なインターネット電子メールの仕様と用語[RFC5321] [RFC5322]およびMIME [RFC2045]および8Bitmime [RFC6152]の文書にも合理的な知識があると仮定しています。この仕様を実装するために厳密には必要ありませんが、IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894]の用語と機能に一般的に精通しています。
Internationalizing Domain Names in Applications (IDNA) [RFC5890] permits internationalized domain names, but deployment has not yet reached most users. One of the reasons for this is that we do not yet have fully internationalized naming schemes. Domain names are just one of the various names and identifiers that are required to be internationalized. In many contexts, until more of those identifiers are internationalized, internationalized domain names alone have little value.
アプリケーションの国際化ドメイン名（IDNA）[RFC5890]は国際化されたドメイン名を許可していますが、展開はまだほとんどのユーザーに到達していません。これの理由の1つは、まだ完全に国際化された命名スキームがないことです。ドメイン名は、国際化する必要があるさまざまな名前と識別子の1つにすぎません。多くの文脈では、これらの識別子の多くが国際化されるまで、国際化されたドメイン名だけではほとんど価値がありません。
Email addresses are prime examples of why it is not good enough to just internationalize the domain name. As most observers have learned from experience, users strongly prefer email addresses that resemble names or initials to those involving seemingly meaningless strings of letters or numbers. Unless the entire email address can use familiar characters and formats, users will perceive email as being culturally unfriendly. If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script.
メールアドレスは、ドメイン名を国際化するだけでは十分ではない理由の主要な例です。ほとんどのオブザーバーが経験から学んだように、ユーザーは、一見意味のない文字や数字の文字列を含む名前やイニシャルに似た電子メールアドレスを強く好みます。メールアドレス全体が馴染みのある文字やフォーマットを使用できない限り、ユーザーは電子メールを文化的に友好的ではないと認識します。メールアドレスで使用される名前とイニシャルがネイティブ言語やユーザーの作成システムで表現できる場合、特にネイティブ言語がローマ由来のスクリプトのサブセットに書かれていない人によって、インターネットはより自然であると認識されます。
Internationalization of email addresses is not merely a matter of changing the SMTP envelope; or of modifying the "From:", "To:", and "Cc:" header fields; or of permitting upgraded Mail User Agents (MUAs) to decode a special coding and respond by displaying local characters. To be perceived as usable, the addresses must be internationalized and handled consistently in all of the contexts in which they occur. This requirement has far-reaching implications:
電子メールアドレスの国際化は、単にSMTPエンベロープを変更する問題ではありません。または、「from：」、 "to："、および "cc："ヘッダーフィールドを変更する;または、アップグレードされたメールユーザーエージェント（MUA）を許可して、特別なコーディングをデコードし、ローカル文字を表示して応答します。使用可能であると認識されるには、アドレスは国際化され、それらが発生するすべてのコンテキストで一貫して処理されなければなりません。この要件には、広範囲の意味があります。
collections of patches and workarounds are not adequate. Even if they were adequate, a workaround-based approach may result in an assortment of implementations with different sets of patches and workarounds having been applied with consequent user confusion about what is actually usable and supported. Instead, we need to build a fully internationalized email environment, focusing on permitting efficient communication among those who share a language and writing system. That, in turn, implies changes to the mail header environment to permit those header fields that are appropriately internationalized to utilize the full range of Unicode characters, an SMTP extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing and delivery of those extended header fields, support for internationalization of delivery and service notifications [RFC3461] [RFC3464], and (finally) a requirement for support of the 8BITMIME SMTP extension [RFC6152] so that all of these can be transported through the mail system without having to overcome the limitation that header fields do not have content-transfer-encodings.
パッチと回避策のコレクションは適切ではありません。たとえそれらが適切であったとしても、回避策ベースのアプローチは、実際に使用可能でサポートされているものについての結果として、ユーザーの混乱とともに、さまざまなパッチと回避策を備えた実装の品揃えをもたらす可能性があります。代わりに、言語とライティングシステムを共有する人々の間で効率的なコミュニケーションを許可することに焦点を当て、完全に国際化された電子メール環境を構築する必要があります。これは、Mail Header環境への変更を意味して、UTF-8 [RFC3629] [RFC5198]を許可するSMTP拡張機能の全範囲のUnicode文字を利用するために適切に国際化されているヘッダーフィールドを許可することを意味します。拡張ヘッダーフィールド、配信およびサービス通知の国際化のサポート[RFC3461] [RFC3464]、および（最後に）8ビットマイムSMTP拡張[RFC6152]のサポートの要件であるためヘッダーフィールドにはコンテンツ転送エンコードがないという制限を克服します。
This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in RFC 5321 [RFC5321] and RFC 5322 [RFC5322].
このドキュメントでは、RFC 5321 [RFC5321]およびRFC 5322 [RFC5322]に記載されているコアメール標準のプロトコルと用語の合理的な理解を想定しています。
Much of the description in this document depends on the abstractions of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). However, it is important to understand that those terms and the underlying concepts postdate the design of the Internet's email architecture and the application of the "protocols on the wire" principle to it. That email architecture, as it has evolved, and that "on the wire" principle have prevented any strong and standardized distinctions about how MTAs and MUAs interact on a given origin or destination host (or even whether they are separate).
このドキュメントの説明の多くは、「メール転送エージェント」（「MTA」）と「メールユーザーエージェント」（「MUA」）の抽象化に依存しています。ただし、これらの用語と基礎となる概念が、インターネットの電子メールアーキテクチャの設計と、「ワイヤー上のプロトコル」の原則を適用することを課していることを理解することが重要です。その電子メールアーキテクチャは、それが進化したように、そしてその「ワイヤー上」の原則は、MTAとMUAが特定の原点または宛先ホスト（またはそれらが別々であるかどうか）でどのように相互作用するかについての強力で標準化された区別を妨げました。
However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery system" of RFC 5321. This is the SMTP server that controls the format of the local parts of addresses and is permitted to inspect and interpret them. It receives messages from the network for delivery to mailboxes or for other local processing, including any forwarding or aliasing that changes envelope addresses, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence are not part of the SMTP transport or delivery process.
ただし、「最終配信MTA」という用語は、このドキュメントでは、RFC 5321の「配信システム」または「最終配信システム」という用語に相当するファッションで使用されます。これは、アドレスのローカル部分の形式を制御するSMTPサーバーです。それらを検査して解釈することが許可されています。ネットワークから、メールボックスへの配信またはその他のローカル処理のためにメッセージを受信します。ネットワークの観点から見ると、メッセージストアへの保存、特定のメッセージ配信プログラムまたはエージェントへのハンドオフ、メッセージを取得するメカニズムなどのローカル配信の取り決めはすべて最終配信MTAの「後ろ」であり、したがってSMTPの一部ではありません。輸送または配送プロセス。
In this document, an address is "all-ASCII", or just an "ASCII address", if every character in the address is in the ASCII character repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address", if any character is not in the ASCII character repertoire. Such addresses MAY be restricted in other ways, but those restrictions are not relevant to this definition. The term "all-ASCII" is also applied to other protocol elements when the distinction is important, with "non-ASCII" or "internationalized" as its opposite.
このドキュメントでは、アドレスは「All-ascii」、または単なる「ASCIIアドレス」です。アドレスは、ASCII文字レパートリーにないキャラクターがいない場合、「非ASCII」または「I18N-Address」です。そのようなアドレスは他の方法で制限される場合がありますが、これらの制限はこの定義には関係ありません。「All-ascii」という用語は、区別が重要な場合に他のプロトコル要素にも適用され、「非ASCII」または「国際化」が反対です。
The umbrella term to describe the email address internationalization specified by this document and its companion documents is "SMTPUTF8". For example, an address permitted by this specification is referred to as a "SMTPUTF8 (compliant) address".
このドキュメントとそのコンパニオンドキュメントで指定された電子メールアドレスの国際化を説明する傘の用語は「SMTPUTF8」です。たとえば、この仕様で許可されているアドレスは、「SMTPUTF8（準拠）アドレス」と呼ばれます。
Please note that, according to the definitions given here, the set of all "all-ASCII" addresses and the set of all "non-ASCII" addresses are mutually exclusive. The set of all addresses permitted when SMTPUTF8 appears is the union of these two sets.
ここに記載されている定義によれば、すべての「すべてASCII」アドレスのセットとすべての「非ASCII」アドレスのセットは相互に排他的であることに注意してください。SMTPUTF8が表示されるときに許可されるすべてのアドレスのセットは、これら2つのセットの結合です。
An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters.
「ASCIIユーザー」（i）は、ASCII文字のみを含む電子メールアドレスのみを使用し、（ii）非ASCII文字を含む受信者アドレスを生成できません。
An "internationalized email user" has one or more non-ASCII email addresses, or is able to generate recipient addresses that contain non-ASCII characters. Such a user may have ASCII addresses too; if the user has more than one email account and a corresponding address, or more than one alias for the same address, he or she has some method to choose which address to use on outgoing email. Note that under this definition, it is not possible to tell from an ASCII address if the owner of that address is an internationalized email user or not. (A non-ASCII address implies a belief that the owner of that address is an internationalized email user.) There is no such thing as an "internationalized email user message"; the term applies only to users and their agents and capabilities. In particular, the use of non-ASCII, and hence presumably internationalized, message content is an integral part of the MIME specifications [RFC2045] and does not require these extensions (although it is compatible with them).
「国際化された電子メールユーザー」には、1つ以上の非ASCII電子メールアドレスがあります。または、ASCII以外の文字を含む受信者アドレスを生成することができます。このようなユーザーは、ASCIIアドレスも持っている可能性があります。ユーザーが複数の電子メールアカウントと対応するアドレス、または同じアドレスの複数のエイリアスを持っている場合、送信メールで使用するアドレスを選択する方法があります。この定義の下では、そのアドレスの所有者が国際化された電子メールユーザーであるかどうかをASCIIアドレスから伝えることはできないことに注意してください。 （非ASSASCIIアドレスは、そのアドレスの所有者が国際化された電子メールユーザーであるという信念を暗示しています。）「国際化された電子メールユーザーメッセージ」のようなものはありません。この用語は、ユーザーとそのエージェントと機能にのみ適用されます。特に、非ASCIIの使用、したがっておそらく国際化されたと思われるメッセージコンテンツは、MIME仕様[RFC2045]の不可欠な部分であり、これらの拡張機能を必要としません（ただし、それらと互換性があります）。
A "message" is sent from one user (the sender) using a particular email address to one or more other recipient email addresses (often referred to just as "users" or "recipient users").
「メッセージ」は、特定のメールアドレスを使用して1人のユーザー（送信者）から送信されます。
A "mailing list" is a mechanism whereby a message may be distributed to multiple recipients by sending it to one recipient address. An agent (typically not a human being) at that single address then causes the message to be redistributed to the target recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original single recipient message. Using a different envelope return address (reverse-path) causes error (and other automatically generated) messages to go to an error-handling address.
「メーリングリスト」は、1つの受信者アドレスに送信することにより、複数の受信者にメッセージを配布できるメカニズムです。その単一のアドレスのエージェント（通常は人間ではありません）は、メッセージをターゲット受信者に再配布します。このエージェントは、元の単一の受信者メッセージとは異なるアドレスに再配布されたメッセージの封筒返信アドレスを設定します。別のエンベロープの返品アドレス（リバースパス）を使用すると、エラー（およびその他の自動生成された）メッセージがエラー処理アドレスに移動します。
Special provisions for managing mailing lists that might contain non-ASCII addresses are discussed in a document that is specific to that topic [RFC5983] and its expected successor [RFC5983bis-MailingList].
ASCII以外のアドレスを含む可能性のあるメーリングリストを管理するための特別な規定については、そのトピック[RFC5983]とその予想される後継[RFC5983BIS-Mailinist]に固有のドキュメントで説明されています。
o A conventional message is one that does not use any extension defined in the SMTP extension document [RFC6531] or in the UTF8header document [RFC6532] in this set of specifications, and is strictly conformant to RFC 5322 [RFC5322].
o 従来のメッセージとは、SMTP拡張ドキュメント[RFC6531]またはこの一連の仕様のUTF8Headerドキュメント[RFC6532]で定義された拡張機能を使用しないものであり、RFC 5322 [RFC5322]に厳密に適合しています。
o An internationalized message is a message utilizing one or more of the extensions defined in this set of specifications, so that it is no longer conformant to the traditional specification of an email message or its transport.
o 国際化されたメッセージは、この仕様のセットで定義されている1つ以上の拡張機能を使用したメッセージであるため、電子メールメッセージまたはそのトランスポートの従来の仕様に適合しなくなります。
As specified in RFC 5321, a message that is undeliverable for some reason is expected to result in notification to the sender. This can occur in either of two ways. One, typically called "Rejection", occurs when an SMTP server returns a reply code indicating a fatal error (a "5yz" code) or persistently returns a temporary failure error (a "4yz" code). The other involves accepting the message during SMTP processing and then generating a message to the sender, typically known as a "Non-delivery Notification" or "NDN". Current practice often favors rejection over NDNs because of the reduced likelihood that the generation of NDNs will be used as a spamming technique. The latter, NDN, case is unavoidable if an intermediate MTA accepts a message that is then rejected by the next-hop server.
RFC 5321で指定されているように、何らかの理由で配信不可能なメッセージは、送信者への通知をもたらすと予想されます。これは、2つの方法のいずれかで発生する可能性があります。通常、「拒否」と呼ばれる1つは、SMTPサーバーが致命的なエラー（「5YZ」コード）を示す返信コードを返すときに発生するか、一時的な障害エラー（「4YZ」コード）を永続的に返します。もう1つは、SMTP処理中にメッセージを受け入れ、通常は「非配信通知」または「NDN」と呼ばれる送信者にメッセージを生成することを伴います。現在の慣行は、NDNの生成がスパム技術として使用される可能性が低下するため、NDNに対する拒否をしばしば支持します。後者のNDNは、中間MTAが次のホップサーバーによって拒否されるメッセージを受け入れる場合、避けられません。
A sender MAY also explicitly request message receipts [RFC3461] that raise the same issues for these internationalization extensions as NDNs.
また、送信者は、これらの国際化拡張に対してNDNと同じ問題を提起するメッセージ受信[RFC3461]を明示的に要求する場合があります。
This set of specifications changes both SMTP and the character encoding of email message headers to permit non-ASCII characters to be represented directly. Each important component of the work is described in a separate document. The document set, whose members are described below, also contains Informational documents whose purpose is to provide implementation suggestions and guidance for the protocols.
この一連の仕様は、SMTPと電子メールメッセージヘッダーの文字エンコードの両方を変更して、非ASCII文字を直接表現できるようにします。作業の各重要なコンポーネントは、別のドキュメントで説明されています。メンバーを以下に説明するドキュメントセットには、プロトコルの実装提案とガイダンスを提供することを目的とする情報ドキュメントも含まれています。
In addition to this document, the following documents make up this specification and provide advice and context for it.
このドキュメントに加えて、次のドキュメントはこの仕様を構成し、アドバイスとコンテキストを提供します。
o SMTP extension. The SMTP extension document [RFC6531] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses.
o SMTP拡張。SMTP拡張ドキュメント[RFC6531]は、国際化された住所にSMTP拡張（RFC 5321で規定されている）を提供します。
o Email message headers in UTF-8. The email message header document [RFC6532] essentially updates RFC 5322 to permit some information in email message headers to be expressed directly by Unicode characters encoded in UTF-8 when the SMTP extension described above is used. This document, possibly with one or more supplemental ones, will also need to address the interactions with MIME, including relationships between SMTPUTF8 and internal MIME headers and content types.
o UTF-8の電子メールメッセージヘッダー。電子メールメッセージヘッダードキュメント[RFC6532]は基本的にRFC 5322を更新して、上記のSMTP拡張機能を使用した場合にUTF-8にエンコードされたUnicode文字で電子メールメッセージヘッダーの情報を直接表現できるようにします。このドキュメントは、おそらく1つ以上の補足的なものを使用して、SMTPUTF8と内部MIMEヘッダーとコンテンツタイプの関係など、MIMEとの相互作用に対処する必要があります。
o Extensions to delivery status and notification handling to adapt to internationalized addresses [RFC6533].
o 配信ステータスへの拡張と、国際化された住所に適応するための通知処理[RFC6533]。
o Forthcoming documents will specify extensions to the IMAP protocol [RFC3501] to support internationalized message headers [RFC5738bis-IMAP], parallel extensions to the POP protocol [RFC5721] [RFC5721bis-POP3], and some common properties of the two [POPIMAP-downgrade].
o 今後のドキュメントでは、IMAPプロトコル[RFC3501]への拡張機能を指定して、国際化されたメッセージヘッダー[RFC5738BIS-IMAP]、POPプロトコル[RFC5721] [RFC5721BIS-POP3]、および2つの[Popimap-Soldgrade]のいくつかの一般的な特性への並列拡張をサポートします。。
The key difference between this set of protocols and the experimental set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a mechanism for in-transit downgrading of messages (described in detail in RFC 5504). That mechanism permitted, and essentially required, that each non-ASCII address be accompanied by an all-ASCII equivalent. That, in turn, raised security concerns associated with
[RFC5335] [RFC5336] [RFC5721] [RFC5721] [RFC5738] [RFC5825] [RFC5336] [RFC5336] [RFC5336] [RFC5336] [RFC5336] [RFC5336] [RFC5336] [RFC5336] [RFC5721] [RFC5825]は、それらに先行するこのプロトコルのセットとの重要な違いは、以前のグループが、トランス酸樹状の機械を提供したことです。メッセージ（RFC 5504で詳細に説明）。このメカニズムは、各ASCIIアドレスに全ASCIIに相当するものを伴うことを許可し、本質的に必要としています。それは、それに関連するセキュリティ上の懸念を提起しました
pairing of addresses that could not be authenticated. It also introduced the first incompatible change to Internet mail addressing in many years, raising concerns about interoperability issues if the new address forms "leaked" into legacy email implementations. After examining experience with the earlier, experimental, predecessors of these specifications, the working group that produced them concluded that the advantages of in-transit downgrading, were it feasible operationally, would be significant enough to overcome those concerns.
認証できなかったアドレスのペアリング。また、長年にわたってインターネットメールアドレス指定に最初の互換性のない変更を導入し、新しいアドレスがレガシーメールの実装に「リーク」された場合、相互運用性の問題に関する懸念を提起しました。これらの仕様の以前の実験的な前任者との経験を調べた後、それらを生成したワーキンググループは、輸送中の格下げの利点は運用可能であれば、それらの懸念を克服するのに十分なほど重要であると結論付けました。
That turned out not to be the case, with interoperability problems among initial implementations. Prior to starting on the work that led to this set of specifications, the WG concluded that the combination of requirements and long-term implications of that earlier model were too complex to be satisfactory and that work should move ahead without it.
それは、初期の実装の間の相互運用性の問題で、そうではないことが判明しました。この一連の仕様につながった作業を開始する前に、WGは、要件とその以前のモデルの長期的な意味の組み合わせは、満足のいくものではないほど複雑すぎて、それなしではその作業が前進する必要があると結論付けました。
The other significant change to the protocols themselves is that the SMTPUTF8 keyword is now required as an SMTP client announcement if the extension is needed; in the experimental version, only the server announcement that an extended envelope and/or content were permitted was necessary.
プロトコル自体の他の重要な変更は、拡張機能が必要な場合、SMTPPITF8キーワードがSMTPクライアントの発表として必要になることです。実験バージョンでは、拡張エンベロープおよび/またはコンテンツが許可されたサーバーの発表のみが必要でした。
An SMTP extension, "SMTPUTF8", is specified as follows:
SMTP拡張機能「SMTPUTF8」は、次のように指定されています。
o Permits the use of UTF-8 strings in email addresses, both local parts and domain names.
o ローカルパーツとドメイン名の両方の電子メールアドレスでUTF-8文字列を使用することを許可します。
o Permits the selective use of UTF-8 strings in email message headers (see Section 7.2).
o 電子メールメッセージヘッダーでUTF-8文字列の選択的使用を許可します（セクション7.2を参照）。
o Requires that the server advertise the 8BITMIME extension [RFC6152] and that the client support 8-bit transmission so that header information can be transmitted without using a special content-transfer-encoding.
o サーバーが8Bitmime拡張機能[RFC6152]を宣伝し、クライアントが8ビット伝送をサポートして、特別なコンテンツ転送エンコードを使用せずにヘッダー情報を送信できるようにする必要があります。
Some general principles affect the development decisions underlying this work.
いくつかの一般原則は、この作業の根底にある開発決定に影響します。
1. Email addresses enter subsystems (such as a user interface) that may perform charset conversions or other encoding changes. When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to
1. 電子メールアドレスは、チャーセット変換またはその他のエンコード変更を実行できるサブシステム（ユーザーインターフェイスなど）を入力します。アドレスのローカル部分にASCII文字のレパートリー以外の文字が含まれている場合、ドメイン部分のASCII互換エンコード（ACE）[RFC3492] [RFC5890]の使用は、
promote consistent processing of characters throughout the address.
アドレス全体の文字の一貫した処理を促進します。
2. An SMTP relay MUST
2. SMTPリレーは必要です
* Either recognize the format explicitly, agreeing to do so via an ESMTP option, or
* フォーマットを明示的に認識するか、ESMTPオプションを介してそうすることに同意するか、
* Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan.
* メッセージを拒否するか、必要に応じて、送信者が別の計画を立てることができるように、非配信通知メッセージを返します。
3. If the message cannot be forwarded because the next-hop system cannot accept the extension, it MUST be rejected or a non-delivery message MUST be generated and sent.
3. 次のホップシステムが拡張機能を受け入れることができないためにメッセージを転送できない場合、拒否される必要があります。または、配送のないメッセージを生成して送信する必要があります。
4. In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and message headers being transmitted over the Internet. There is no practical way to identify multiple charsets properly with an extension similar to this without introducing great complexity.
4. 相互運用性のために、UTF-8以外の充電器は、インターネットを介して送信されるメールアドレスとメッセージヘッダーで禁止されています。大きな複雑さを導入することなく、これと同様の拡張機能を使用して複数の充電器を適切に識別する実用的な方法はありません。
Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP extension specification and the UTF-8 header specification. If the system implements IMAP or POP, it MUST conform to the internationalized IMAP [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications respectively.
電子メールトランスポートと配信のためにここで指定された標準のグループへの適合には、SMTP拡張仕様とUTF-8ヘッダー仕様の実装が必要です。システムがIMAPまたはPOPを実装する場合、それぞれ国際化されたIMAP [RFC5738BIS-IMAP]またはPOP [RFC5721BIS-POP3]仕様に適合する必要があります。
There are many places in MUAs or in a user presentation in which email addresses or domain names appear. Examples include the conventional "From:", "To:", or "Cc:" header fields; "Message-ID:" and "In-Reply-To:" header fields that normally contain domain names (but that may be a special case); and in message bodies. Each of these must be examined from an internationalization perspective. The user will expect to see mailbox and domain names in local characters, and to see them consistently. If non-obvious encodings, such as protocol-specific ACE variants, are used, the user will inevitably, if only occasionally, see them rather than "native" characters and will find that discomfiting or astonishing. Similarly, if different codings are used for mail transport and message bodies, the user is particularly likely to be surprised, if only as a consequence of the long-established "things leak" principle. The only practical way to avoid these sources of discomfort, in both the medium and the longer term, is to have the encodings used in transport be as similar to the encodings used in message headers and message bodies as possible.
MUASや、メールアドレスまたはドメイン名が表示されるユーザープレゼンテーションには多くの場所があります。例には、従来の「from： "、" to： "、または" cc： "ヘッダーフィールドが含まれます。 「Message-ID：」と「In-Reply-to：」ヘッダーフィールドは、通常ドメイン名を含む（ただし、特別なケースかもしれません）。そしてメッセージ本文で。これらのそれぞれは、国際化の観点から検討する必要があります。ユーザーは、ローカル文字のメールボックスとドメイン名を表示し、一貫して表示することを期待します。プロトコル固有のACEバリアントなどの非自明なエンコーディングが使用されている場合、ユーザーは必然的に、「ネイティブ」文字ではなくそれらを見ることがあり、その識別または驚くべきことに気付くでしょう。同様に、メールトランスポートやメッセージボディに異なるコーディングが使用されている場合、ユーザーは、長年にわたって確立されていた「漏れ」の原則の結果としてのみ、特に驚かされる可能性があります。これらの不快感の原因を中期と長期の両方で回避する唯一の実用的な方法は、輸送で使用されるエンコーディングを、メッセージヘッダーとメッセージ本文で可能な限り使用するエンコーディングに似ていることです。
When email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in the fully internationalized form. That form SHOULD use UTF-8 rather than ASCII as the base character set for the contents of header fields (protocol elements such as the header field names themselves are unchanged and remain entirely in ASCII). For transition purposes and compatibility with legacy systems, this can be done by extending the traditional MIME encoding models for non-ASCII characters in headers [RFC2045] [RFC2231], but even these should be based on UTF-8, rather than other encodings, if at all possible [RFC6055]. However, the target is fully internationalized message headers, as discussed in [RFC6532] and not an extended and painful transition.
電子メールのローカルパーツが国際化される場合、メッセージヘッダーが完全に国際化された形式になるように手配する必要があります。そのフォームは、ヘッダーフィールドの内容のベース文字セットとしてASCIIではなくUTF-8を使用する必要があります（ヘッダーフィールド名自体などのプロトコル要素は変更されず、完全にASCIIにとどまります）。レガシーシステムとの移行目的と互換性のために、これはヘッダー[RFC2045] [RFC2231]の非ASCII文字の従来のMIMEエンコードモデルを拡張することで実行できますが、これらは他のエンコーディングではなくUTF-8に基づく必要があります。可能であれば[RFC6055]。ただし、[RFC6532]で説明されているように、ターゲットは完全に国際化されたメッセージヘッダーであり、拡張された痛みを伴う移行ではありません。
The existing Delivery Status Notifications (DSNs) specification [RFC3461], which is a Draft Standard, is limited to ASCII text in the machine-readable portions of the protocol. "International Delivery and Disposition Notifications" [RFC6533] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the SMTPUTF8 and the DSN extension, that server MUST implement internationalized DSNs including support for the ORCPT parameter specified in RFC 3461 [RFC3461].
ドラフト標準である既存の配信ステータス通知（DSNS）仕様[RFC3461]は、プロトコルの機械可読部分のASCIIテキストに限定されています。「国際配信と気質の通知」[RFC6533]は、国際的な電子メールアドレスの新しいアドレスタイプを追加するため、格下げ後でもASSASCII文字を持つ元の受信者アドレスを正しく保存できます。SMTPサーバーがSMTPUTF8とDSN拡張機能の両方を宣伝する場合、そのサーバーはRFC 3461 [RFC3461]で指定されたORCPTパラメーターのサポートを含む国際化されたDSNを実装する必要があります。
An important issue with these extensions is how to handle interactions between systems that support non-ASCII addresses and legacy systems that expect ASCII. There is, of course, no problem with ASCII-only systems sending to those that can handle internationalized forms because the ASCII forms are just a proper subset. But, when systems that support these extensions send mail, they MAY include non-ASCII addresses for senders, receivers, or both and might also provide non-ASCII header information other than addresses. If the extension is not supported by the first-hop system (i.e., the SMTP server accessed by the submission server acting as an SMTP client), message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form, possibly using encoded words [RFC2047] in the message headers. Of course, such transformations imply that the originating user or system must have ASCII-only addresses available for all senders and recipients. Mechanisms by which such addresses may be found or identified are outside the scope
これらの拡張機能の重要な問題は、ASCIIを期待する非ASCIIアドレスとレガシーシステムをサポートするシステム間の相互作用を処理する方法です。もちろん、ASCIIフォームは単なる適切なサブセットであるため、国際化されたフォームを処理できるASCII-ONLYシステムには問題ありません。ただし、これらの拡張機能をサポートするシステムがメールを送信する場合、送信者、受信機、またはその両方の非ASCIIアドレスを含めることができ、アドレス以外の非ASCIIヘッダー情報を提供する場合があります。拡張機能がファーストホップシステム（つまり、SMTPクライアントとして機能する提出サーバーがアクセスするSMTPサーバー）によってサポートされていない場合、メッセージを発行するシステムは、従来の封筒とメッセージヘッダーを送信するか、メッセージを返すように準備する必要があります。メッセージがメッセージヘッダーにエンコードされた単語[RFC2047]を使用して、メッセージが従来のフォームに手動で格下げされるように発信するユーザーに。もちろん、そのような変換は、すべての送信者と受信者が利用できるASCIIアドレスを発信する必要があることを意味します。そのようなアドレスが見つかったり特定されたりするメカニズムは範囲外です
of these specifications as are decisions about the design of originating systems such as whether any required transformations are made by the user, the originating MUA, or the submission server.
これらの仕様のうち、必要な変換がユーザー、発信元のMUA、または提出サーバーによって行われるかどうかなどの発信システムの設計に関する決定。
A somewhat more complex situation arises when the first-hop system supports these extensions but some subsequent server in the SMTP transmission chain does not. It is important to note that most cases of that situation with forward-pointing addresses will be the result of configuration errors: especially if it hosts non-ASCII addresses, a final delivery MTA that accepts these extensions SHOULD NOT be configured with lower-preference MX hosts that do not. When the only non-ASCII address being transmitted is backward-pointing (e.g., in an SMTP MAIL command), recipient configuration cannot help in general. On the other hand, alternate, all-ASCII addresses for senders are those most likely to be authoritatively known by the submission environment or the sender herself. Consequently, if an intermediate SMTP relay that requires these extensions then discovers that the next system in the chain does not support them, it will have little choice other than to reject or return the message.
ファーストホップシステムがこれらの拡張機能をサポートしている場合、やや複雑な状況が発生しますが、SMTP伝送チェーンの後続のサーバーはそうではありません。フォワードポイントアドレスを持つその状況のほとんどのケースは、構成エラーの結果であることに注意することが重要です。特に、非ASCIIアドレスをホストする場合、これらの拡張機能を受け入れる最終配信MTAは、より低いプレファレンスMXで構成されてはなりません。そうでないホスト。送信されているASCII以外の唯一のアドレスが後方指定である場合（たとえば、SMTPメールコマンドで）、受信者の構成は一般的には役立ちません。一方、送信者の代替のすべてのASCIIアドレスは、提出環境または送信者自身によって権威をもって知られている可能性が最も高いものです。その結果、これらの拡張機能を必要とする中間SMTPリレーがチェーン内の次のシステムがそれらをサポートしていないことを発見した場合、メッセージを拒否または返す以外に選択肢はほとんどありません。
As discussed above, downgrading to an ASCII-only form may occur before or during the initial message submission. It might also occur after the delivery to the final delivery MTA in order to accommodate message stores, IMAP or POP servers, or clients that have different capabilities than the delivery MTA. These cases are discussed in the subsections below.
上記で説明したように、最初のメッセージの提出の前または最初に、Ascii-Onlyフォームへのダウングレードが発生する場合があります。また、メッセージストア、IMAPまたはPOPサーバー、または配信MTAとは異なる機能を持つクライアントに対応するために、最終配信MTAへの配信後に発生する可能性があります。これらのケースについては、以下のサブセクションで説明します。
The IETF has traditionally avoided specifying the precise behavior of MUAs to provide maximum flexibility in the associated user interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide latitude to MUAs and submission servers as to what might be supplied by the user as long as the result conforms with "on the wire" standards once it is injected into the public Internet. In that tradition, the discussion in the remainder of Section 8 is provided as general guidance rather than normative requirements.
IETFは、従来、MUAの正確な動作を指定して、関連するユーザーインターフェイスで最大の柔軟性を提供することを避けてきました。SMTP標準[RFC5321]、セクション6.4は、結果が公開インターネットに注入されると「ワイヤー」標準に準拠している限り、ユーザーが提供できるものについて、MUASおよび提出サーバーに幅広い緯度を提供します。その伝統において、セクション8の残りの残りの議論は、規範的要件ではなく一般的なガイダンスとして提供されます。
Messages that require these extensions will sometimes be transferred to a system that does not support these extensions; it is likely that the most common cases will involve the combination of ASCII-only forward-pointing addresses with a non-ASCII backward-pointing one. Until the extensions described here have been universally implemented in the Internet email environment, senders who prefer to use non-ASCII addresses (or raw UTF-8 characters in header fields), even when their intended recipients use and expect all-ASCII ones, will need to be especially careful about the error conditions that can arise. The
これらの拡張機能を必要とするメッセージは、これらの拡張機能をサポートしないシステムに転送される場合があります。最も一般的なケースには、ASCIIの順方向のアドレスと非ASCII後方ポイントのアドレスの組み合わせが含まれる可能性があります。ここで説明する拡張機能がインターネットメール環境で普遍的に実装されるまで、意図した受信者がすべてASCIIのアドレスを使用して期待する場合でも、非ASCIIアドレス（またはヘッダーフィールドでRAW UTF-8文字）を使用することを好む送信者は発生する可能性のあるエラー条件に特に注意する必要があります。
risks are especially great in environments in which non-delivery messages (or other indications from submission servers) are routinely dropped or ignored.
リスクは、非配信メッセージ（または提出サーバーからのその他の適応）が日常的に削除または無視される環境で特に優れています。
Perhaps obviously, the most convenient time to find an ASCII address corresponding to an internationalized address is at the originating MUA or closely associated systems. This can occur either before the message is sent or after the internationalized form of the message is rejected. It is also the most convenient time to convert a message from the internationalized form into conventional ASCII form or to generate a non-delivery message to the sender if either is necessary. At that point, the user has a full range of choices available, including changing backward-pointing addresses, contacting the intended recipient out of band for an alternate address, consulting appropriate directories, arranging for translation of both addresses and message content into a different language, and so on. While it is natural to think of message downgrading as optimally being a fully automated process, we should not underestimate the capabilities of a user of at least moderate intelligence who wishes to communicate with another such user.
おそらく明らかに、国際化されたアドレスに対応するASCIIアドレスを見つける最も便利な時間は、発生するMUAまたは密接に関連するシステムです。これは、メッセージが送信される前に、またはメッセージの国際化された形式が拒否された後に発生する可能性があります。また、国際化されたフォームからのメッセージを従来のASCIIフォームに変換したり、いずれかが必要な場合に送信者に非配信メッセージを生成する最も便利な時間です。その時点で、ユーザーは、後方ポイントアドレスの変更、代替アドレスのバンドからの意図した受信者に連絡し、適切なディレクトリに相談し、アドレスとメッセージコンテンツの両方の翻訳を別の言語に並べるなど、さまざまな選択肢を利用できます。 、 等々。メッセージのダウングレードが完全に自動化されたプロセスであると考えるのは自然なことですが、他のユーザーと通信したい少なくとも中程度のインテリジェンスのユーザーの機能を過小評価するべきではありません。
In this context, one can easily imagine modifications to message submission servers (as described in RFC 6409 [RFC6409]) so that they would perform downgrading operations or perhaps even upgrading ones. Such operations would permit receiving messages with one or more of the internationalization extensions discussed here and adapting the outgoing message, as needed, to respond to the delivery or next-hop environment the submission server encounters.
これに関連して、送信サーバーへの変更（RFC 6409 [RFC6409]に記載されているように）の変更を簡単に想像できます。そのため、格下げ操作やおそらくアップグレードされた操作を実行できます。このような操作は、ここで説明されている1つ以上の国際化拡張機能でメッセージを受信し、必要に応じて送信メッセージを配信または次のホップ環境に応答するために、送信サーバーの環境に応答することができます。
When an email message is received by a final delivery MTA, it is usually stored in some form. Then it is retrieved either by software that reads the stored form directly or by client software via some email retrieval mechanisms such as POP or IMAP.
最終配信MTAによって電子メールメッセージが受信されると、通常は何らかの形で保存されます。次に、POPやIMAPなどの電子メール検索メカニズムを介して、保存されたフォームを直接読み取るソフトウェアまたはクライアントソフトウェアによって取得されます。
The SMTP extension described in Section 7.1 provides protection only in transport. It does not prevent MUAs and email retrieval mechanisms that have not been upgraded to understand internationalized addresses and UTF-8 message headers from accessing stored internationalized emails.
セクション7.1で説明されているSMTP拡張は、輸送においてのみ保護を提供します。国際化された住所とUTF-8メッセージヘッダーが保存された国際化された電子メールにアクセスすることを理解するためにアップグレードされていないMUASおよび電子メール検索メカニズムを妨げません。
Since the final delivery MTA (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY downgrade internationalized emails, specially identify messages that utilize these extensions, or both. If either or both of these actions were to be taken, the final
最終配信MTA（または、より具体的には、対応するメールストレージエージェント）は、電子メールストレージにアクセスするエージェントがここで提案されている拡張機能を常に処理できると安全に想定することはできません。拡張機能、またはその両方。これらのアクションのいずれかまたは両方が実行される場合、ファイナル
delivery MTA SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss. Preservation of that information is necessary to support access by SMTPUTF8-aware agents.
配信MTAには、情報の損失なしに元の国際化されたフォームを保存または回復するメカニズムを含める必要があります。その情報の保存は、SMTPUTF8対応エージェントによるアクセスをサポートするために必要です。
The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address". This is not a new requirement; equivalent statements appeared in specifications in 2001 [RFC2821] and even in 1989 [RFC1123].
ベースSMTP仕様（RFC 5321 [RFC5321]のセクション2.3.11）は、「中間ホストが輸送を変更して輸送を最適化しようとした場合の問題の長い歴史のために、ローカルパートを解釈および割り当てる必要があると述べています。アドレスのドメイン部分で指定されたホスト」。これは新しい要件ではありません。同等のステートメントは、2001年[RFC2821]および1989年[RFC1123]の仕様に登場しました。
Adherence to this rule means that a downgrade mechanism that transforms the local part of an email address cannot be utilized in transit. It can only be applied at the endpoints, specifically by the MUA or submission server or by the final delivery MTA.
この規則の順守とは、電子メールアドレスのローカル部分を変換するダウングレードメカニズムを輸送中に利用できないことを意味します。特にMUAまたは提出サーバー、または最終配信MTAによって、エンドポイントでのみ適用できます。
One of the reasons for this rule has to do with legacy email systems that embed mail routing information in the local part of the address field. Transforming the email address destroys such routing information. There is no way a server other than the final delivery server can know, for example, whether the local part of user%foo@example.com is a route ("user" is reached via "foo") or simply a local address.
このルールの理由の1つは、アドレスフィールドのローカル部分にメールルーティング情報を埋め込むレガシーメールシステムに関係しています。メールアドレスを変換すると、そのようなルーティング情報が破壊されます。たとえば、user%foo@example.comのローカル部分がルート（「ユーザー」に「foo」を介して「ユーザー」に到達する）か、単にローカルアドレスであるかどうかなど、最終配信サーバー以外のサーバーが知る方法はありません。
Internationalization of addresses and message headers, especially in combination with variations on character coding that are inherent to Unicode, may make careful choices of addresses and careful configuration of servers and DNS records even more important than they are for traditional Internet email. It is likely that, as experience develops with the use of these protocols, it will be desirable to produce one or more additional documents that offer guidance for configuration and interfaces. A document that discusses issues with MUAs, especially with regard to downgrading, is expected to be developed. The subsections below address some other issues.
特にUnicodeに固有の文字コーディングのバリエーションと組み合わせて、住所とメッセージヘッダーの国際化は、住所の慎重な選択とサーバーとDNSレコードの慎重な構成を、従来のインターネットメールよりもさらに重要にすることができます。これらのプロトコルを使用して経験が発展するにつれて、構成とインターフェイスのガイダンスを提供する1つ以上の追加のドキュメントを作成することが望ましい可能性があります。特に格下げに関して、MUAとの問題について説明するドキュメントが開発される予定です。以下のサブセクションは、他のいくつかの問題に対処しています。
It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice, if one actually intends the mailboxes to be accessible to a broad range of senders. The most often cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These
メールボックスが幅広い送信者が実際にアクセスできることを実際に意図している場合、電子メールの構文は、実際には賢明ではないメールボックス名に関する選択を許可することが長い間そうでした。最も頻繁に引用されている例には、ケース感受性の使用と、メールボックスのローカルパーツに埋め込まれた文字のトリッキーな引用が含まれます。これらは
deliberately unusual constructions are permitted by the protocols, and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity.
意図的に異常な構造はプロトコルによって許可されており、サーバーはそれらをサポートすることが期待されています。彼らは特別なケースで価値を提供することができますが、それらを利用することは、あいまいさによって何らかの形のセキュリティを作成することでない限り、ほとんど常に悪い習慣です。
In the absence of these extensions, SMTP clients and servers are constrained to using only those addresses permitted by RFC 5321. The local parts of those addresses MAY be made up of any ASCII characters except the control characters that RFC 5321 prohibits, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 because it requires a backspace character (a prohibited C0 control). Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of this character in ASCII mailbox names and it is even more problematic (for canonicalization and normalization reasons) in non-ASCII strings, backspace MUST NOT appear in SMTPUTF8 mailbox names.
これらの拡張機能がない場合、SMTPクライアントとサーバーは、RFC 5321によって許可されているアドレスのみを使用するように制約されています。これらのアドレスのローカル部分は、RFC 5321が禁止するコントロール文字を除くASCII文字で構成されている場合がありますが、それらの一部はそれらの一部ですが、そこに指定されているように引用する必要があります。国際化の文脈では、引用された文字列内のオーバーストラックASCIIキャラクター（キャラクター、バックスペース、および別の文字）を使用して、ASCII以外の文字を近似するシステムを使用するシステムに長い歴史があることが注目に値します。この形式の国際化は、RFC 821 [RFC0821]によって許可されましたが、バックスペース文字（禁止されているC0コントロール）が必要なため、RFC 5321によって禁止されています。RFC 5321（およびその前身であるRFC 2821）は、ASCIIメールボックス名でのこのキャラクターの使用を禁止しており、非ASCII文字列ではさらに問題があるため、Backspaceはsmtputf8メールボックス名に表示されてはなりません。
For the particular case of mailbox names that contain non-ASCII characters in the local part, domain part, or both, special attention MUST be paid to Unicode normalization [Unicode-UAX15], in part because Unicode strings may be normalized by other processes independent of what a mail protocol specifies (this is exactly analogous to what may happen with quoting and dequoting in traditional addresses). Consequently, the following principles are offered as advice to those who are selecting names for mailboxes:
ローカル部分、ドメイン部分、またはその両方にASCII以外の文字を含むメールボックス名の特定のケースの場合、Unicode文字列は他のプロセスが独立して正規化される可能性があるため、Unicode正規化[Unicode-Uax15]に特別な注意を払う必要があります。メールプロトコルが指定しているものの（これは、従来のアドレスで引用して不引払いすることで起こる可能性があることにまったく類似しています）。その結果、メールボックスの名前を選択している人へのアドバイスとして、次の原則が提供されます。
o In general, it is wise to support addresses in Normalized form, using at least Normalization Form NFC. Except in circumstances in which NFKC would map characters together that the parties responsible for the destination mail server would prefer to be kept distinguishable, supporting the NFKC-conformant form would yield even more predictable behavior for the typical user.
o 一般に、少なくとも正規化フォームNFCを使用して、正規化された形式でアドレスをサポートすることが賢明です。NFKCが宛先メールサーバーを担当する当事者が区別可能に保つことを好むという文字をマッピングする状況を除き、NFKC準拠のフォームをサポートすると、一般的なユーザーにとってさらに予測可能な動作が得られます。
o It will usually be wise to support other forms of the same local-part string, either as aliases or by normalization of strings reaching the delivery server: the sender should not be depended upon to send the strings in normalized form.
o 通常、エイリアスとして、または配信サーバーに到達する文字列の正規化により、同じローカルパート文字列の他の形式をサポートすることが賢明です。送信者は、弦を正規化された形式で送信するために依存してはなりません。
o Stated differently and in more specific terms, the rules of the protocol for local-part strings essentially provide that:
o 異なる方法で、より具体的な用語で、ローカルパート文字列のプロトコルのルールは、本質的にそれを提供します。
* Unnormalized strings are valid, but sufficiently bad practice that they may not work reliably on a global basis. Servers should not depend on clients to send normalized forms but should be aware that procedures on client machines outside the control of the MUA may cause normalized strings to be sent regardless of user intent.
* 非正規化された文字列は有効ですが、グローバルベースで確実に機能しない可能性があるため、十分に悪い実践です。サーバーは、正規化されたフォームを送信するためにクライアントに依存してはなりませんが、MUAの制御外のクライアントマシンの手順により、ユーザーの意図に関係なく正規化された文字列が送信される可能性があることに注意する必要があります。
* C0 (and presumably C1) controls (see The Unicode Standard [Unicode]) are prohibited, the first in RFC 5321 and the second by an obvious extension from it [RFC5198].
* C0（およびおそらくC1）コントロール（Unicode標準[Unicode]を参照）は禁止されており、1つ目はRFC 5321で、2番目は明らかな拡張[RFC5198]によって禁止されています。
* Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and SMTP receiver code is required to handle them without severe errors (even if such strings are not accepted in addresses to be delivered on that server), but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems.
* 他の種類の句読点、スペースなどは、危険な練習です。おそらくそれらは機能し、SMTPレシーバーコードは、重大なエラーなしでそれらを処理するために必要です（そのような文字列がそのサーバーで配信されるアドレスで受け入れられていなくても）が、選択されたメールボックス名でそれらに依存関係を作成するのは悪いです実践し、相互運用性の問題につながる可能性があります。
This section identifies issues that are not covered, or not covered comprehensively, as part of this set of specifications, but that will require ongoing review as part of deployment of email address and header internationalization.
このセクションでは、この一連の仕様の一部としてカバーされていない、または包括的にカバーされていない問題を特定しますが、メールアドレスとヘッダー国際化の展開の一環として継続的なレビューが必要になります。
The mailto: schema [RFC6068], and the discussion of it in the Internationalized Resource Identifier (IRI) specification [RFC3987], may need to be modified when this work is completed and standardized.
Mailto：Schema [RFC6068]、および国際化されたリソース識別子（IRI）仕様[RFC3987]での議論は、この作業が完了して標準化されたときに変更する必要がある場合があります。
There are a number of places in contemporary Internet usage in which email addresses are used as identifiers for individuals, including as identifiers to Web servers supporting some electronic commerce sites and in some X.509 certificates [RFC5280]. These documents do not address those uses, but it is reasonable to expect that some difficulties will be encountered when internationalized addresses are first used in those contexts, many of which cannot even handle the full range of addresses permitted today.
現代のインターネット使用量には、電子商取引サイトをサポートするWebサーバーの識別子およびいくつかのX.509証明書[RFC5280]を含む、個人の識別子として電子メールアドレスが使用される多くの場所があります。これらのドキュメントはこれらの使用に対処していませんが、国際化されたアドレスが最初にこれらのコンテキストで使用される場合にいくつかの困難が発生することを期待するのは合理的です。
One particular characteristic of the email format is its persistency: MUAs are expected to handle messages that were originally sent decades ago and not just those delivered seconds ago. As such, MUAs and mail filtering software, such as that specified in Sieve [RFC5228], will need to continue to accept and decode header fields that use the "encoded word" mechanism [RFC2047] to accommodate non-ASCII characters in some header fields. While extensions to both POP3 [RFC1939] and IMAP [RFC3501] have been defined that include automatic upgrading of messages that carry non-ASCII information in encoded form -- including RFC 2047 decoding -- of messages by the POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are message structures and MIME content-types for which that cannot be done or where the change would have unacceptable side effects.
電子メール形式の特定の特性の1つは、その持続性です。MUAは、数十年前に送信されたメッセージだけでなく、数秒前に配信されたメッセージだけでなく、メッセージを処理することが期待されています。そのため、Sieve [RFC5228]で指定されているようなMUASおよびメールフィルタリングソフトウェアは、「エンコードされた単語」メカニズム[RFC2047]を使用して、一部のヘッダーフィールドの非ASCII文字に対応するヘッダーフィールドを引き続きデコードする必要があります。。一方、POP3 [RFC1939]とIMAP [RFC3501]の両方への拡張機能は、POP3 [RFC5721BIS-POP3]または「RFC5721BIS-POP3]または「RFC 2047デコードを含むエンコードされていないフォーム」で非ASCII情報を運ぶメッセージの自動アップグレードを含む定義が定義されています。IMAP [RFC5738BIS-IMAP]サーバーには、メッセージ構造とMIMEコンテンツタイプができない、または変更が容認できない副作用がある場所があります。
For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot be upgraded from the RFC 2047 form to normal UTF-8 characters without breaking the signature. Similarly, message parts that are encrypted may contain, when decrypted, header fields that use the RFC 2047 encoding; such messages cannot be 'fully' upgraded without access to cryptographic keys.
たとえば、S/MIME [RFC5751]またはかなり良いプライバシー（PGP）[RFC3156]を使用して、暗号化された署名されたメッセージパーツは、署名を破ることなくRFC 2047フォームから通常のUTF-8文字にアップグレードすることはできません。同様に、暗号化されたメッセージパーツには、RFC 2047エンコーディングを使用するヘッダーフィールドが含まれる場合があります。このようなメッセージは、暗号化キーにアクセスせずに「完全に」アップグレードすることはできません。
Similar issues may arise if messages are signed and then subsequently downgraded, e.g., as discussed in Section 8.1, and then an attempt is made to upgrade them to the original form and then verify the signatures. Even the very subtle changes that may result from algorithms to downgrade and then upgrade again may be sufficient to invalidate the signatures if they impact either the primary or MIME body part headers. When signatures are present, downgrading must be performed with extreme care if at all.
メッセージに署名されてから、セクション8.1で説明したように、その後格下げされた場合、同様の問題が発生する可能性があります。その後、元のフォームにアップグレードしてから署名を確認する試みが行われます。アルゴリズムがダウングレードしてから再びアップグレードすることから生じる可能性のある非常に微妙な変更でさえ、プライマリまたはMIMEボディパーツヘッダーのいずれかに影響を与える場合、署名を無効にするのに十分な場合があります。署名が存在する場合、格下げは非常に注意して実行する必要があります。
Local parts are sometimes used to construct domain labels, e.g., the local part "user" in the address user@domain.example could be converted into a host name user.domain.example with its Web space at <http://user.domain.example> and the catch-all addresses any.thing.goes@user.domain.example.
ローカルパーツは、ドメインラベルを構築するために使用される場合があります。たとえば、アドレスのローカルパーツ「ユーザー」は、user@domain.exampleのローカルパーツ「ユーザー」をホスト名user.domain.exampleに変換することができます。domain.example>およびCatch-allはany.thing.goes@user.domain.exampleをアドレスします。
Such schemes are obviously limited by, among other things, the SMTP rules for domain names, and will not work without further restrictions for other local parts. Whether those limitations are relevant to these specifications is an open question. It may be simply another case of the considerable flexibility accorded to delivery MTAs in determining the mailbox names they will accept and how they are interpreted.
このようなスキームは、とりわけドメイン名のSMTPルールによって明らかに制限されており、他のローカルパーツのさらなる制限なしには機能しません。これらの制限がこれらの仕様に関連するかどうかは、未解決の問題です。それは、彼らが受け入れるメールボックス名とそれらがどのように解釈されるかを決定する際に、配信MTAに与えられたかなりの柔軟性の単なる別のケースかもしれません。
Some applications use formats similar to the application/mbox format [RFC4155] instead of the message/digest form defined in RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as single units. Insofar as such applications assume that all stored messages use the message/rfc822 format described in RFC 2046, Section 5.2.1 [RFC2046] with ASCII message headers, they are not ready for the extensions specified in this series of documents, and special measures may be needed to properly detect and process them.
一部のアプリケーションは、RFC 2046、セクション5.1.5 [RFC2046]で定義されたメッセージ/ダイジェストフォームの代わりに、アプリケーション/Mbox形式[RFC4155]と同様の形式を使用して、複数のメッセージを単一ユニットとして転送します。そのようなアプリケーションは、すべての保存されたメッセージがRFC 2046、セクション5.2.1 [RFC2046]で説明されているメッセージ/RFC822形式をASCIIメッセージヘッダーで使用していると想定している場合、この一連のドキュメントで指定された拡張機能の準備ができていません。それらを適切に検出して処理するために必要です。
The original framework for internationalized email addresses and headers was described in RFC 4952 and a subsequent set of experimental protocol documents. Those relationships are described in Section 3. The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading. Those mechanisms included the definition of syntax and functions to support passing alternate, all-ASCII addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. Those features were eliminated after experimentation indicated that they were more complex and less necessary than had been assumed earlier. Those issues are described in more detail in Sections 6 and 9.
国際化された電子メールアドレスとヘッダーの元のフレームワークは、RFC 4952とその後の実験的プロトコルドキュメントのセットで説明されています。これらの関係はセクション3で説明されています。実験仕様とこの新しいセットの重要なアーキテクチャの違いは、以前の仕様が輸送中の格下げをサポートしていたことです。これらのメカニズムには、構文と機能の定義が含まれており、非ASCIIアドレスと非ASCIIアドレスと、メッセージの格下げステータスを示す特別なヘッダーと同様に、ASCIIアドレスがあります。これらの機能は、実験により、以前に想定されていたよりも複雑で必要ではないことが示された後に排除されました。これらの問題については、セクション6および9で詳しく説明します。
Any expansion of permitted characters and encoding forms in email addresses raises some risks. There have been discussions on so called "IDN-spoofing" or "IDN homograph attacks". These attacks allow an attacker (or "phisher") to spoof the domain or URLs of businesses or other entities. The same kind of attack is also possible on the local part of internationalized email addresses. It should be noted that the proposed fix involving forcing all displayed elements into normalized lowercase works for domain names in URLs, but not for email local parts since those are case sensitive.
許可された文字の拡張と電子メールアドレスでのエンコードフォームは、いくつかのリスクを引き起こします。いわゆる「IDNスプーフィング」または「IDNホモグラフ攻撃」に関する議論がありました。これらの攻撃により、攻撃者（または「Phisher」）が企業や他のエンティティのドメインまたはURLを押し付けることができます。国際化された電子メールアドレスのローカル部分でも同じ種類の攻撃が可能です。表示されたすべての要素をURLのドメイン名の正規化された小文字に強制することを含む提案された修正は、電子メールのローカルパーツではないことに注意してください。
Since email addresses are often transcribed from business cards and notes on paper, they are subject to problems arising from confusable characters (see [RFC4690]). These problems are somewhat reduced if the domain associated with the mailbox is unambiguous and supports a relatively small number of mailboxes whose names follow local system conventions. They are increased with very large mail systems in which users can freely select their own addresses.
電子メールアドレスは多くの場合、名刺から紙の上にメモから転写されるため、混乱しやすい文字から生じる問題の対象となります（[RFC4690]を参照）。メールボックスに関連付けられているドメインが明確であり、名前がローカルシステムの規則に従う比較的少数のメールボックスをサポートしている場合、これらの問題はいくらか減少します。ユーザーが独自のアドレスを自由に選択できる非常に大きなメールシステムで増加します。
The internationalization of email addresses and message headers must not leave the Internet less secure than it is without the required extensions. The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues.
電子メールアドレスとメッセージヘッダーの国際化は、必要な拡張機能よりもインターネットの安全性を低くしてはなりません。この一連の仕様で文書化された要件とメカニズムは、一般に、新しいセキュリティの問題を提起しません。
They do require a review of issues associated with confusable characters -- a topic that is being explored thoroughly elsewhere (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other transformations. Normalization and other issues associated with transformations and standard forms are also part of the subject of work described elsewhere [RFC5198] [RFC5893] [RFC6055].
彼らは、混乱するキャラクターに関連する問題のレビューを必要とします - 他の場所で徹底的に調査されているトピック（例えば、RFC 4690 [RFC4690]を参照） - および潜在的に、RFC 3629で議論されているUTF-8正規化に関するいくつかの問題[RFC3629]、およびその他の変換。変換や標準形式に関連するその他の問題も、他の場所で説明されている作業の主題の一部です[RFC5198] [RFC5893] [RFC6055]。
Some issues specifically related to internationalized addresses and message headers are discussed in more detail in the other documents in this set. However, in particular, caution should be taken that any "downgrading" mechanism, or use of downgraded addresses, does not inappropriately assume authenticated bindings between the internationalized and ASCII addresses. This potential problem can be mitigated somewhat by enforcing the expectation that most or all such transformations will be performed prior to final delivery by systems that are presumed to be under the administrative control of the sending user (as opposed to being performed in transit by entities that are not under the administrative control of the sending user).
このセットの他のドキュメントでは、国際化された住所とメッセージヘッダーに特に関連するいくつかの問題について詳しく説明します。ただし、特に、「格下げ」メカニズム、または格下げされたアドレスの使用は、国際化されたアドレスとASCIIアドレス間の認証されたバインディングを不適切に想定しないことに注意する必要があります。この潜在的な問題は、送信ユーザーの管理管理下にあると推定されるシステムによる最終配信の前に、ほとんどまたはすべての変換が最終配信の前に実行されるという期待を強制することにより、多少軽減できます（（輸送中に実行されるのではなく、）送信ユーザーの管理管理下にありません）。
The new UTF-8 header and message formats might also raise, or aggravate, another known issue. If the model creates new forms of an 'invalid' or 'malformed' message, then a new email attack is created: in an effort to be robust, some or most agents will accept such messages and interpret them as if they were well-formed. If a filter interprets such a message differently than the MUA used by the recipient, then it may be possible to create a message that appears acceptable under the filter's interpretation but that should be rejected under the interpretation given to it by that MUA. Such attacks already have occurred for existing messages and encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of particular image types.
新しいUTF-8ヘッダーとメッセージ形式は、もう1つの既知の問題を提起または悪化させる可能性があります。モデルが「無効」または「不正な」メッセージの新しいフォームを作成する場合、新しい電子メール攻撃が作成されます。堅牢性を持たせるために、一部またはほとんどのエージェントはそのようなメッセージを受け入れ、それらをよく形成しているかのように解釈します。フィルターが受信者が使用したMUAとは異なる方法でそのようなメッセージを解釈する場合、フィルターの解釈の下で受け入れられるように見えるメッセージを作成することが可能かもしれませんが、そのMUAによって与えられた解釈の下で拒否されるべきです。このような攻撃は、既存のメッセージとエンコードレイヤー、たとえば無効なMIME構文、無効なHTMLマークアップ、および特定の画像タイプの無効なコーディングですでに発生しています。
In addition, email addresses are used in many contexts other than sending mail, such as for identifiers under various circumstances (see Section 11.2). Each of those contexts will need to be evaluated, in turn, to determine whether the use of non-ASCII forms is appropriate and what particular issues they raise.
さらに、メールアドレスは、さまざまな状況下で識別子など、メールを送信する以外の多くのコンテキストで使用されます（セクション11.2を参照）。これらのそれぞれのコンテキストは、非ASCIIフォームの使用が適切かどうか、どの特定の問題を提起するかを判断するために、順番に評価する必要があります。
This work will clearly affect any systems or mechanisms that are dependent on digital signatures or similar integrity protection for email message headers (see also the discussion in Section 11.3). Many conventional uses of PGP and S/MIME are not affected since they
この作業は、電子メールメッセージヘッダーのデジタル署名または同様の整合性保護に依存するシステムまたはメカニズムに明らかに影響します（セクション11.3の説明も参照）。PGPとS/MIMEの多くの従来の使用は、彼らが影響を受けていないので影響を受けません
are used to sign body parts but not message headers. On the other hand, the developing work on DomainKeys Identified Mail (DKIM) [RFC5863] will eventually need to consider this work, and vice versa: while this specification does not address or solve the issues raised by DKIM and other signed header mechanisms, the issues will have to be coordinated and resolved eventually if the two sets of protocols are to coexist. In addition, to the degree to which email addresses appear in PKI (Public Key Infrastructure) certificates [RFC5280], standards addressing such certificates will need to be upgraded to address these internationalized addresses. Those upgrades will need to address questions of spoofing by look-alikes of the addresses themselves.
メッセージヘッダーではなく、身体の部分に署名するために使用されます。一方、Domainkeysを特定した郵便物（DKIM）[RFC5863]の開発中の作業は、最終的にこの作業を検討する必要があり、その逆も同様です。2つのプロトコルが共存する場合、問題を調整して解決する必要があります。さらに、PKI（公開キーインフラストラクチャ）証明書[RFC5280]に電子メールアドレスが表示される程度には、これらの国際化されたアドレスにアドレス指定するために、そのような証明書にアドレス指定する標準をアップグレードする必要があります。これらのアップグレードは、アドレス自体の外観によってスプーフィングの質問に対処する必要があります。
This document is an update to, and derived from, RFC 4952. This document would have been impossible without the work and contributions acknowledged in it. The present document benefited significantly from discussions in the IETF EAI working group and elsewhere after RFC 4952 was published, especially discussions about the experimental versions of other documents in the internationalized email collection, and from RFC errata on RFC 4952 itself.
このドキュメントは、RFC 4952の更新であり、導き出されたものです。このドキュメントは、その中で認められている作業と貢献がなければ不可能でした。現在の文書は、RFC 4952が公開された後、IETF EAIワーキンググループおよびその他の場所での議論、特に国際化された電子メールコレクションの他の文書の実験バージョンに関する議論、およびRFC 4952自体のRFC Errataからの議論から大きな恩恵を受けました。
Special thanks are due to Ernie Dainow for careful reviews and suggested text in this version and to several IESG members for a careful review and specific suggestions.
慎重なレビューをしてくれたアーニー・デイノウと、このバージョンのテキストを提案したことと、慎重なレビューと具体的な提案については、いくつかのIESGメンバーに感謝します。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII] American National Standards Institute（以前のアメリカ合衆国標準研究所）、「米国情報インターチェンジのコード」、ANSI X3.4-1968、1968。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットで決定的なままです。
[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月。
[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月。
[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月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152] Klensin、J.、Freed、N.、Rose、M。、およびD. Crocker、「8ビットMIME輸送用SMTPサービス拡張」、STD 71、RFC 6152、2011年3月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.
[RFC6531] Yao、J。およびW. Mao、「国際化された電子メールアドレスのSMTP拡張」、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、「国際化されたメールヘッダー」、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、「国際化された配送状況と処分通知」、RFC 6533、2012年2月。
[POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, October 2011.
[Popimap-DownGrade] Fujiwara、K。、「国際化された電子メールメッセージの配送後のメッセージの格下げ」、2011年10月の作業。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[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月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、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月。
[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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R.、およびT. Roessler、「OpenPGPを使用したMime Security」、RFC 3156、2001年8月。
[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月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.
[RFC4155] Hall、E。、「アプリケーション/Mboxメディアタイプ」、RFC 4155、2005年9月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「国際化されたドメイン名（IDN）のレビューと推奨事項」、RFC 4690、2006年9月。
[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月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228] Guenther、P。およびT. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335] Yang、A。、「国際化されたメールヘッダー」、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月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504] Fujiwara、K。およびY. Youneya、「電子メールアドレス国際化の格下げメカニズム」、RFC 5504、2009年3月。
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.
[RFC5721] Gellens、R。およびC. Newman、「UTF-8のPOP3サポート」、RFC 5721、2010年2月。
[RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, November 2011.
[RFC5721BIS-POP3] Gellens、R.、Newman、C.、Yao、J。、およびK. Fujiwara、「UTF-8のPOP3サポート」、2011年11月の作業。
[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.
[RFC5738] Resnick、P。およびC. Newman、「UTF-8のIMAPサポート」、RFC 5738、2010年3月。
[RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, December 2011.
[RFC5738BIS-IMAP] Resnick、P.、ed。、Newman、C.、Ed。、およびS. Shen、ed。、「UTF-8のIMAPサポート」、2011年12月の作業。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.
[RFC5825] Fujiwara、K。およびB. Leiba、「電子メールアドレス国際化のためのダウングレードされたメッセージの表示」、RFC 5825、2010年4月。
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[RFC5863] Hansen、T.、Siegel、E.、Hallam-Baker、P。、およびD. Crocker、「Domainkeys Idified Mail（DKIM）開発、展開、および運用」、RFC 5863、2010年5月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、2010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892] Faltstrom、P。、「アプリケーションのユニコードコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、2010年8月。
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893] Alvestrand、H。およびC. Karp、「アプリケーションの国際化されたドメイン名（IDNA）の右から左へのスクリプト」、RFC 5893、2010年8月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：背景、説明、および根拠」、RFC 5894、2010年8月。
[RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.
[RFC5983] Gellens、R。、「メーリングリストと国際化されたメールアドレス」、RFC 5983、2010年10月。
[RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", Work in Progress, December 2011.
[RFC5983BIS-MailingList] Levine、J。およびR. Gellens、「メーリングリストとUTF-8アドレス」、2011年12月の作業。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055] Thaler、D.、Klensin、J。、およびS. Cheshire、「国際化されたドメイン名のエンコーディングに関するIABの考え」、RFC 6055、2011年2月。
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[RFC6068] Duerst、M.、Masinter、L。、およびJ. Zawinski、「The Mailto 'URIスキーム」、RFC 6068、2010年10月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、STD 72、RFC 6409、2011年11月。
[Unicode] The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined by:, "The Unicode Standard, Version 6.0.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6)., <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode] Unicodeコンソーシアム。Unicode Standard、バージョン6.0.0、次のとおりです。http://www.unicode.org/versions/unicode6.0.0/>。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, <http://www.unicode.org/reports/tr15/>.
[Unicode-uax15] Unicode Consortium、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2010年9月、<http://www.unicode.org/reports/tr15/>。
Authors' Addresses
著者のアドレス
John C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
YangWoo KO 112-202 Malgeunachim APT. Nae-dong Seo-gu, Daejeon 302-981 Republic of Korea
Yangwoo Ko 112-202 Malgeunachim apt。Nae-Dong Seo-gu、Daejeon 302-981韓国共和国
EMail: yangwooko@gmail.com