メインコンテンツまでスキップ

RFC 6530 - Overview and Framework for Internationalized Email (国際化電子メールの概要とフレームワーク)

  • ステータス: Proposed Standard
  • 発行日: February 2012
  • ストリーム: IETF
  • 廃止: RFC4952, RFC5504, RFC5825
  • エラッタ: エラッタなし

Document Information (ドキュメント情報)​

  • RFC Number: 6530
  • Title: Overview and Framework for Internationalized Email (国際化電子メールの概要とフレームワーク)
  • Authors: J. Klensin, Y. Ko
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 4952, RFC 5504, RFC 5825
  • ISSN: 2070-1721

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.

本文書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6530 で入手できます。

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2012 IETF Trust および文書の著者として特定された人物。All rights reserved.

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）の対象となります。これらの文書には、本文書に関するお客様の権利と制限が記載されていますので、注意深く確認してください。本文書から抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているとおり、保証なしで提供されます。

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トラストに付与していない可能性があります。当該資料の著作権を管理する人物から適切なライセンスを取得しない限り、本文書をIETF標準化プロセス以外で変更することはできず、RFCとして発行するためのフォーマットや英語以外の言語への翻訳を除き、IETF標準化プロセス以外でその派生著作物を作成することはできません。

Table of Contents (目次)​

  1. Introduction (はじめに)
  2. Role of This Specification (本仕様の役割)
  3. Problem Statement (問題提起)
  4. Terminology (用語)
  5. Overview of the Approach and Document Plan (アプローチの概要と文書計画)
  6. Review of Experimental Results (実験結果のレビュー)
  7. Overview of Protocol Extensions and Changes (プロトコル拡張と変更の概要)
  8. Downgrading before and after SMTP Transactions (SMTPトランザクション前後のダウングレード)
  9. Downgrading in Transit (転送中のダウングレード)
  10. User Interface and Configuration Issues (ユーザインターフェースと設定の問題)
  11. Additional Issues (その他の問題)
  12. Key Changes from the Experimental Protocols and Framework (実験的プロトコルおよびフレームワークからの主な変更点)
  13. Security Considerations (セキュリティに関する考慮事項)
  14. Acknowledgments (謝辞)
  15. References (参考文献)

1. Introduction (はじめに)​

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つの文書すべてをHistoric（歴史的）に移動するよう要請されています。

The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender.

代名詞「彼（he）」と「彼女（she）」は、性別が不特定の人を示すために互換的に使用されます。

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

本文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14, RFC 2119 [RFC2119] で説明されているように解釈されるものとします。

2. Role of This Specification (本仕様の役割)​

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

本文書は、電子メール国際化の次の段階へのアプローチに関する概要とフレームワークを提示します。この新しい段階では、アドレスとヘッダーフィールドの国際化だけでなく、関連する転送および配信モデルも必要となります。本仕様の以前のバージョンであるRFC 4952 [RFC4952] も、一連の実験的プロトコル [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] の導入を提供しました。この改訂版は、それらのプロトコルのサブセットの標準化過程の後継に関する概要と概念情報を提供します。文書の詳細とそれらの関係はセクション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] の用語と機能についての一般的な知識も前提とされています。

3. Problem Statement (問題提起)​

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

電子メールアドレスの国際化は、単にSMTPエンベロープを変更すること、あるいは "From:", "To:", "Cc:" ヘッダーフィールドを変更すること、あるいはアップグレードされたメールユーザエージェント（MUA）が特別なコーディングをデコードしてローカル文字を表示して応答することを許可することだけの問題ではありません。使用可能であると認識されるためには、アドレスは国際化され、それらが発生するすべてのコンテキストで一貫して処理される必要があります。この要件には広範な意味があります。パッチや回避策の集まりでは不十分です。たとえそれらが十分であったとしても、回避策ベースのアプローチは、異なるパッチや回避策のセットが適用されたさまざまな実装をもたらし、結果として実際に何が使用可能でサポートされているかについてユーザの混乱を招く可能性があります。代わりに、言語と表記体系を共有する人々の間での効率的な通信を許可することに焦点を当てた、完全に国際化された電子メール環境を構築する必要があります。これは、ひいては、適切に国際化されたヘッダーフィールドがUnicode文字の全範囲を利用できるようにするためのメールヘッダー環境の変更、UTF-8 [RFC3629] [RFC5198] メールアドレッシングとそれらの拡張ヘッダーフィールドの配信を許可するSMTP拡張、配信およびサービス通知の国際化のサポート [RFC3461] [RFC3464]、そして（最後に）ヘッダーフィールドにコンテンツ転送エンコーディングがないという制限を克服することなくこれらすべてをメールシステムを通じて転送できるようにするための8BITMIME SMTP拡張 [RFC6152] のサポート要件を意味します。

