[要約] RFC 4952は、国際化されたメールの概要とフレームワークを提供するものであり、国際的なメールの問題を解決するためのガイドラインを提供します。目的は、異なる言語や文字セットを使用するユーザー間でのメールの相互運用性を向上させることです。
Network Working Group J. Klensin
Request for Comments: 4952
Category: Informational Y. Ko
ICU
July 2007
Overview and Framework for Internationalized Email
国際化された電子メールの概要とフレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
Full use of electronic mail throughout the world requires that people be able to use 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.
世界中の電子メールを完全に使用するには、メールアドレスのメールボックス名として、自分の言語やスクリプトで正しく書かれた独自の名前を使用できる必要があります。このドキュメントでは、国際化された電子メールアドレスを完全にサポートするために必要なメカニズムとプロトコル拡張を定義する一連の仕様を紹介します。これらの変更には、UTF-8データに対応するためのSMTP拡張と電子メールヘッダー構文の拡張が含まれます。ドキュメントセットには、完全な国際化された電子メールの展開における重要な仮定と問題の議論も含まれています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of the Approach . . . . . . . . . . . . . . . . . . . 6
3. Document Plan . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Protocol Extensions and Changes . . . . . . . . . 7
4.1. SMTP Extension for Internationalized Email Address . . . . 7
4.2. Transmission of Email Header Fields in UTF-8 Encoding . . 8
4.3. Downgrading Mechanism for Backward Compatibility . . . . . 9
5. Downgrading before and after SMTP Transactions . . . . . . . . 10
5.1. Downgrading before or during Message Submission . . . . . 10
5.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 11
6.2. Interaction with Delivery Notifications . . . . . . . . . 12
6.3. Use of Email Addresses as Identifiers . . . . . . . . . . 12
6.4. Encoded Words, Signed Messages, and Downgrading . . . . . 12
6.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 13
6.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 13
7. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
In order to use internationalized email addresses, we need to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC3490], 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 [RFC2821]. 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 2822 [RFC2822] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant headers. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all.
国際化されたメールアドレスを使用するには、ドメイン部分と電子メールアドレスのローカル部分の両方を国際化する必要があります。電子メールアドレスのドメイン部分はすでに国際化[RFC3490]ですが、ローカル部分は既にそうではありません。このドキュメントで指定された拡張機能がない場合、メールボックス名は7ビットASCII [RFC2821]のサブセットに制限されています。MIME [RFC2045]は非ASCIIデータの輸送を可能にしますが、国際化された電子メールアドレスのメカニズムは提供されません。RFC 2047 [RFC2047]では、MIMEは、ASCII以外のデータに対応するための特定のメッセージヘッダーフィールドのエンコーディングメカニズムを定義しています。ただし、ASCII以外の文字を含む電子メールアドレスの使用は許可されていません。ここで定義されている拡張機能、または同等のセットがない場合、電子メールアドレスのいずれかの部分に非ASCII文字を組み込む唯一の方法は、RFC 2047コーディングを使用してRFC 2822 [RFC2822]を「ディスプレイ名」と呼ぶものに埋め込むことです。関連するヘッダーの「名前フレーズ」または他の用語で）として。ディスプレイ名にコード化された情報は、メッセージエンベロープでは見えません。多くの目的で、アドレスの一部ではありません。
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 headers, but also associated transport and delivery models.
このドキュメントでは、電子メール国際化の次の段階へのアプローチの概要とフレームワークを示します。この新しい段階では、住所とヘッダーの国際化だけでなく、関連する輸送モデルと配信モデルも必要です。
This document provides the framework for a series of experimental specifications that, together, 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 how the relationships among the various documents are involved.
このドキュメントは、国際化された電子メールを実装およびサポートする方法の詳細を一緒に提供する一連の実験仕様のフレームワークを提供します。ドキュメント自体は、電子メールの国際化のさまざまな要素がどのように適合し、さまざまなドキュメント間の関係が関係するかを説明しています。
Internationalizing Domain Names in Applications (IDNA) [RFC3490] 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）[RFC3490]は、国際化されたドメイン名を許可していますが、展開はまだほとんどのユーザーに到達していません。これの理由の1つは、まだ完全に国際化された命名スキームがないことです。ドメイン名は、国際化する必要があるさまざまな名前と識別子の1つにすぎません。多くの文脈では、これらの識別子の多くが国際化されるまで、国際化されたドメイン名だけではほとんど価値がありません。
Email addresses are prime examples of why it is not good enough to just internationalize the domain name. As most of us 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 headers; 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 or other community. That, in turn, implies changes to the mail header environment to permit the full range of Unicode characters where that makes sense, an SMTP Extension to permit UTF-8 [RFC3629] mail addressing and delivery of those extended headers, and (finally) a requirement for support of the 8BITMIME SMTP extension [RFC1652] so that all of these can be transported through the mail system without having to overcome the limitation that headers do not have content-transfer-encodings.
電子メールアドレスの国際化は、単にSMTPエンベロープを変更する問題ではありません。または、from、to、およびccヘッダーを変更する。または、アップグレードされたメールユーザーエージェント（MUA）を許可して、特別なコーディングをデコードし、ローカル文字を表示して応答します。使用可能であると認識されるには、アドレスは国際化され、それらが発生するすべてのコンテキストで一貫して処理されなければなりません。この要件には、広範囲にわたる意味があります。パッチと回避策のコレクションは適切ではありません。たとえそれらが適切であったとしても、回避策ベースのアプローチは、実際に使用可能でサポートされているものについての結果としてのユーザーの混乱とともに、さまざまなパッチと回避策を備えた実装の品揃えをもたらす可能性があります。代わりに、言語や他のコミュニティを共有する人々の間で効率的なコミュニケーションを許可することに焦点を当て、完全に国際化された電子メール環境を構築する必要があります。それは、それが、それが理にかなっているユニコード文字の全範囲を許可するために、Mail Header環境の変更を意味することを意味します。8bitmime SMTP拡張[RFC1652]のサポートの要件により、これらすべてが、ヘッダーにコンテンツ転送エンコードがないという制限を克服することなく、メールシステムを介して輸送できるようにします。
This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in [RFC2821] and [RFC2822].
このドキュメントは、[RFC2821]および[RFC2822]に文書化されているように、コアメール標準のプロトコルと用語の合理的な理解を想定しています。
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 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 2821. 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 2821の「配信システム」または「最終配信システム」という用語に相当するファッションで使用されます。これは、アドレスのローカル部分の形式を制御する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 "UTF8SMTP". For example, an address permitted by this specification is referred to as a "UTF8SMTP (compliant) address".
このドキュメントとそのコンパニオンドキュメントで指定された電子メールアドレスの国際化を説明する傘の用語は「UTF8SMTP」です。たとえば、この仕様で許可されているアドレスは、「UTF8SMTP（準拠）アドレス」と呼ばれます。
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 UTF8SMTP addresses is the union of these two sets.
ここに記載されている定義によれば、すべての「すべてのASCII」アドレスのセットとすべての「非ASCII」アドレスのセットは相互に排他的であることに注意してください。すべてのUTF8SMTPアドレスのセットは、これら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 "i18mail user" has one or more non-ASCII email addresses. 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 i18mail user or not. (A non-ASCII address implies a belief that the owner of that address is an i18mail user.) There is no such thing as an "i18mail message"; the term applies only to users and their agents and capabilities.
「i18mailユーザー」には、1つ以上の非ASCIIメールアドレスがあります。このようなユーザーは、ASCIIアドレスも持っている可能性があります。ユーザーが複数の電子メールアカウントと対応するアドレス、または同じアドレスの複数のエイリアスを持っている場合、送信メールで使用するアドレスを選択する方法があります。この定義の下では、ASCIIアドレスからそのアドレスの所有者がi18mailユーザーであるかどうかを知ることはできないことに注意してください。（非ASCIIアドレスは、そのアドレスの所有者がi18mailユーザーであるという信念を暗示しています。）「i18mailメッセージ」のようなものはありません。この用語は、ユーザーとそのエージェントと機能にのみ適用されます。
A "message" is sent from one user (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つの受信者アドレスに送信することにより、複数の受信者にメッセージを配布できるメカニズムです。その単一のアドレスのエージェント（通常は人間ではありません）は、メッセージをターゲット受信者に再配布します。このエージェントは、元の単一の受信者メッセージとは異なるアドレスに再配布されたメッセージの封筒返信アドレスを設定します。別のエンベロープ返信アドレス（リバースパス）を使用すると、エラー（およびその他の自動生成された）メッセージがエラー処理アドレスに移動します。
As specified in RFC 2821, 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 2821で指定されているように、何らかの理由で配信不可能なメッセージは、送信者への通知をもたらすと予想されます。これは、2つの方法のいずれかで発生する可能性があります。通常、「拒否」と呼ばれる1つは、SMTPサーバーが致命的なエラー（「5YZ」コード）を示す返信コードを返すときに発生するか、一時的な障害エラー（「4YZ」コード）を永続的に返します。もう1つは、SMTP処理中にメッセージを受け入れ、通常は「非配信通知」または「NDN」と呼ばれる送信者にメッセージを生成することを伴います。現在の慣行は、NDNの生成がスパム技術として使用される可能性が低下するため、NDNに対する拒否をしばしば支持します。後者のNDNは、中間MTAが次のホップサーバーによって拒否されるメッセージを受け入れる場合、避けられません。
The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender.
代名詞「彼」と「彼女」は、不確定な性別の人間を示すために交換可能に使用されます。
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントの「必須」、「必要」、「必須」、「必須」、「推奨」、および「5月」は、RFC 2119 [RFC2119]に記載されているように解釈されるべきです。
This set of specifications changes both SMTP and the format of email 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 in the next section, 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 extensions. This document [EAI-SMTPext] provides an SMTP extension for internationalized addresses, as provided for in RFC 2821.
o SMTP拡張機能。このドキュメント[EAI-SMTPEXT]は、RFC 2821で規定されているように、国際化アドレスのSMTP拡張を提供します。
o Email headers in UTF-8. This document [EAI-UTF8] essentially updates RFC 2822 to permit some information in email 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 UTF8SMTP and internal MIME headers and content types.
o UTF-8のヘッダーにメールしてください。このドキュメント[EAI-UTF8]は、基本的にRFC 2822を更新して、上記のSMTP拡張を使用した場合、UTF-8でエンコードされたUnicode文字によって電子メールヘッダーのいくつかの情報を直接表現することを許可します。このドキュメントは、おそらく1つ以上の補足的なものを使用して、UTF8SMTPと内部MIMEヘッダーとコンテンツタイプの関係など、MIMEとの相互作用に対処する必要があります。
o In-transit downgrading from internationalized addressing with the SMTP extension and UTF-8 headers to traditional email formats and characters [EAI-downgrade]. Downgrading either at the point of message origination or after the mail has successfully been received by a final delivery SMTP server involve different constraints and possibilities; see Section 4.3 and Section 5, below. Processing that occurs after such final delivery, particularly processing that is involved with the delivery to a mailbox or message store, is sometimes called "Message Delivery" processing.
o SMTP拡張機能とUTF-8ヘッダーを使用した国際化アドレス指定から、従来の電子メール形式と文字[EAI-DownGrade]への輸送中の格下げ。メッセージのオリジネーションのポイントでの格下げまたはメールが最終配信SMTPサーバーによって正常に受信された後、さまざまな制約と可能性が含まれます。以下のセクション4.3およびセクション5を参照してください。このような最終配信後に発生する処理、特にメールボックスまたはメッセージストアへの配信に関係する処理は、「メッセージ配信」処理と呼ばれることもあります。
o Extensions to the IMAP protocol to support internationalized headers [EAI-imap].
o IMAPプロトコルへの拡張は、国際化されたヘッダー[EAI-IMAP]をサポートします。
o Parallel extensions to the POP protocol [EAI-pop].
o POPプロトコル[EAI-POP]への並列拡張。
o Description of internationalization changes for delivery notifications (DSNs) [EAI-DSN].
o 配信通知の国際化の変更（DSNS）[EAI-DSN]。
o Scenarios for the use of these protocols [EAI-scenarios].
o これらのプロトコル[EAI-Scenarios]を使用するためのシナリオ。
An SMTP extension, "UTF8SMTP" is specified as follows:
SMTP拡張機能「UTF8SMTP」は、次のように指定されています。
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 headers (see Section 4.2).
o 電子メールヘッダーでUTF-8文字列の選択的使用を許可します（セクション4.2を参照）。
o Requires that the server advertise the 8BITMIME extension [RFC1652] and that the client support 8-bit transmission so that header information can be transmitted without using special content-transfer-encoding.
o サーバーが8Bitmime拡張機能[RFC1652]を宣伝し、クライアントが8ビット伝送をサポートして、特別なコンテンツ転送エンコードを使用せずにヘッダー情報を送信できるようにする必要があります。
o Provides information to support downgrading mechanisms.
o 格下げメカニズムをサポートする情報を提供します。
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 left hand side of the address includes characters outside the US-ASCII character repertoire, use of punycode on the right hand side is discouraged to promote consistent processing of characters throughout the address.
1. 電子メールアドレスは、チャーセット変換またはその他のエンコード変更を実行できるサブシステム（ユーザーインターフェイスなど）を入力します。アドレスの左側にUS-ASCII文字のレパートリー以外の文字が含まれている場合、右側でのプニコードの使用は、アドレス全体の文字の一貫した処理を促進するために落胆します。
2. An SMTP relay must
2. SMTPリレーは必要です
* Either recognize the format explicitly, agreeing to do so via an ESMTP option,
*
* Select and use an ASCII-only address, downgrading other information as needed (see Section 4.3), or
* Ascii-Onlyアドレスを選択して使用し、必要に応じて他の情報の格下げ（セクション4.3を参照）、または
* Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan.
* メッセージを拒否するか、必要に応じて、送信者が別の計画を立てることができるように、非配信通知メッセージを返します。
If the message cannot be forwarded because the next-hop system cannot accept the extension and insufficient information is available to reliably downgrade it, it MUST be rejected or a non-delivery message generated and sent.
次のホップシステムが拡張機能を受け入れず、情報が不十分な情報を確実に格下げするために、メッセージを転送できない場合、拒否されたか、生成されて送信されない配信メッセージを拒否する必要があります。
3. In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and headers. There is no practical way to identify them properly with an extension similar to this without introducing great complexity.
3. 相互運用性のために、UTF-8以外の充電器はメールアドレスとヘッダーで禁止されています。大きな複雑さを導入することなく、これに似た拡張機能でそれらを適切に識別する実用的な方法はありません。
Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP Extension specification, including recognition of the keywords associated with alternate addresses, and the UTF-8 Header specification. Support for downgrading is not required, but, if implemented, MUST be implemented as specified. Similarly, if the system implements IMAP or POP, it MUST conform to the i18n IMAP or POP specifications respectively.
電子メールトランスポートと配信のためにここで指定された標準のグループへの適合には、代替アドレスに関連付けられたキーワードの認識、およびUTF-8ヘッダー仕様を含むSMTP拡張仕様の実装が必要です。格下げのサポートは必要ありませんが、実装されている場合は、指定どおりに実装する必要があります。同様に、システムがIMAPまたはPOPを実装する場合、I18N IMAPまたはPOP仕様にそれぞれ適合する必要があります。
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 ASCII-Compatible Encoding (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ヘッダーフィールドが含まれます。通常、ドメイン名を含むメッセージ-IDおよびIn-Reply-to Headerフィールド（ただし、それは特別なケースかもしれません）。そしてメッセージ本文で。これらのそれぞれは、国際化の観点から検討する必要があります。ユーザーは、ローカル文字のメールボックスとドメイン名を表示し、一貫して表示することを期待します。プロトコル固有のASCII互換エンコード（ACE）バリアントなどの非自明なエンコーディングが使用されている場合、ユーザーは必然的に、「ネイティブ」文字ではなくそれらを見ることがあり、その識別や驚くべきものを見つけることができます。同様に、メールトランスポートやメッセージボディに異なるコーディングが使用される場合、ユーザーは、長年にわたって確立されていた「漏れ」の原則の結果としてのみ、特に驚かされる可能性があります。これらの不快感の原因を中期と長期の両方で回避する唯一の実用的な方法は、輸送で使用されるエンコーディングを、メッセージヘッダーとメッセージ本文で可能な限り使用するエンコーディングに似ていることです。
When email local parts are internationalized, it seems clear that they should be accompanied by arrangements for the email headers to be in the fully internationalized form. That form should presumably 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 will remain entirely in ASCII). For transition purposes and compatibility with legacy systems, this can done by extending the encoding models of [RFC2045] and [RFC2231]. However, our target should be fully internationalized headers, as discussed in [EAI-UTF8].
電子メールのローカルパーツが国際化されている場合、電子メールヘッダーが完全に国際化された形式になるための手配を伴うべきであることは明らかです。そのフォームは、ヘッダーフィールドの内容のベース文字セットとしてASCIIではなくUTF-8を使用する必要があります（ヘッダーフィールド名自体などのプロトコル要素はASCIIに完全に留まります）。遷移目的とレガシーシステムとの互換性のために、これは[RFC2045]および[RFC2231]のエンコーディングモデルを拡張することで行うことができます。ただし、[EAI-UTF8]で説明されているように、目標は完全に国際化されたヘッダーである必要があります。
As with any use of the SMTP extension mechanism, there is always the possibility of a client that requires the feature encountering a server that does not support the required feature. In the case of email address and header internationalization, the risk should be minimized by the fact that the selection of submission servers are presumably under the control of the sender's client and the selection of potential intermediate relays is under the control of the administration of the final delivery server.
SMTP拡張メカニズムの使用と同様に、必要な機能をサポートしていないサーバーに遭遇する機能が必要なクライアントの可能性が常にあります。電子メールアドレスとヘッダーの国際化の場合、提出サーバーの選択が送信者のクライアントの制御下にあり、潜在的な中間リレーの選択が最終管理の制御下にあるという事実によって、リスクを最小限に抑える必要があります。配信サーバー。
For situations in which a client that needs to use UTF8SMTP encounters a server that does not support the extension UTF8SMTP, there are two possibilities: o Reject the message or generate and send a non-delivery message, requiring the sender to resubmit it with traditional-format addresses and headers.
UTF8SMTPを使用する必要があるクライアントが拡張機能UTF8SMTPをサポートしていないサーバーに遭遇する状況については、2つの可能性があります。oメッセージを拒否するか、非配信メッセージを生成して送信します。フォーマットアドレスとヘッダー。
o Figure out a way to downgrade the envelope or message body in transit. Especially when internationalized addresses are involved, downgrading will require that all-ASCII addresses be obtained from some source. An optional extension parameter is provided as a way of transmitting an alternate address. Downgrade issues and a specification are discussed in [EAI-downgrade].
o 輸送中に封筒またはメッセージ本体をダウングレードする方法を見つけます。特に、国際化されたアドレスが関与している場合、格下げでは、一部のソースからすべてのASCIIアドレスを取得する必要があります。オプションの拡張機能パラメーターは、代替アドレスを送信する方法として提供されます。ダウングレードの問題と仕様については、[eai-downgrade]で説明します。
(The client can also try an alternate next-hop host or requeue the message and try later, on the assumption that the lack of UTF8SMTP is a transient failure; since this ultimately resolves to success or failure, it doesn't change the discussion here.)
（クライアントは、UTF8SMTPの欠如が一時的な障害であると仮定して、代替のNext-Hopホストを試したり、メッセージを要求したり、後で試してみてください。。）
The first of these two options, that of rejecting or returning the message to the sender MAY always be chosen.
これらの2つのオプションのうち、送信者へのメッセージを拒否または返却する最初のオプションは、常に選択される場合があります。
If a UTF8SMTP capable client is sending a message that does not require the extended capabilities, it SHOULD send the message whether or not the server announces support for the extension. In other words, both the addresses in the envelope and the entire set of headers of the message are entirely in ASCII (perhaps including encoded words in the headers). In that case, the client SHOULD send the message whether or not the server announces the capability specified here.
UTF8SMTP対応クライアントが拡張機能を必要としないメッセージを送信している場合、サーバーが拡張機能のサポートを発表するかどうかはメッセージを送信する必要があります。言い換えれば、エンベロープ内のアドレスとメッセージのヘッダーのセット全体の両方が完全にASCII（おそらくヘッダーにエンコードされた単語を含む）にあります。その場合、クライアントは、サーバーがここで指定された機能を発表するかどうかにかかわらずメッセージを送信する必要があります。
In addition to the in-transit downgrades discussed above, downgrading may also occur before or during the initial message submission or after the delivery to the final delivery MTA. Because these cases have a different set of available information from in-transit cases, the constraints and opportunities may be somewhat different too. These two cases are discussed in the subsections below.
上記で説明した輸送中の格下げに加えて、最初のメッセージの提出前または最終配信MTAへの配信後に、格下げが発生する場合があります。これらのケースには、輸送中のケースとは異なる利用可能な情報セットがあるため、制約と機会も多少異なる場合があります。これらの2つのケースについては、以下のサブセクションで説明します。
Perhaps obviously, the most convenient time to find an ASCII address corresponding to an internationalized address is at the originating MUA. 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 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 [RFC4409]) so that they would perform downgrading, or perhaps even upgrading, operations, 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 it encounters.
これに関連して、送信サーバーへの変更（[RFC4409]で説明されているように）のメッセージを簡単に想像できます。そのため、格下げ、またはアップグレード、操作、ここで説明した1つ以上の国際化拡張機能でメッセージを受信し、ここで適応します。必要に応じて、出会う配信または次のホップ環境に応答するための発信メッセージ。
When an email message is received by a final delivery SMTP server, 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.
最終配信SMTPサーバーによって電子メールメッセージが受信されると、通常は何らかの形で保存されます。次に、POPやIMAPなどの電子メール検索メカニズムを介して、保存されたフォームを直接読み取るソフトウェアまたはクライアントソフトウェアによって取得されます。
The SMTP extension described in Section 4.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 headers from accessing stored internationalized emails.
セクション4.1で説明されているSMTP拡張は、輸送においてのみ保護を提供します。国際化された住所やUTF-8ヘッダーが保存された国際化された電子メールへのアクセスを理解するためにアップグレードされていないMUASおよび電子メール検索メカニズムを妨げません。
Since the final delivery SMTP server (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 either downgrade internationalized emails or specially identify messages that utilize these extensions, or both. If this is done, the final delivery SMTP server SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss to support access by UTF8SMTP-aware agents.
最終配信SMTPサーバー（または、より具体的には、対応するメールストレージエージェント）は、電子メールストレージにアクセスするエージェントが常にここで提案されている拡張機能を処理できると安全に想定できないため、国際化された電子メールをダウングレードするか、特別に識別する可能性があります。これらの拡張機能、またはその両方を利用します。これが行われた場合、最終配信SMTPサーバーには、UTF8SMTP対応エージェントによるアクセスをサポートするための情報損失なしに、元の国際化されたフォームを保存または回復するメカニズムを含める必要があります。
This section identifies issues that are not covered as part of this set of specifications, but that will need to be considered as part of deployment of email address and header internationalization.
このセクションでは、この一連の仕様の一部としてカバーされていない問題を特定しますが、電子メールアドレスとヘッダー国際化の展開の一部として考慮する必要があります。
The mailto: schema defined in [RFC2368] and discussed in the Internationalized Resource Identifier (IRI) specification [RFC3987] may need to be modified when this work is completed and standardized.
Mailto：[RFC2368]で定義され、国際化されたリソース識別子（IRI）仕様[RFC3987]で説明されているスキーマは、この作業が完了して標準化されたときに変更する必要がある場合があります。
The advent of UTF8SMTP will make necessary consideration of the interaction with delivery notification mechanisms, including the SMTP extension for requesting delivery notifications [RFC3461], and the format of delivery notifications [RFC3464]. These issues are discussed in a forthcoming document that will update those RFCs as needed [EAI-DSN].
UTF8SMTPの出現は、配信通知[RFC3461]を要求するためのSMTP拡張、および配信通知の形式[RFC3464]を含む配信通知メカニズムとの相互作用を必要な考慮します。これらの問題は、必要に応じてこれらのRFCを更新する今後のドキュメントで説明されています[EAI-DSN]。
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. 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サーバーの識別子を含む、個人の識別子として電子メールアドレスが使用される場所がいくつかあります。これらのドキュメントはこれらの使用に対処していませんが、これらのコンテキストで国際化されたアドレスが最初に使用される場合、いくつかの困難が発生することを期待するのは合理的です。
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 [RFC3028], 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 and IMAP have been proposed to enable automatic EAI-upgrade -- including RFC 2047 decoding -- of messages by the POP3 or 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つは、その持続性です。MUASは、数十年前に送信されたメッセージだけでなく、数秒前に配信されたメッセージだけでなく、メッセージを処理することが期待されています。そのため、Sieve [RFC3028]で指定されているようなMUASおよびメールフィルタリングソフトウェアは、「エンコードされた単語」メカニズム[RFC2047]を使用して、一部のヘッダーフィールドの非ASCII文字に対応するヘッダーフィールドを引き続きデコードする必要があります。。POP3とIMAPの両方の拡張機能は、POP3またはIMAPサーバーによるメッセージの自動EAIアップグレード（RFC 2047デコードを含む）を有効にするために提案されていますが、メッセージ構造とMIMEコンテンツタイプができない、またはどこでマイムコンテンツタイプがあります。この変更には、容認できない副作用があります。
For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC3851] 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 [RFC3851]またはかなり良いプライバシー（PGP）[RFC3156]を使用して、暗号化された署名されたメッセージパーツは、署名を破ることなくRFC 2047フォームから通常のUTF-8文字にアップグレードすることはできません。同様に、暗号化されたメッセージパーツには、RFC 2047エンコーディングを使用するヘッダーフィールドが含まれる場合があります。このようなメッセージは、暗号化キーにアクセスせずに「完全に」アップグレードすることはできません。
Similar issues may arise if signed messages are downgraded in transit [EAI-downgrade] 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 bodypart headers. When signatures are present, downgrading must be performed with extreme care if at all.
署名されたメッセージがTransit [EAI-DownGrade]でダウングレードされ、元のフォームにアップグレードして署名を確認する試みが行われた場合、同様の問題が発生する場合があります。アルゴリズムがダウングレードしてから再びアップグレードすることから生じる可能性のある非常に微妙な変更でさえ、プライマリまたは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 vanity host user.domain.example with its Web space at <http://user.domain.example> and the catchall addresses any.thing.goes@user.domain.example.
ローカルパーツは、ドメインラベルを構築するために使用されることがあります。たとえば、アドレスのローカルパーツ「ユーザー」は、user@domain.exampleのローカルパーツ「ユーザー」をbanityホストユーザーに変換できます。domain.example>およびCatchallは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 such as the <utf8-local-part> specified in [EAI-UTF8]. Whether this issue is 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ルールによって明らかに制限されており、[EAI-UTF8]で指定された<UTF8-ローカルパート>などの他のローカルパーツのさらなる制限なしには機能しません。この問題がこれらの仕様に関連するかどうかは、未解決の問題です。それは、彼らが受け入れるメールボックス名とそれらがどのように解釈されるかを決定する際に、配信MTAに与えられたかなりの柔軟性の別のケースかもしれません。
Some applications use formats similar to the application/mbox format defined in [RFC4155] instead of the message/digest RFC 2046, Section 5.1.5 [RFC2046] form to transfer multiple messages as single units. Insofar as such applications assume that all stored messages use the message/rfc822 RFC 2046, Section 5.2.1 [RFC2046] format with US-ASCII 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]フォームの代わりに[RFC4155]で定義されているアプリケーション/MBOX形式と同様の形式を使用して、複数のメッセージを単一ユニットとして転送します。そのようなアプリケーションは、すべての保存されたメッセージがメッセージ/RFC822 RFC 2046、セクション5.2.1 [RFC2046]を使用してUS-ASCIIヘッダーを使用していると仮定している場合、この一連のドキュメントで指定された拡張機能と特別な措置が必要になる場合があります。それらを適切に検出して処理します。
In addition to the simple question of whether the model outlined here can be made to work in a satisfactory way for upgraded systems and provide adequate protection for un-upgraded ones, we expect that actually working with the systems will provide answers to two additional questions: what restrictions such as character lists or normalization should be placed, if any, on the characters that are permitted to be used in address local-parts and how useful, in practice, will downgrading turn out to be given whatever restrictions and constraints that must be placed upon it.
ここで概説されているモデルがアップグレードされたシステムのために満足のいく方法で動作し、アップグレードされていないシステムに適切な保護を提供するかどうかの簡単な質問に加えて、実際にシステムを操作することで、2つの追加の質問に対する回答が得られると期待しています。文字リストや正規化などの制限は、ローカルパートのアドレスで使用されることが許可されているキャラクターに配置する必要があり、実際には、どのように格下げされるかは、どんな制限と制約と制約が必要なものが与えられるかが判明します。その上に置かれた。
This overview description and framework document does not contemplate any IANA registrations or other actions. Some of the documents in the group have their own IANA considerations sections and requirements.
この概要の説明とフレームワークドキュメントは、IANA登録やその他のアクションを想定していません。グループのドキュメントには、独自のIANAに関する考慮事項セクションと要件があります。
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. 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 lower-case works for domain names in URLs, but not 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 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., [RFC4690]) -- and, potentially, some issues with UTF-8 normalization, discussed in [RFC3629], and other transformations. Normalization and other issues associated with transformations and standard forms are also part of the subject of ongoing work discussed in [Net-Unicode], in [IDNAbis-BIDI] and elsewhere. Some issues specifically related to internationalized addresses and 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.
電子メールアドレスとヘッダーの国際化は、必要な拡張機能よりもインターネットの安全性を低くしてはなりません。この一連の仕様に文書化された要件とメカニズムは、一般に、新しいセキュリティの問題を提起しません。彼らは、混乱しやすい文字に関連する問題のレビューを必要とします - 他の場所で徹底的に調査されているトピック（例えば[RFC4690]を参照） - および潜在的に、[RFC3629]で議論されているUTF-8正規化に関するいくつかの問題その他の変換。変換および標準形式に関連する正規化およびその他の問題は、[net-unicode]、[idnabis-bidi]などで議論されている進行中の作業の対象の一部でもあります。このセットの他のドキュメントでは、国際化された住所とヘッダーに特に関連するいくつかの問題について詳しく説明します。ただし、特に、「ダウングレード」メカニズム、または格下げされたアドレスの使用は、国際化されたアドレスと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 message and interpret them as if they were well-formed. If a filter interprets such a message differently than the final MUA, then it may be possible to create a message that appears acceptable under the filter's interpretation but should be rejected under the interpretation given to it by the final MUA. Such attacks already exist 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マークアップ、および特定の画像タイプの無効なコーディングにすでに存在します。
Models for the "downgrading" of messages or addresses from UTF-8 form to some ASCII form, including those described in [EAI-downgrade], pose another special problem and risk. Any system that transforms one address or set of mail header fields into another becomes a point at which spoofing attacks can occur and those who wish to spoof messages might be able to do so by imitating a message downgraded from one with a legitimate original address.
[EAI-DownGrade]に記載されているものを含む、UTF-8フォームからASCII形式へのメッセージまたはアドレスの「ダウングレード」のモデルは、別の特別な問題とリスクをもたらします。1つのアドレスまたはメールヘッダーフィールドを別のアドレスに変換するシステムは、スプーフィング攻撃が発生するポイントになり、スプーフィングメッセージを希望する人は、正当な元のアドレスを持つメッセージから格下げされたメッセージを模倣することでそうすることができます。
In addition, email addresses are used in many contexts other than sending mail, such as for identifiers under various circumstances (see Section 6.3). 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.
さらに、メールアドレスは、さまざまな状況下で識別子など、メールを送信する以外の多くのコンテキストで使用されます（セクション6.3を参照）。これらのそれぞれのコンテキストは、非ASCIIフォームの使用が適切かどうか、どのような特定の問題を提起するかを判断するために、順番に評価する必要があります。
This work will clearly impact any systems or mechanisms that are dependent on digital signatures or similar integrity protection for mail headers (see also the discussion in Section 6.4). Many conventional uses of PGP and S/MIME are not affected since they are used to sign body parts but not headers. On the other hand, the developing work on domain keys identified mail (DKIM [DKIM-Charter]) will eventually need to consider this work and vice versa: while this experiment does not propose to 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 co-exist. In addition, to the degree to which email addresses appear in PKI (Public Key Infrastructure) certificates, 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.
この作業は、デジタル署名またはメールヘッダーの同様の整合性保護に依存するシステムまたはメカニズムに明らかに影響を与えます（セクション6.4の説明も参照）。PGPとS/MIMEの多くの従来の使用は、体の部分に署名するために使用されているがヘッダーではないため、影響を受けません。一方、ドメインキーを識別するドメインキーの開発作業（DKIM [DKIM-Charter]）は最終的にこの作業を検討する必要があり、その逆も同様です。ヘッダーメカニズムでは、2つのプロトコルが共存する場合、問題は最終的に調整および解決する必要があります。さらに、PKI（公開キーインフラストラクチャ）証明書にメールアドレスが表示される程度には、これらの国際化されたアドレスにアドレス指定するために、そのような証明書のアドレス指定をアップグレードする必要があります。これらのアップグレードは、アドレス自体の外観によってスプーフィングの問題に対処する必要があります。
This document, and the related ones, were originally derived from documents by John Klensin and the JET group [Klensin-emailaddr], [JET-IMA]. The work drew inspiration from discussions on the "IMAA" mailing list, sponsored by the Internet Mail Consortium and especially from an early document by Paul Hoffman and Adam Costello [Hoffman-IMAA] that attempted to define an MUA-only solution to the address internationalization problem.
この文書、および関連する文書は、もともとジョン・クレンシンとジェットグループ[クレンシン・エマラドドル]、[Jet-IMA]による文書から派生したものでした。この作品は、インターネットメールコンソーシアムが後援する「IMAA」メーリングリストに関する議論から、特にポール・ホフマンとアダム・コステロ[ホフマン・イマー]による初期の文書からのインスピレーションを引き出しました。問題。
More recent documents have benefited from considerable discussion within the IETF EAI Working Group and especially from suggestions and text provided by Martin Duerst, Frank Ellermann, Philip Guenther, Kari Hurtta, and Alexey Melnikov, and from extended discussions among the editors and authors of the core documents cited in Section 3: Harald Alvestrand, Kazunori Fujiwara, Chris Newman, Pete Resnick, Jiankang Yao, Jeff Yeh, and Yoshiro Yoneya.
より最近の文書は、IETF EAIワーキンググループ内でのかなりの議論、特にMartin Duerst、Frank Ellermann、Philip Guenther、Kari Hurtta、およびAlexey Melnikovから提供された提案とテキストから、およびCoreの編集者と著者の間の拡張的な議論から恩恵を受けています。セクション3で引用されている文書：Harald Alvestrand、Kazunori Fujiwara、Chris Newman、Pete Resnick、Jiankang Yao、Jeff Yeh、Yoshiro Yoneya。
Additional comments received during IETF Last Call, including those from Paul Hoffman and Robert Sparks, were helpful in making the document more clear and comprehensive.
Paul HoffmanとRobert Sparksからのものを含むIETFの最後のコール中に受け取った追加のコメントは、ドキュメントをより明確かつ包括的にするのに役立ちました。
[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年のバージョンはインターネットにとって決定的なままです。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels'", RFC 2119, BCP 14, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年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月。
[DKIM-Charter] IETF, "Domain Keys Identified Mail (dkim)", October 2006, <http://www.ietf.org/ html.charters/dkim-charter.html>.
[dkim-charter] ietf、「ドメインキー識別メール（dkim）」、2006年10月、<http://www.ietf.org/ html.charters/dkim-charter.html>。
[EAI-DSN] Newman, C., "UTF-8 Delivery and Disposition Notification", Work in Progress, January 2007.
[EAI-DSN] Newman、C。、「UTF-8配信および処分通知」、2007年1月、進行中の作業。
[EAI-SMTPext] Yao, J., Ed. and W. Mao, Ed., "SMTP extension for internationalized email address", Work in Progress, June 2007.
[eai-smtpext] yao、J.、ed。and W. Mao、ed。、「国際化されたメールアドレスのSMTP拡張」、2007年6月、進行中の作業。
[EAI-UTF8] Yeh, J., "Internationalized Email Headers", Work in Progress, April 2007.
[eai-utf8] yeh、J。、「国際化された電子メールヘッダー」、2007年4月、進行中の作業。
[EAI-downgrade] Yoneya, Y., Ed. and K. Fujiwara, Ed., "Downgrading mechanism for Internationalized eMail Address (IMA)", Work in Progress, March 2007.
[eai-downgrade] yoneya、y.、ed。and K. Fujiwara、ed。、「国際化された電子メールアドレス（IMA）の格下げメカニズム」、2007年3月、Work in Progress。
[EAI-imap] Resnick, P. and C. Newman, "IMAP Support for UTF-8", Work in Progress, March 2007.
[Eai-Imap] Resnick、P。and C. Newman、「UTF-8のIMAPサポート」、2007年3月、Work in Progress。
[EAI-pop] Newman, C., "POP3 Support for UTF-8", Work in Progress, January 2007.
[EAI-POP] Newman、C。、「UTF-8のPOP3サポート」、2007年1月、進行中の作業。
[EAI-scenarios] Alvestrand, H., "UTF-8 Mail: Scenarios", Work in Progress, February 2007.
[EAI-SCENARIOS] Alvestrand、H。、「UTF-8メール：シナリオ」、2007年2月、作業中。
[Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing Mail Addresses in Applications (IMAA)", Work in Progress, October 2003.
[Hoffman-Imaa] Hoffman、P。and A. Costello、「アプリケーションでのメールアドレス（IMAA）の国際化」、2003年10月の作業。
[IDNAbis-BIDI] Alvestrand, H. and C. Karp, "An IDNA problem in right-to-left scripts", Work in Progress, October 2006.
[Idnabis-bidi] Alvestrand、H。およびC. Karp、「左から左へのスクリプトのIDNA問題」、2006年10月、進行中の作業。
[JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail Address (IMA)", Work in Progress, June 2005.
[Jet-Ima] Yao、J。およびJ. Yeh、「国際化されたメールアドレス（IMA）」、2005年6月、進行中の作業。
[Klensin-emailaddr] Klensin, J., "Internationalization of Email Addresses", Work in Progress, July 2005.
[Klensin-Emailaddr] Klensin、J。、「電子メールアドレスの国際化」、2005年7月の進行中。
[Net-Unicode] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", Work in Progress, March 2007.
[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月。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[RFC3028] Showalter、T。、「Sieve：A Mail Filtering Language」、RFC 3028、2001年1月。
[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月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[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]ホール、E。、「アプリケーション/MBOXメディアタイプ」、RFC 4155、2005年9月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[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月。
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 ICU 119 Munjiro Yuseong-gu, Daejeon 305-732 Republic of Korea
Yangwoo Ko ICU 119 Munjiro Yusongu、Daejeon 305-732韓国共和国
EMail: yw@mrko.pe.kr
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。