Internet Engineering Task Force (IETF) R. Gellens
Request for Comments: 5983 Qualcomm
Category: Experimental October 2010
ISSN: 2070-1721
Mailing Lists and Internationalized Email Addresses
Abstract
抽象
This document describes considerations for mailing lists with the introduction of internationalized email addresses.
この文書では、国際化電子メールアドレスの導入とメーリングリストのための考慮事項について説明します。
This document makes some specific recommendations on how mailing lists should act in various situations.
この文書では、メーリングリストは、様々な状況で行動すべきかについて、いくつかの具体的な提言を行います。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5983.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5983で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. Scenarios Involving Mailing Lists ...............................4
4. Capabilities and Requirements ...................................5
5. List Header Fields ..............................................6
6. Further Discussion ..............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
This document describes considerations for mailing lists with the introduction of internationalized email addresses [RFC5335].
この文書では、国際化電子メールアドレス[RFC5335]の導入により、メーリングリストのための考慮事項について説明します。
Mailing lists are an important part of email usage and collaborative communications. The introduction of internationalized email addresses affects mailing lists in three main areas: (1) transport (receiving and sending messages), (2) message headers of received and retransmitted messages, and (3) mailing list operational policies.
メーリングリストは、電子メールの使用状況やコラボレーティブコミュニケーションの重要な部分です。国際化電子メールアドレスの導入は3つの主要分野にメーリングリストに影響を与えます：（1）輸送（メッセージの送受信）、（2）メッセージの受信と再送信されたメッセージのヘッダ、および（3）メーリングリスト運用方針。
A mailing list is a mechanism whereby a message may be distributed to multiple recipients by sending to one address. An agent (typically not a human being) at that single address receives the message and then causes the message to be redistributed to a list of recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original message. Using a different envelope return address (reverse-path) directs error (and other automatically generated) messages to an error handling address associated with the mailing list. (This avoids having error and other automatic messages go to the original sender, who typically doesn't control the list and hence can't do anything about them.)
メーリングリストは、メッセージが一つのアドレスに送信することにより、複数の受信者に配布することができる機構です。その単一のアドレスでエージェントが（典型的には人間）メッセージを受信し、メッセージが受信者のリストに再配布されるようにします。このエージェントは、元のメッセージとは異なるアドレスに再配分メッセージのエンベロープのリターンアドレスを設定します。異なるエンベロープリターンアドレスを使用して（リバースパス）メーリング・リストに関連付けられたエラー処理アドレスにエラー（および他の自動的に生成された）メッセージを送ります。 （これは、エラーやその他の自動メッセージは、通常、リストを制御しないので、それらについては何もできない元の送信者、に行く必要がなくなります。）
In most cases, the mailing list agent redistributes a received message to its subscribers as a new message, that is, conceptually it uses message submission [submission] (as did the sender of the original message). The exception, where the mailing list is not a separate agent that receives and redistributes messages in separate transactions, but is instead an expansion step within an SMTP transaction where one local address expands to multiple local or non-local addresses, is out of scope for this document.
（元のメッセージの送信者をしたとして）ほとんどの場合、メーリングリスト剤である新規メッセージとしてその加入者に受信したメッセージを再配布、概念的には、メッセージ送信[提出]を使用しています。メーリングリストが別のトランザクション内のメッセージを受信し、再分配別個剤ではなく、一つのローカルアドレスは、複数のローカルまたは非ローカルアドレスに展開SMTPトランザクション内の拡張ステップで例外は、の範囲外でありますこのドキュメント。
Some mailing lists alter message header fields, while others do not. A number of standardized list-related header fields have been defined, and many lists add one or more of these header fields. Separate from these standardized list-specific header fields, and despite a history of interoperability problems from doing so, some lists alter or add header fields in an attempt to control where replies are sent. Such lists typically add or replace the "Reply-To" field and some add or replace the "Sender" field. Poorly behaved lists may alter or replace other fields, including "From".
他の人がいない間、いくつかのメーリングリストは、メッセージヘッダーフィールドを変更します。標準化されたリストに関連したヘッダフィールドの数が定義されている、と多くのリストは、これらのヘッダフィールドの一つ以上を追加します。これらの標準化されたリストに固有のヘッダフィールドから独立し、そうすることから、相互運用性の問題の歴史にもかかわらず、いくつかのリストは、返信の送信先を制御するための試みでヘッダフィールドを変更したり、追加します。このようなリストは、通常、追加または置換「返信先」フィールドを、いくつかの追加や、「送信者」フィールドを置き換えます。不十分な行儀のリストは、「から」など、他のフィールドを、変更または交換することができます。
Among these list-specific header fields are those specified in RFC 2369 ("The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields") [List-*] and RFC 2919 ("List-Id: A Structured Field and Namespace for the Identification of Mailing Lists") [List-ID]. For more information, see Section 5.
これらのリストに固有のヘッダフィールドの中で、RFC 2369で指定されたもの（「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」）[リスト - *]とRFC 2919（「リスト-Idがあります：メーリングリストの識別のための構造化フィールドと名前空間」）[リスト-ID]。詳細については、第5章を参照してください。
While the mail transport protocol does not differ between regular email recipients and mailing list recipients, lists have special considerations with internationalized email addresses because they retransmit messages composed by other agents to potentially many recipients.
メール転送プロトコルは、通常の電子メール受信者やメーリングリストの受信者間で違いはありませんが、彼らは潜在的に多くの受信者に他のエージェントで構成メッセージを再送するので、リストは、国際化電子メールアドレスを持つ特別な考慮事項があります。
There are considerations for internationalized email addresses in the envelope as well as in header fields of redistributed messages. In particular, an internationalized message cannot be downgraded unless all envelope addresses are available in ASCII (that is, each address either is ASCII or has an alt-address [UTF8SMTP]).
エンベロープ内だけでなく、再配布メッセージのヘッダフィールドにおける国際化電子メールアドレスのための考慮事項があります。具体的には、国際化されたメッセージは、すべてのエンベロープアドレスない限り、ダウングレードすることができない（すなわち、各アドレスはASCIIであるか、またはALT-アドレス[UTF8SMTP]を有するいずれかである）ASCIIで利用可能です。
With mailing lists, there are two different types of considerations: first, the purely technical ones involving message handling, error cases, downgrades, and the like; and second, those that arise from the fact that humans use mailing lists to communicate. As an example of the first, mailing lists might choose to reject all messages from internationalized addresses that lack an alt-address, or even all internationalized messages that cannot be downgraded. As an example of the second, a user who sends a message to a list often is unaware of the list membership. In particular, the user often doesn't know if the members are UTF-8 mail users or not, and often neither the original sender nor the recipients personally know each other. As a consequence of this, remedies that may be readily available for a missed email in one-to-one communications might not be appropriate when dealing with mailing lists. For example, if a user sends a message that is undeliverable, normally the telephone, instant messaging, or other forms of communication are available to obtain a working address. With mailing lists, the users may not have any recourse. Of course, with mailing lists, the original sender usually does not know if the message was successfully received by any list members or if it was undeliverable to some.
メーリングリストでは、検討事項の2つのタイプがあります：最初、メッセージ処理、エラーの場合、ダウングレードなどを含む純粋に技術的なもの。そして第二に、人間が通信するためにメーリングリストを使用しているという事実に起因するもの。最初の例として、メーリングリストは、ALT-アドレス、またはダウングレードできない場合でも、すべての国際化されたメッセージが不足している国際アドレスからのすべてのメッセージを拒否することもできます。第二の例として、多くの場合、リストにメッセージを送信するユーザーがリストのメンバーシップを認識しません。特に、メンバーはUTF-8メールユーザーまたはされていない場合、ユーザーは、多くの場合、知らない、と多くの場合、元の送信者や受信者のいずれもが個人的にお互いを知っています。メーリングリストを扱うときにこの結果として、1対1通信で逃した電子メールのために容易に利用できる救済措置は適切ではないかもしれません。ユーザは、配信不能なメッセージを送信した場合、例えば、通常の電話、インスタントメッセージ、または通信の他の形態は、作業用アドレスを取得するために利用可能です。メーリングリストでは、ユーザーが任意の償還請求権を持っていないかもしれません。もちろん、メーリングリストで、メッセージが正常に任意のリストのメンバーによって受信された場合、元の送信者は通常、知らないか、それはいくつかの配信不能だった場合。
Conceptually, a mailing list's internationalization can be divided into three capabilities: First, does it have a UTF-8 submission or return-path address? Second, does it accept subscriptions to UTF-8 addresses? And third, does it accept [UTF8SMTP] messages? This is explored in Section 4.
概念的には、メーリングリストの国際化は3つの機能に分けることができます：まず、それはUTF-8提出またはリターンパスアドレスを持っているのですか？第二に、それはUTF-8のアドレスにサブスクリプションを受け入れていますか？そして第三に、それは[UTF8SMTP]メッセージを受け付けていますか？これは、第4節で検討されます。
A brief discussion on a few additional considerations for mailing list operation is in Section 6.
メーリングリストの操作のためのいくつかの追加の考慮事項についての簡単な議論は、第6節です。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Generally (and exclusively within the scope of this document), an original message is sent to a mailing list as a completely separate and independent transaction from the mailing list agent sending the retransmitted message to one or more list recipients. In both cases, the message might have only one recipient, or might have multiple recipients. That is, the original message might be sent to additional recipients as well as the mailing list agent, and the mailing list might choose to send the retransmitted message to each list recipient in a separate message submission [submission] transaction, or it might choose to include multiple recipients per transaction. (Often, mailing lists are constructed to work in cooperation with, rather than include the functionality of, a message submission server [submission], and hence the list transmits to a single submission server one copy of the retransmitted message, with all list recipients specified in the SMTP envelope. The submission server then decides which recipients to include in which transaction.)
一般に（排他的この文書の範囲内）、元のメッセージは、一つ以上のリストの受信者に再送信メッセージを送信するメーリングリスト剤から完全に分離し、独立したトランザクションとしてメーリングリストに送信されます。どちらの場合も、メッセージは一つだけの受信者を持っている可能性がある、または複数の受信者がある場合があります。これは、元のメッセージには、追加の受信者だけでなく、メーリングリストのエージェントに送信される可能性がありますされ、メーリング・リストには、別のメッセージ提出[提出]トランザクション内の各リストの受信者に再送信されたメッセージを送信することを選択するかもしれない、またはそれが選択できますトランザクションごとに複数の受信者が含まれます。 （多くの場合、メーリングリストは、連携して動作するのではなく、指定されたすべてのリストの受信者と、単一の提出サーバに再送メッセージの一つのコピーを送信する機能、メッセージ送信サーバ[提出]、したがってリストを含むように構成されていますSMTPエンベロープで。提出サーバは、どのトランザクションに含める受信者を決定します。）
The retransmitted message sent by the mailing list to its subscribers might need to be downgraded [EAI-Downgrade]. In order for a downgrade to be possible, the return path set by the mailing list agent must be an ASCII address or have an alt-address [UTF8SMTP] specified. In addition, the recipient addresses need to have ASCII addresses available. It may be advisable for mailing list operators to pre-obtain an alt-address for all its internationalized member addresses.
その加入者にメーリングリストで送られた再送信されたメッセージは、[EAI-ダウングレード]ダウングレードする必要があるかもしれません。ダウングレードが可能であるためには、メーリングリストのエージェントによって設定されたリターンパスはASCIIアドレスであるか、Alt-アドレスは[UTF8SMTP]指定されている必要があります。また、受信者のアドレスは、利用可能なASCIIアドレスを持っている必要があります。これは、すべての国際メンバーのアドレスのために、ALT-アドレスを事前に取得するリスト演算子を郵送するための賢明かもしれません。
In the case where a member or non-member with an internationalized email address is sending to a mailing list, no alt-address [UTF8SMTP] is specified, and a downgrade is required, the message cannot be delivered. To protect against this, a UTF8SMTP-aware [UTF8SMTP] mailing list might prefer to reject submissions from internationalized email addresses that lack an alt-address.
国際メールアドレスを会員または非会員は、メーリングリストに送信された場合には、何のALT-アドレスは[UTF8SMTP]指定されていない、およびダウングレードが必要とされる、メッセージを配信することができません。これを防ぐために、UTF8SMTP認識[UTF8SMTP]メーリングリストはALT-アドレスが不足している国際化電子メールアドレスからの投稿を拒否することを好むかもしれません。
(Note that this situation is not unique to mailing lists. Mail relays that are UTF8SMTP-aware will potentially encounter the same situation.) Further discussions are included in Section 6 of this document.
（この状況はメーリングリストに特有のものではないことに注意してください。UTF8SMTP-認識しているメールリレーが潜在的に同じような状況が発生します。）さらに議論がこのドキュメントのセクション6に含まれています。
There are three primary internationalization capabilities of mailing lists: First, does it have a UTF-8 submission or return-path address? Second, does it allow subscriptions from UTF-8 addresses? And third, does it accept [UTF8SMTP] messages?
メーリングリストの3つの主要な国際化機能があります。第一に、それはUTF-8提出またはリターンパスアドレスを持っているのですか？第二に、それはUTF-8のアドレスからのサブスクリプションを許可していますか？そして第三に、それは[UTF8SMTP]メッセージを受け付けていますか？
In theory, any list can support any combination of these. In practice, only some offer any benefit. For example, neither allowing UTF-8 addresses to subscribe, nor accepting UTF8SMTP messages, makes much sense without the other (an all-ASCII address might or might not be capable of receiving UTF8SMTP messages, but a UTF-8 address of necessity needs to accept UTF8SMTP messages). Likewise, there is no real benefit to a list in using a UTF-8 submission address unless it also accepts UTF8SMTP messages and permits UTF-8 addresses to subscribe.
理論的には、任意のリストは、これらの任意の組み合わせをサポートすることができます。実際には、唯一のいくつかは、任意の利点を提供します。例えば、どちらもUTF-8のアドレスを購読することができない、またUTF8SMTPメッセージを受け入れ、他の（すべて-ASCIIアドレスかもしれなくてずっと理にかなっているかUTF8SMTPメッセージを受信することができないかもしれませんが、必要のUTF-8のアドレスをする必要があります）UTF8SMTPメッセージを受け入れます。それはまたUTF8SMTPメッセージを受け取り、購読するUTF-8のアドレスを許可しない限り、同様に、UTF-8提出アドレスを使用して、リストへの本当の利点はありません。
However, requirements for lists can be discussed separately for each of the three capabilities.
ただし、リストの要件は3つの機能ごとに分けて議論することができます。
1. If the list uses a UTF-8 submission or return-path address, it SHOULD specify an alt-address [UTF8SMTP] for it. Clearly, it needs to sit behind a UTF8SMTP-enabled final-delivery SMTP server
1.リストはUTF-8提出またはリターンパスアドレスを使用している場合、それは[UTF8SMTP]それのためのALT-アドレスを指定する必要があります。明らかに、それはUTF8SMTP対応の最終配信SMTPサーバーの背後に座ってする必要があります
[UTF8SMTP] and delivery agent. Likewise, if a list uses a UTF-8 return-path address, then its Message Submission Agent (MSA) [submission] needs to support UTF8SMTP.
【UTF8SMTP]と送達剤。リストには、UTF-8リターンパスアドレスを使用している場合は同様に、そのメッセージ服従エージェント（MSA）[提出]はUTF8SMTPをサポートする必要があります。
The list's return-path address is usually separate from its submission address (so that delivery reports and other automatically generated messages are not sent to the submission address). For reliability in receiving delivery status notifications, a list MAY choose to use an all-ASCII return path even if it uses a UTF-8 submission address. If the list does use a UTF-8 return path, it MUST specify an alt-address [UTF8SMTP] (or else there is a high risk of being unable to receive non-delivery reports).
リストのリターンパスアドレスは、（配信レポートおよびその他の自動生成されたメッセージを投稿アドレスに送信されないように）通常、その提出アドレスとは別です。配信状態通知を受信する際に、信頼性のために、リストには、それがUTF-8提出アドレスを使用している場合でも、すべての-ASCIIのリターンパスを使用することもできます。リストには、UTF-8のリターンパスを使用しない場合は、[UTF8SMTP] ALT-アドレスを指定する必要があります（または他の配信不能レポートを受信できなくなる危険性が高いです）。
There are also implications for the List-* header fields (see below).
リスト - *ヘッダフィールドのための含意は、（下記参照）もあります。
2. If it allows UTF-8 addresses to subscribe, it MAY require an alt-address [UTF8SMTP] to be specified for each UTF-8 subscriber.
それはUTF-8のアドレスがサブスクライブすることを可能にする場合2.、それはALT-アドレスは[UTF8SMTP各UTF-8加入者に対して指定することが必要な場合があります。
Naturally, if it permits UTF-8 addresses to subscribe, it needs a mechanism to accept subscription requests from such addresses (preferably specified in the form <utf8@utf8 <ascii@ascii>>). In order to send email to its subscribers who have UTF-8 addresses, its MSA needs to support [UTF8SMTP].
それがサブスクライブするUTF-8のアドレスを許可する場合は当然、それは（好ましくは<UTF8 UTF8 @ <アスキーアスキー@ >>形式で指定された）そのようなアドレスからのサブスクリプション要求を受け入れるための仕組みが必要です。 UTF-8のアドレスを持って、その加入者に電子メールを送信するためには、そのMSAは[UTF8SMTP]をサポートする必要があります。
3. If it accepts UTF8SMTP messages, the Message Transfer Agents (MTAs) and Mail Delivery Agent (MDA) in its inbound path need to support UTF8SMTP.
3.それはそのインバウンドパスにUTF8SMTPメッセージ、メッセージ転送エージェント（MTA）とメール配送エージェント（MDA）を受け入れた場合UTF8SMTPをサポートする必要があります。
A number of header fields, specifically for mailing lists, have been introduced in RFCs 2369 and 2919. For example, these include:
具体的にはメーリングリストのヘッダフィールドの数は、例えば、のRFC 2369と2919に導入されており、これらは：
List-Id: List Header Mailing List <list-header.example.com> List-Help: <mailto:list@example.com?subject=help> List-Unsubscribe: <mailto:list@example.com?subject=unsubscribe> List-Subscribe: <mailto:list@example.com?subject=subscribe> List-Post: <mailto:list@example.com> List-Owner: <mailto:listmom@example.com> (Contact Person for Help) List-Archive: <mailto:archive@example.com?subject=index%20list>
一覧-ID：一覧<list-header.example.com>一覧 - ヘルプメーリングリストヘッダー：<mailtoの：？list@example.com対象=ヘルプ>リスト-解除：<mailtoの：？list@example.com対象=退会>リスト-購読：<mailtoの：list@example.com対象=購読>リスト-ポスト：<？のmailto：list@example.com>リスト - 所有者：<mailtoの：listmom@example.com>（ヘルプ用コンタクトパーソン）一覧-アーカイブ：<mailtoの：？archive@example.com対象=インデックス％の20list>
As described in RFC 2369, "The contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored" [List-*]. For List-ID, RFC 2919 specifies that, "The list identifier will, in most cases, appear like a host name in a domain of the list owner" [List-ID].
RFC 2369に記載されているように、[リスト - *]「をリスト・ヘッダ・フィールドの内容は、ほとんど無視されて内部の空白と角括弧（ 『<』、 『>』）囲まれたURL、から成ります」。一覧-IDについては、RFC 2919には、[リスト-ID]「リスト識別子は、ほとんどの場合、リストの所有者のドメインでホスト名のように表示される」ことを指定します。
Except for the List-ID header field, these mailing list header fields contain URLs [RFC3986]. The most common schemes are generally HTTP, HTTPS, mailto, and FTP. Schemes that permit both URI and Internationalized Resource Identifier (IRI) [IRI] forms should use the URI-encoded form described in [IRI]. Future work may extend these header fields or define replacements to directly support non-encoded UTF-8 in IRIs (for example, [mailto-bis]), but in the absence of such extension or replacement, non-ASCII characters can only appear within when encoded as ASCII. Note that discussion on whether internationalized domain names should be percent encoded or puny coded is ongoing; see [IRI-bis].
一覧-IDヘッダフィールドを除いて、これらのメーリングリストのヘッダフィールドは、URL [RFC3986]を含んでいます。最も一般的なスキームは、一般的にHTTP、HTTPS、mailtoの、およびFTPです。フォームは[IRI]に記載URIエンコード形式を使用しなければならない[IRI] URI及び国際化リソース識別子（IRI）の両方を可能にする方式。今後は、これらのヘッダフィールドを拡張するか、または直接虹彩コードされていないUTF-8をサポートするために、置換を定義する（例えば、[mailtoのビス]）、そのような拡張または交換の非存在下で、非ASCII文字のみ以内表示されることができますASCIIとしてエンコードされたとき。国際化ドメイン名が％が符号化されるべきか、ちっぽけな符号化が進行中であるか否かでその説明を注意してください。 [IRI-ビス]参照。
Even without these header fields being extended to support UTF-8, some special provisions may be helpful when downgrading. In particular, if a List-* header field contains a UTF-8 mailto (even encoded in ASCII) followed by an ASCII mailto, it may be advisable not only to copy and preserve the original header field as usual (ENCAPSULATION method of [EAI-Downgrade]), but also to edit the header field to remove the UTF-8 address. Otherwise, a client might run into trouble if the decoded mailto results in a non-ASCII address.
ダウングレードする場合にも、これらのヘッダフィールドはUTF-8をサポートするように拡張されることなく、いくつかの特別な規定が有用であり得ます。リスト - *ヘッダフィールドはUTF-8のmailto（さえASCIIで符号化された）ASCIIのmailto続くを含む場合[EAIをコピーし、（通常通りのカプセル化方式を元のヘッダフィールドを保存するだけでなく、特に、それが賢明であり得ます-downgrade]）だけでなく、UTF-8のアドレスを削除するヘッダフィールドを編集します。そうでない場合、クライアントは、非ASCIIアドレスでデコードされたmailtoの結果ならば、トラブルに遭遇するかもしれません。
When mailing lists use a UTF-8 form of a List-* header field, an ASCII form SHOULD also be used. These header fields are vital to good operations and use of mailing lists; caution is called for when considering how to form and use these header fields in a non-ASCII environment.
メーリングリストのリスト - *ヘッダフィールドのUTF-8形式を使用する場合は、ASCII形式でも使用する必要があります。これらのヘッダフィールドは、優れた操作やメーリングリストの利用に不可欠です。注意を形成し、非ASCII環境でこれらのヘッダフィールドを使用する方法を検討する際に呼び出されます。
The most commonly used URI schemes in List-* header fields tend to be HTTP and mailto. The current specification for mailto does not permit unencoded UTF-8 characters, although work has been proposed to extend or more likely replace mailto in order to permit this. For mailto URIs, a separate consideration is how to include an alternate ASCII address (alt-address) [UTF8SMTP] for a UTF-8 address. Note that the existing ability to specify multiple URLs within each List-* header field provides one solution.
リスト - *ヘッダフィールドの中で最も一般的に使用されるURIスキームはHTTPとのmailtoになる傾向があります。仕事が拡張または可能性が高いこれを可能にするためにのmailtoを交換することが提案されているものの、mailtoのための現在の仕様では、エンコードされていないUTF-8文字を許可しません。 MAILTO URIのために、別の考慮事項は、UTF-8アドレスの代替ASCIIアドレス（ALT-アドレス）[UTF8SMTP]を含む方法です。各リスト - *ヘッダフィールド内に複数のURLを指定する既存の能力が一つの解決策を提供することに留意されたいです。
[List-*] says:
[リスト - *]は言います：
A list of multiple, alternate, URLs MAY be specified by a comma-separated list of angle-bracket enclosed URLs. The URLs have order of preference from left to right. The client application should use the left most protocol that it supports, or knows how to access by a separate application.
複数の、代替のリスト、URLはアングルブラケット囲まれたURLのカンマ区切りリストによって指定することができます。 URLは、左から右への優先順位を持っています。クライアント・アプリケーションは、それがサポートしている、または別のアプリケーションによってアクセスする方法を知っている一番左のプロトコルを使用する必要があります。
When a UTF-8 mailto is used in a List-* header field, an alt-address [UTF8SMTP], if available, SHOULD be supplied.
UTF-8のmailtoをリスト - *ヘッダフィールドで使用する場合、ALT-アドレスは[UTF8SMTP]、利用可能な場合、供給されるべきです。
The List-ID header field provides an opaque value that uniquely identifies a list. The intent is that the value of this header field remain constant, even if the machine or system used to operate or host the list changes. This header field is often used in various filters and tests, such as client-side filters, Sieve filters, and so forth. Such filters and tests may not properly compare a non-ASCII value that has been encoded into ASCII. In addition to these comparison considerations, it is generally desirable that this header field contain something meaningful that users can type in. However, ASCII encodings of non-ASCII characters are unlikely to be meaningful to users or easy for them to accurately type.
リスト-IDヘッダフィールドは、一意のリストを識別する不透明な値を提供します。意図は、このヘッダーフィールドの値は、機械またはシステムが動作するか、リストの変更をホストするために使用される場合であっても、一定のままであることです。このヘッダーフィールドは、多くの場合、等クライアント側フィルター、ふるいフィルタ、等の各種フィルタやテストに使用されています。このようなフィルタとテストは正しくASCIIにエンコードされた非ASCII値を比較しないことがあります。これらの比較検討事項に加えて、それはこのヘッダーフィールドは、ユーザーが入力できることを意味のあるものを含んでいることが一般的に望ましい。しかし、非ASCII文字のASCIIエンコーディングは、それらを正確に入力するためのユーザーにとって意味のか、簡単ではないようです。
While mailing lists do not create a significant additional burden to the deployment of internationalized email address functionalities, there are some specific areas that need to be considered when the operator of a mailing list or of a final delivery MTA that serves a mailing list upgrades to internationalized mail.
メーリングリストは、国際化電子メールアドレスの機能の展開に重要な追加負担を作成しませんが、検討する必要があるいくつかの特定の領域があるとき、メーリングリストのか、国際化にメーリングリストのアップグレードを提供しています最終的な配送のMTAのオペレータ郵便物。
Mailing lists face additional complexity since they redistribute messages composed by other agents. Hence, they may be asked to accept a message with non-ASCII header fields composed by a UTF8SMTP-aware user agent [UTF8SMTP] and redistribute it to UTF-8 mail and all-ASCII mail users via systems that are not UTF8SMTP-aware.
彼らは他のエージェントで構成メッセージを再配布するため、メーリングリストは、追加の複雑さに直面しています。したがって、彼らは[UTF8SMTP] UTF8SMTP認識ユーザエージェントによって構成される非ASCIIヘッダーフィールドを持つメッセージを受け入れ、UTF8SMTP-認識していないシステムを介して、UTF-8メール、全ASCIIメールユーザに再配布するように求めてもよいです。
1. Obtaining Downgrade Information -- for a mailing list, or mail relay server for that matter, which is UTF8SMTP-aware, receiving mail from an internationalized email address, the alt-address [UTF8SMTP] is not required from the sending MTA for the transport to be complete. When the mailing list then retransmits the message to its subscribers, it may encounter paths where a downgrade is needed (if a relay or final MSA does not supports UTF8SMTP). In order to mitigate this situation, the mailing list might perhaps decide to reject all incoming mail from an internationalized email address that lacks an alt-address. However, note that in general, downgrades are not expected to be the normal case.
1.ダウングレード情報取得 - 国際化電子メールアドレスからのメールを受信、UTF8SMTP-認識してそのことについては、メーリングリスト、またはメールリレーサーバー用に、ALT-アドレスは[UTF8SMTP]のために送信MTAから必要とされていません輸送は完全なものにします。メーリングリストは、その加入者にメッセージを再送信すると、それは（リレーまたは最終MSAはUTF8SMTPをサポートしていない場合）ダウングレードが必要とされているパスが発生することがあります。このような状況を軽減するために、メーリングリストは、おそらくALT-アドレスを欠いた国際メールアドレスからのすべての受信メールを拒否することを決定するかもしれません。しかし、一般的には、ダウングレードが正常な場合であることが予想されていないことに注意してください。
2. Downgrading Considerations for mailto URLs -- UTF-8 addresses in mailto links in List-* header fields will be easier to downgrade if they contain an alt-address [UTF8SMTP].
彼らはALT-アドレス[UTF8SMTP]が含まれている場合*ヘッダフィールドをダウングレードすることが容易になりますリスト - でのmailtoリンクでUTF-8のアドレス - 2のmailto URLの考慮事項をダウングレード。
Because use of both a UTF-8 address and an alt-address for the same entity introduces a potential ambiguity regarding the identity of list subscribers and message senders, implementers are advised to carefully handle authorization decisions regarding subscriptions, sender filters, and other common list administration features. For example, a binding between a UTF-8 address and an ASCII alt-address can be used by an attacker to deny another person admission to an Email Address Internationalization (EAI) mailing list.
UTF-8のアドレスと同じエンティティに対するALT-アドレスの両方を使用すると、リストの加入者とメッセージ送信者の身元に関する潜在的なあいまいさを紹介しているので、実装者は慎重にサブスクリプション、送信者のフィルタ、およびその他の一般的なリストについては、認可の決定を扱うことをお勧めします管理機能。たとえば、UTF-8のアドレス間の結合とASCIIのALT-アドレスは、メールアドレスの国際化（EAI）メーリングリストに別の人の入場を拒否するために、攻撃者によって使用することができます。
Other relevant security considerations are discussed in the Framework document [EAI-Framework].
その他の関連するセキュリティの考慮事項は、フレームワークドキュメント[EAI-フレームワーク]で議論されています。
Edmon Chung of Afilias wrote the original version of this document. Thanks to Harald Alvestrand for his extensive comments. Ted Hardie contributed helpful text on IRIs. Last-Call comments from S. Moonesamy and Amanda Baber, plus shepherd review by Pete Resnick, improved the document.
Afiliasのエドモンチャンは、このドキュメントのオリジナルバージョンを書きました。彼の豊富なコメントについてハラルドAlvestrandに感謝します。テッドハーディーアイリスに役立つテキストを寄付しました。ピート・レズニックによって最終コールS. MoonesamyとアマンダBaberからのコメント、プラス羊飼いのレビューは、ドキュメントを改善しました。
[EAI-Framework] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[EAI-フレームワーク] Klensin、J.とY.コ、 "国際電子メールのための概要とフレームワーク"、RFC 4952、2007年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[List-*] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[リスト - *]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[List-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[リスト-ID] Chandhok、R.とG.ウェンガー、 "リスト-ID：メーリングリストの識別のための構造化フィールドと名前空間"、RFC 2919、2001年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y.、エド。、 "国際電子メールヘッダ"、RFC 5335、2008年9月。
[submission] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提出] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[UTF8SMTP] Yao, J., Ed., and W. Mao, Ed., "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[UTF8SMTP]八尾、J.、エド。、およびW.真央、エド。、 "国際化メールアドレスのSMTP拡張"、RFC 5336、2008年9月。
[EAI-Downgrade] Fujiwara, K., Ed., and Y. Yoneya, Ed., "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[EAI-ダウングレード]藤原、K.、エド。、およびY.米谷、エド。、RFC 5504、2009年3月、 "メールアドレスの国際化のためのメカニズムをダウングレード"。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[IRI-bis] Duerst, M., Suignard, M., and L. Masinter, "Internationalized Resource Identifiers (IRIs)", Work in Progress, July 2010.
[IRI-UP] Duerst、M.、Suignard、M、及びL.瑪斯ケア、 "国際化リソース識別Fiers（IRI）"、進歩、2010年7月ワーク。
[mailto-bis] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", Work in Progress, May 2010.
[mailtoのアップ] Duerst、M、瑪斯ケア、L.、およびJ. Zawinski、 " 'のmailto' URIスキーム"、進歩、2010年5月での作業。
Author's Address
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 rg+ietf@qualcomm.com
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121 rg+ietf@qualcomm.com