4. Terminology (用語)​

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] に文書化されているコア電子メール標準のプロトコルと用語について、ある程度の理解があることを前提としています。

4.1. Mail User and Mail Transfer Agents (メールユーザエージェントとメール転送エージェント)​

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転送または配信プロセスの一部ではありません。

4.2. Address Character Sets (アドレス文字セット)​

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.

本文書では、アドレス内のすべての文字がASCII文字レパートリー [ASCII] に含まれている場合、そのアドレスは「全ASCII」または単に「ASCIIアドレス」です。いずれかの文字がASCII文字レパートリーに含まれていない場合、そのアドレスは「非ASCII」または「i18nアドレス」です。そのようなアドレスは他の方法で制限される場合がありますが、それらの制限はこの定義には関係ありません。「全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つのセットの和集合です。

4.3. User Types (ユーザタイプ)​

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アドレスから、そのアドレスの所有者が国際化電子メールユーザであるかどうかを判断することはできないことに注意してください。（非ASCIIアドレスは、そのアドレスの所有者が国際化電子メールユーザであるという確信を意味します。）「国際化電子メールユーザメッセージ」というものは存在しません。この用語は、ユーザとそのエージェントおよび機能にのみ適用されます。特に、非ASCII、したがって推定上国際化されたメッセージコンテンツの使用は、MIME仕様 [RFC2045] の不可欠な部分であり、これらの拡張機能を必要としません（ただし、それらと互換性はあります）。

4.4. Messages (メッセージ)​

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人のユーザ（送信者）から、1人以上の他の受信者電子メールアドレス（単に「ユーザ」または「受信者ユーザ」と呼ばれることが多い）に送信されます。

4.5. Mailing Lists (メーリングリスト)​

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-MailingList] で説明されています。

4.6. Conventional Message and Internationalized Message (従来のメッセージと国際化メッセージ)​

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

  • 「従来のメッセージ」とは、この一連の仕様に含まれるSMTP拡張文書 [RFC6531] またはUTF8header文書 [RFC6532] で定義された拡張機能を使用せず、RFC 5322 [RFC5322] に厳密に準拠しているメッセージのことです。

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

  • 「国際化メッセージ」とは、この一連の仕様で定義された拡張機能の1つ以上を利用するメッセージのことであり、そのため、電子メールメッセージまたはその転送の従来の仕様にはもはや準拠していません。

4.7. Undeliverable Messages, Notification, and Delivery Receipts (配信不能メッセージ、通知、および配信確認)​

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つは、通常「拒否（Rejection）」と呼ばれ、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.

送信者はまた、メッセージ受領確認 [RFC3461] を明示的に要求する場合があり、これはNDNと同じ国際化拡張の問題を引き起こします。

5. Overview of the Approach and Document Plan (アプローチの概要と文書計画)​

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.

この一連の仕様は、非ASCII文字を直接表現できるようにするために、SMTPと電子メールメッセージヘッダーの文字エンコーディングの両方を変更します。作業の重要な各コンポーネントは、個別の文書で説明されています。以下で説明するメンバーで構成される文書セットには、プロトコルの実装に関する提案やガイダンスを提供することを目的とした情報提供文書も含まれています。

In addition to this document, the following documents make up this specification and provide advice and context for it.

本文書に加えて、以下の文書が本仕様を構成し、助言と背景を提供します。

  • SMTP extension. The SMTP extension document [RFC6531] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses.

  • SMTP拡張。 SMTP拡張文書 [RFC6531] は、国際化アドレスのためのSMTP拡張（RFC 5321で規定されているとおり）を提供します。

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

  • UTF-8での電子メールメッセージヘッダー。 電子メールメッセージヘッダー文書 [RFC6532] は基本的にRFC 5322を更新し、上記のSMTP拡張が使用されている場合に、電子メールメッセージヘッダー内の一部の情報をUTF-8でエンコードされたUnicode文字で直接表現できるようにします。この文書は、おそらく1つ以上の補足文書とともに、SMTPUTF8と内部MIMEヘッダーおよびコンテンツタイプとの関係を含む、MIMEとの相互作用に対処する必要もあります。

  • Extensions to delivery status and notification handling to adapt to internationalized addresses [RFC6533].

  • 配信ステータスおよび通知処理の拡張。国際化アドレスに適応するため [RFC6533]。

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

  • 今後の文書では、国際化メッセージヘッダーをサポートするためのIMAPプロトコル [RFC3501] への拡張 [RFC5738bis-IMAP]、POPプロトコル [RFC5721] [RFC5721bis-POP3] への並行拡張、および両者のいくつかの共通プロパティ [POPIMAP-downgrade] が規定される予定です。

6. Review of Experimental Results (実験結果のレビュー)​

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

この一連のプロトコルと、それに先行する実験的なセット [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] との主な違いは、初期のグループがメッセージの転送中ダウングレードのメカニズムを提供していたことです（RFC 5504で詳細に説明されています）。そのメカニズムは、各非ASCIIアドレスに全ASCIIの同等物が伴うことを許可し、本質的に要求していました。これは、ひいては、認証できないアドレスのペアリングに関連するセキュリティ上の懸念を引き起こしました。また、インターネットメールアドレッシングに長年ぶりの互換性のない変更をもたらし、新しいアドレス形式がレガシー電子メール実装に「漏洩」した場合の相互運用性の問題についての懸念を引き起こしました。これらの仕様の初期の実験的な前身での経験を検討した後、それらを作成したワーキンググループは、転送中ダウングレードの利点が、運用上実現可能であれば、それらの懸念を克服するのに十分重要であると結論付けました。

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.

プロトコル自体のもう1つの重要な変更は、拡張機能が必要な場合、SMTPUTF8キーワードがSMTPクライアントのアナウンスとして必須になったことです。実験版では、拡張エンベロープおよび/またはコンテンツが許可されているというサーバのアナウンスのみが必要でした。

7. Overview of Protocol Extensions and Changes (プロトコル拡張と変更の概要)​

7.1. SMTP Extension for Internationalized Email Address (国際化電子メールアドレスのためのSMTP拡張)​

An SMTP extension, "SMTPUTF8", is specified as follows:

SMTP拡張 "SMTPUTF8" は次のように規定されています。

  • Permits the use of UTF-8 strings in email addresses, both local parts and domain names.

  • 電子メールアドレス（ローカルパートとドメイン名の両方）でのUTF-8文字列の使用を許可します。

  • Permits the selective use of UTF-8 strings in email message headers (see Section 7.2).

  • 電子メールメッセージヘッダーでのUTF-8文字列の選択的な使用を許可します（セクション7.2を参照）。

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

  • 特別なコンテンツ転送エンコーディングを使用せずにヘッダー情報を送信できるように、サーバが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 promote consistent processing of characters throughout the address.

  2. 電子メールアドレスは、文字セット変換やその他のエンコーディング変更を実行する可能性のあるサブシステム（ユーザインターフェースなど）に入ります。アドレスのローカルパートにASCII文字レパートリー外の文字が含まれている場合、アドレス全体で文字の一貫した処理を促進するために、ドメインパートでのASCII互換エンコーディング（ACE）[RFC3492] [RFC5890] の使用は推奨されません。

  3. An SMTP relay MUST

    • Either recognize the format explicitly, agreeing to do so via an ESMTP option, or
    • Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan.

  4. SMTPリレーは以下を行う必要があります。

    • フォーマットを明示的に認識し、ESMTPオプションを介してそうすることに同意する、または
    • 送信者が別の計画を立てられるように、メッセージを拒否するか、必要に応じて配信不能通知メッセージを返す。

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

  6. 次のホップのシステムが拡張機能を受け入れられないためにメッセージを転送できない場合は、拒否するか、配信不能メッセージを生成して送信する必要があります。

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

  8. 相互運用性の観点から、インターネット経由で送信されるメールアドレスおよびメッセージヘッダーでは、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] 仕様に準拠する必要があります。

7.2. Transmission of Email Header Fields in UTF-8 Encoding (UTF-8エンコーディングでの電子メールヘッダーフィールドの送信)​

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.

MUAやユーザプレゼンテーションには、電子メールアドレスやドメイン名が表示される場所がたくさんあります。例としては、従来の "From:", "To:", "Cc:" ヘッダーフィールド、通常ドメイン名を含む "Message-ID:" および "In-Reply-To:" ヘッダーフィールド（ただし、これは特別な場合かもしれません）、およびメッセージ本文があります。これらはそれぞれ、国際化の観点から検討する必要があります。ユーザは、メールボックス名とドメイン名がローカル文字で表示され、それらが一貫して表示されることを期待します。プロトコル固有のACEバリアントなどの自明でないエンコーディングが使用されると、ユーザは必然的に、たまにしかなくても、「ネイティブ」文字ではなくそれらを目にすることになり、不快に感じたり驚いたりするでしょう。同様に、メール転送とメッセージ本文で異なるコーディングが使用される場合、ユーザは特に驚く可能性が高くなります（これは、長く確立された「物は漏れる（things leak）」という原則の結果としてのみかもしれませんが）。中長期的の両方において、これらの不快感の原因を回避する唯一の実用的な方法は、転送で使用されるエンコーディングを、メッセージヘッダーとメッセージ本文で使用されるエンコーディングにできるだけ近づけることです。

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.

電子メールのローカルパートが国際化されている場合、メッセージヘッダーも完全に国際化された形式にするための手配を伴うべきです（SHOULD）。その形式では、ヘッダーフィールドの内容の基本文字セットとしてASCIIではなくUTF-8を使用すべきです（SHOULD）（ヘッダーフィールド名自体などのプロトコル要素は変更されず、完全にASCIIのままです）。移行目的およびレガシーシステムとの互換性のために、これはヘッダー内の非ASCII文字に対する従来のMIMEエンコーディングモデル [RFC2045] [RFC2231] を拡張することによって行うことができますが、可能であれば、これらも他のエンコーディングではなくUTF-8に基づくべきです [RFC6055]。ただし、[RFC6532] で議論されているように、目標は完全に国際化されたメッセージヘッダーであり、拡張された痛みを伴う移行ではありません。

7.3. SMTP Service Extension for DSNs (DSNのためのSMTPサービス拡張)​

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

既存の配信ステータス通知（DSN）仕様 [RFC3461]（ドラフト標準）は、プロトコルの機械可読部分のASCIIテキストに限定されています。「国際配信および処理通知」[RFC6533] は、国際電子メールアドレス用の新しいアドレスタイプを追加し、非ASCII文字を含む元の受信者アドレスがダウングレード後も正しく保持されるようにします。SMTPサーバがSMTPUTF8とDSN拡張の両方をアドバタイズする場合、そのサーバはRFC 3461 [RFC3461] で指定されたORCPTパラメータのサポートを含む国際化DSNを実装しなければなりません（MUST）。

8. Downgrading before and after SMTP Transactions (SMTPトランザクション前後のダウングレード)​

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

これらの拡張機能に関する重要な問題は、非ASCIIアドレスをサポートするシステムとASCIIを予期するレガシーシステムとの間の相互作用をどのように処理するかです。もちろん、ASCIIのみのシステムから国際化形式を処理できるシステムへの送信には問題ありません。ASCII形式は適切なサブセットにすぎないからです。しかし、これらの拡張機能をサポートするシステムがメールを送信する場合、送信者、受信者、またはその両方に非ASCIIアドレスを含めることがあり（MAY）、アドレス以外の非ASCIIヘッダー情報を提供することもあります。最初のホップのシステム（つまり、SMTPクライアントとして機能する送信サーバがアクセスするSMTPサーバ）が拡張機能をサポートしていない場合、メッセージ発信システムは、従来のエンベロープとメッセージヘッダーを送信するか、メッセージを発信ユーザに返してメッセージを手動で従来の形式にダウングレードできるように準備する必要があります（SHOULD）。メッセージヘッダーでエンコードされた単語 [RFC2047] を使用する可能性があります。もちろん、このような変換は、発信ユーザまたはシステムが、すべての送信者と受信者に対してASCIIのみのアドレスを利用できる必要があることを意味します。そのようなアドレスを見つけたり特定したりするメカニズムは、これらの仕様の範囲外であり、必要な変換をユーザが行うか、発信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ホストで構成すべきではありません（SHOULD NOT）。送信されている唯一の非ASCIIアドレスが後方参照（例：SMTP MAILコマンド内）である場合、受信者の構成は一般に役に立ちません。一方、送信者の代替の全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のみの形式へのダウングレードは、最初のメッセージ送信前または送信中に発生する可能性があります。また、メッセージストア、IMAPまたはPOPサーバ、または配信MTAとは異なる機能を持つクライアントに対応するために、最終配信MTAへの配信後に発生する場合もあります。これらのケースについては、以下のサブセクションで説明します。

8.1. Downgrading before or during Message Submission (メッセージ送信前または送信中のダウングレード)​

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では、パブリックインターネットに注入された時点で結果が「オン・ザ・ワイヤー」標準に準拠している限り、ユーザが何を提供できるかについて、MUAと送信サーバに広い裁量を与えています。その伝統に則り、セクション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 risks are especially great in environments in which non-delivery messages (or other indications from submission servers) are routinely dropped or ignored.

これらの拡張機能を必要とするメッセージは、これらの拡張機能をサポートしていないシステムに転送されることがあります。最も一般的なケースは、ASCIIのみの前方参照アドレスと非ASCIIの後方参照アドレスの組み合わせである可能性が高いです。ここで説明されている拡張機能がインターネットの電子メール環境に普遍的に実装されるまでは、非ASCIIアドレス（またはヘッダーフィールド内の生のUTF-8文字）を使用することを好む送信者は、意図した受信者が全ASCIIアドレスを使用し期待している場合でも、発生する可能性のあるエラー状態について特に注意する必要があります。配信不能メッセージ（または送信サーバからのその他の指示）が日常的にドロップまたは無視される環境では、リスクが特に大きくなります。

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つ以上を含むメッセージを受信し、送信サーバが遭遇する配信またはネクストホップ環境に対応するために、必要に応じて送信メッセージを適応させることができます。

8.2. Downgrading or Other Processing after Final SMTP Delivery (最終SMTP配信後のダウングレードまたはその他の処理)​

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メッセージヘッダーを理解するようにアップグレードされていないMUAや電子メール取得メカニズムが、保存された国際化電子メールにアクセスするのを防ぐものではありません。

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 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（より具体的には、対応するメールストレージエージェント）は、電子メールストレージにアクセスするエージェントがここで提案されている拡張機能を常に処理できると安全に仮定することはできないため、国際化電子メールをダウングレードしたり、これらの拡張機能を利用するメッセージを特別に識別したり、あるいはその両方を行うことができます（MAY）。これらのアクションのいずれかまたは両方が行われる場合、最終配信MTAは、情報を失うことなく元の国際化形式を保存または回復するメカニズムを含めるべきです（SHOULD）。その情報の保存は、SMTPUTF8対応エージェントによるアクセスをサポートするために必要です。

9. Downgrading in Transit (転送中のダウングレード)​

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）には、「中間ホストが転送を変更して最適化しようとしたときの問題の長い歴史のため、ローカルパートは、アドレスのドメインパートで指定されたホストによってのみ解釈され、セマンティクスが割り当てられなければならない（MUST）」と記載されています。これは新しい要件ではありません。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%[email protected] is a route ("user" is reached via "foo") or simply a local address.

このルールの理由の1つは、アドレスフィールドのローカルパートにメールルーティング情報を埋め込むレガシー電子メールシステムに関係しています。電子メールアドレスを変換すると、そのようなルーティング情報が破壊されます。最終配信サーバ以外のサーバが、たとえば user%[email protected] のローカルパートがルート（"user" は "foo" 経由で到達）なのか、単なるローカルアドレスなのかを知る方法はありません。

10. User Interface and Configuration Issues (ユーザインターフェースと設定の問題)​

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の問題を議論する文書が開発されることが期待されます。以下のサブセクションでは、その他のいくつかの問題について説明します。

10.1. Choices of Mailbox Names and Unicode Normalization (メールボックス名の選択とUnicode正規化)​

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文字で構成できます（MAY）が、その一部はそこで指定されているように引用符で囲む必要があります（MUST）。国際化の文脈で注目すべきは、引用符で囲まれた文字列内でオーバーストライクASCII文字（文字、バックスペース、および別の文字）を使用して非ASCII文字を近似するという長い歴史が一部のシステムにあることです。この形式の国際化はRFC 821 [RFC0821] で許可されていましたが、バックスペース文字（禁止されているC0制御）が必要なため、RFC 5321では禁止されています。RFC 5321（およびその前身であるRFC 2821）は、ASCIIメールボックス名でのこの文字の使用を禁止しており、非ASCII文字列ではさらに問題がある（正規化と標準化の理由で）ため、バックスペースはSMTPUTF8メールボックス名に表示されてはなりません（MUST NOT）。

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-UAX15] に特別な注意を払う必要があります（MUST）。これは部分的には、Unicode文字列がメールプロトコルの指定とは無関係に他のプロセスによって正規化される可能性があるためです（これは、従来のアドレスでの引用と引用解除で発生する可能性のあることとまったく同じです）。その結果、メールボックスの名前を選択する人へのアドバイスとして、次の原則が提供されます。

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

  • 一般に、少なくとも正規化形式NFCを使用して、正規化形式のアドレスをサポートすることが賢明です。宛先メールサーバの責任者が区別しておきたい文字をNFKCが一緒にマッピングするような状況を除いて、NFKC準拠の形式をサポートすると、一般的なユーザにとってさらに予測可能な動作が得られます。

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

  • エイリアスとして、または配信サーバに到達する文字列の正規化によって、同じローカルパート文字列の他の形式をサポートすることは通常賢明です。送信者が正規化された形式で文字列を送信することに依存すべきではありません。

  • Stated differently and in more specific terms, the rules of the protocol for local-part strings essentially provide that:

  • 別の言い方をすれば、より具体的な言葉で言えば、ローカルパート文字列のプロトコルのルールは基本的に次のことを規定しています。

    • 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] を参照）は禁止されています。前者はRFC 5321で、後者はそれからの明らかな拡張 [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受信コードは深刻なエラーなしにそれらを処理する必要があります（たとえそのような文字列がそのサーバに配信されるアドレスで受け入れられないとしても）。しかし、選択されたメールボックス名でそれらに依存関係を作成することは通常悪い習慣であり、相互運用性の問題につながる可能性があります。

11. Additional Issues (その他の問題)​

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.

このセクションでは、この一連の仕様の一部としてカバーされていない、または包括的にカバーされていない問題を特定しますが、電子メールアドレスとヘッダーの国際化の展開の一部として継続的なレビューが必要になります。

11.1. Impact on URIs and IRIs (URIとIRIへの影響)​

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: スキーマ [RFC6068]、および国際化リソース識別子（IRI）仕様 [RFC3987] におけるその議論は、この作業が完了して標準化されたときに修正が必要になる場合があります。

11.2. Use of Email Addresses as Identifiers (識別子としての電子メールアドレスの使用)​

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] に含まれる識別子としてなどが含まれます。これらの文書はそれらの使用については扱っていませんが、国際化アドレスがそれらのコンテキストで最初に使用されるときに、いくつかの困難に遭遇することは予想に難くありません。それらの多くは、今日許可されているアドレスの全範囲さえ処理できません。

11.3. Encoded Words, Signed Messages, and Downgrading (エンコードされた単語、署名付きメッセージ、およびダウングレード)​

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は、数秒前に配信されたメッセージだけでなく、数十年前に最初に送信されたメッセージも処理することが期待されています。そのため、MUAおよびメールフィルタリングソフトウェア（Sieve [RFC5228] で指定されているものなど）は、一部のヘッダーフィールドの非ASCII文字に対応するために「エンコードされた単語」メカニズム [RFC2047] を使用するヘッダーフィールドを受け入れ、デコードし続ける必要があります。POP3 [RFC1939] とIMAP [RFC3501] の両方に対する拡張機能が定義されており、これには、POP3 [RFC5721bis-POP3] またはIMAP [RFC5738bis-IMAP] サーバによる、エンコードされた形式で非ASCII情報を運ぶメッセージの自動アップグレード（RFC 2047デコードを含む）が含まれていますが、それが不可能なメッセージ構造や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] やPretty Good Privacy (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ボディパートヘッダーのいずれかに影響を与える場合、署名を無効にするのに十分な場合があります。署名が存在する場合、ダウングレードは、行うとしても細心の注意を払って実行する必要があります。

11.4. Other Uses of Local Parts (ローカルパートのその他の用途)​

Local parts are sometimes used to construct domain labels, e.g., the local part "user" in the address [email protected] could be converted into a host name user.domain.example with its Web space at http://user.domain.example and the catch-all addresses [email protected].

ローカルパートは、ドメインラベルを構築するために使用されることがあります。たとえば、アドレス [email protected] のローカルパート "user" は、http://user.domain.example にWebスペースを持つホスト名 user.domain.example に変換され、キャッチオールアドレス [email protected] になる可能性があります。

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が受け入れるメールボックス名とその解釈方法を決定する際に与えられたかなりの柔軟性の別のケースかもしれません。

11.5. Non-Standard Encapsulation Formats (非標準のカプセル化フォーマット)​

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] で定義された message/digest 形式の代わりに、application/mbox 形式 [RFC4155] に似た形式を使用します。そのようなアプリケーションが、保存されたすべてのメッセージがASCIIメッセージヘッダーを持つRFC 2046のセクション5.2.1 [RFC2046] で記述された message/rfc822 形式を使用すると仮定している限り、それらはこの一連の文書で指定された拡張機能に対応しておらず、それらを適切に検出して処理するために特別な措置が必要になる場合があります。

12. Key Changes from the Experimental Protocols and Framework (実験的プロトコルおよびフレームワークからの主な変更点)​

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アドレスを渡すことをサポートする構文と機能の定義、およびメッセージのダウングレードステータスを示す特別なヘッダーが含まれていました。これらの機能は、実験により以前に想定されていたよりも複雑であり、必要性が低いことが示されたため、削除されました。これらの問題については、セクション6および9で詳しく説明しています。

13. Security Considerations (セキュリティに関する考慮事項)​

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ホモグラフ攻撃」についての議論がありました。これらの攻撃により、攻撃者（または「フィッシャー」）は、企業やその他のエンティティのドメインまたは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 [RFC3629] で議論されているUTF-8正規化やその他の変換に関するいくつかの問題も潜在的に必要とします。正規化および変換と標準形式に関連するその他の問題も、他の場所で説明されている作業の主題の一部です [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ヘッダーおよびメッセージ形式は、別の既知の問題を引き起こしたり、悪化させたりする可能性もあります。モデルが「無効な」または「不正な形式の」メッセージの新しい形式を作成する場合、新しい電子メール攻撃が作成されます。堅牢であろうとするあまり、一部またはほとんどのエージェントはそのようなメッセージを受け入れ、あたかもそれらが正しい形式であるかのように解釈します。フィルタがそのようなメッセージを受信者が使用する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 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.

この作業は、電子メールメッセージヘッダーのデジタル署名または同様の整合性保護に依存するシステムまたはメカニズムに明らかに影響します（セクション11.3の議論も参照）。PGPおよびS/MIMEの多くの従来の用途は、メッセージヘッダーではなくボディパートに署名するために使用されるため、影響を受けません。一方、DomainKeys Identified Mail（DKIM）[RFC5863] に関する開発作業は、最終的にこの作業を考慮する必要があり、その逆も同様です。この仕様はDKIMおよびその他の署名付きヘッダーメカニズムによって提起される問題に対処または解決しませんが、2つのプロトコルセットが共存するためには、最終的に問題を調整して解決する必要があります。さらに、電子メールアドレスがPKI（公開鍵インフラストラクチャ）証明書 [RFC5280] に表示される程度まで、そのような証明書を扱う標準は、これらの国際化アドレスに対処するためにアップグレードする必要があります。それらのアップグレードは、アドレス自体の類似物によるなりすましの問題に対処する必要があります。

14. Acknowledgments (謝辞)​

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正誤表から大きな恩恵を受けました。

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.

Ernie Dainow氏による慎重なレビューとこのバージョンのテキストの提案、および数人のIESGメンバーによる慎重なレビューと具体的な提案に特に感謝します。

15. References (参考文献)​

15.1. Normative References (引用規格)​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

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

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

  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.

15.2. Informative References (参考文献)​

  • [POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, October 2011.

  • [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

  • [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

  • [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

  • [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.

  • [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

  • [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.

  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

  • [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.

  • [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.

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

  • [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.

  • [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

  • [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.

  • [RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.

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

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

  • [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.

  • [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.

  • [RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, November 2011.

  • [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.

  • [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, December 2011.

  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

  • [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.

  • [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.

  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.

  • [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.

  • [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.

  • [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.

  • [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.

  • [RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", Work in Progress, December 2011.

  • [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.

  • [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [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-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, http://www.unicode.org/reports/tr15/.

に最終更新