RFC 5983 - Mailing Lists and Internationalized Email Addresses 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5983
タイトル : RFC 5983 - メーリングリストと国際化されたメールアドレス
翻訳編集 : 自動生成

[要約] RFC 5983は、国際化されたメーリングリストとメールアドレスに関するガイドラインです。その目的は、異なる言語や文字セットを使用するユーザーがメーリングリストに参加し、国際化されたメールアドレスを使用できるようにすることです。

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.

このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc5983.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5983で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。

Table of Contents

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

1. Introduction

1. はじめに

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

メーリングリストは、1つのアドレスに送信することにより、複数の受信者にメッセージを配布できるメカニズムです。その単一アドレスのエージェント（通常は人間ではありません）がメッセージを受け取り、メッセージを受信者のリストに再配布します。このエージェントは、元のメッセージとは別のアドレスに再配布されたメッセージの封筒返信アドレスを設定します。別のエンベロープ返信アドレス（リバースパス）を使用すると、メーリングリストに関連付けられたエラー処理アドレスにエラー（およびその他の自動生成された）メッセージを指示します。（これにより、エラーが発生し、他の自動メッセージが元の送信者に送られます。これらは通常、リストを制御せず、したがってそれらについて何もできません。）

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.

ほとんどの場合、メーリングリストエージェントは、受信したメッセージを購読者に新しいメッセージとして再配置します。つまり、概念的にはメッセージ送信[提出]を使用します（元のメッセージの送信者と同様）。例外。メーリングリストは、個別のトランザクションでメッセージを受信および再配分する別のエージェントではなく、1つのローカルアドレスが複数のローカルまたは非ローカルアドレスに拡張する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".

一部のメーリングリストはメッセージヘッダーフィールドを変更しますが、他のメーリングリストはそうではありません。多くの標準化されたリスト関連のヘッダーフィールドが定義されており、多くのリストがこれらのヘッダーフィールドの1つ以上を追加しています。これらの標準化されたリスト固有のヘッダーフィールドとは別に、そしてそれからの相互運用性の問題の履歴にもかかわらず、いくつかのリストは、返信の送信先を制御するためにヘッダーフィールドを変更または追加します。このようなリストは通常、「返信」フィールドを追加または交換し、一部は「送信者」フィールドを追加または交換します。動作が不十分なリストは、「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の使用とメッセージヘッダーフィールドを介したトランスポート」[List-*]およびRFC 2919（ "List-id]：メーリングリストの識別のための構造化されたフィールドと名前空間 "）[list-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で利用可能でない限り、国際化されたメッセージを格下げすることはできません（つまり、各アドレスはASCIIまたはAlt-Address [UTF8SMTP]のいずれかです）。

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-Addressを欠いている国際化された住所から、または格下げできないすべての国際化されたメッセージからすべてのメッセージを拒否することを選択する場合があります。2番目の例として、リストにメッセージを送信するユーザーは、多くの場合、リストメンバーシップを知らないことがよくあります。特に、ユーザーは多くの場合、メンバーが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にあります。

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。

3. Scenarios Involving Mailing Lists

3. メーリングリストを含むシナリオ

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

一般的に（およびこのドキュメントの範囲内でのみ）、元のメッセージがメーリングリストに送信され、メーリングリストエージェントから完全に独立したトランザクションとして送信されます。どちらの場合も、メッセージには受信者が1人しかないか、複数の受信者がいる場合があります。つまり、元のメッセージは追加の受信者とメーリングリストエージェントに送信される場合があり、メーリングリストは、別のメッセージ送信[提出]トランザクションで各リスト受信者に再送信メッセージを送信することを選択できます。トランザクションごとに複数の受信者を含めます。（多くの場合、メーリングリストは、メッセージ送信サーバー[提出]の機能を含めるのではなく、協力して機能するように構築されているため、リストは再送信メッセージの1つのコピーを単一の提出サーバーに送信します。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-downgrade]ダウングレードする必要がある場合があります。ダウングレードを可能にするために、メーリングリストエージェントによって設定されたリターンパスは、ASCIIアドレスであるか、Alt-Address [UTF8SMTP]を指定している必要があります。さらに、受信者のアドレスは、ASCIIアドレスを利用できるようにする必要があります。メーリングリストのオペレーターが、国際化されたすべてのメンバーアドレスのAlt-Addressを事前に採用することをお勧めします。

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-Address [UTF8SMTP]は指定されておらず、ダウングレードが必要である場合、メッセージは配信できません。これを保護するために、UTF8SMTP-AWARE [UTF8SMTP]メーリングリストは、Alt-Addressを欠く国際化された電子メールアドレスから提出を拒否することを好むかもしれません。

(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-AWAREであるメールリレーは、同じ状況に遭遇する可能性があります。）このドキュメントのセクション6には、さらなる議論が含まれています。

4. Capabilities and Requirements

4. 機能と要件

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提出または返品パスアドレスを使用する場合、Alt-Address [utf8Smtp]を指定する必要があります。明らかに、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 Return-Pathアドレスを使用する場合、メッセージ提出エージェント（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).

リストのReturn-Pathアドレスは、通常、送信アドレスとは別のものです（そのため、配信レポートやその他の自動生成メッセージが送信アドレスに送信されません）。配信ステータス通知を受信することで信頼性を得るために、リストはUTF-8提出アドレスを使用している場合でも、すべてASCIIリターンパスを使用することを選択できます。リストがUTF-8リターンパスを使用している場合、Alt-Address [UTF8SMTP]を指定する必要があります（または、配達のないレポートを受け取ることができないリスクが高い）。

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.

2. UTF-8アドレスがサブスクライブを許可する場合、各UTF-8サブスクライバーに対してAlt-Address [UTF8SMTP]を指定する必要がある場合があります。

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 <ascii@ascii >>）フォームで指定されています）。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をサポートする必要があります。

5. List Header Fields

5. ヘッダーフィールドをリストします

A number of header fields, specifically for mailing lists, have been introduced in RFCs 2369 and 2919. For example, these include:

特にメーリングリストのために、多くのヘッダーフィールドがRFCS 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>

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で構成され、内部の白文字は無視されます」[list-*]。List-IDの場合、RFC 2919は、「リスト識別子は、ほとんどの場合、リスト所有者のドメインのホスト名のように表示される」[List-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].

List-IDヘッダーフィールドを除き、これらのメーリングリストヘッダーフィールドにはURLが含まれています[RFC3986]。最も一般的なスキームは、一般にHTTP、HTTPS、MailTo、およびFTPです。URIと国際化されたリソース識別子（IRI）[IRI]フォームの両方を許可するスキームは、[IRI]で説明されているURIエンコード形式を使用する必要があります。将来の作業は、これらのヘッダーフィールドを拡張するか、交換を定義して、非エンコードされていないUTF-8をIRIS（たとえば[MailTo-Bis]）を直接サポートする場合がありますが、そのような拡張または交換がない場合、ASCII以外の文字は内にのみ表示されます。ASCIIとしてエンコードされた場合。国際化されたドメイン名がエンコードされたパーセントであるか、パンコード化されているかどうかについての議論が進行中であることに注意してください。[iri-bis]を参照してください。

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をサポートするために拡張されていなくても、格下げ時にいくつかの特別な規定が役立つ場合があります。特に、list*ヘッダーフィールドにUTF-8 Mailto（ASCIIでエンコードされても）が含まれている場合、ASCII Mailtoが続く場合は、通常のように元のヘッダーフィールドをコピーして保存するだけでなく、[eaiのカプセル化方法を保存することをお勧めします。-downgrade]）、しかし、ヘッダーフィールドを編集してUTF-8アドレスを削除します。それ以外の場合、デコードされたメールが非ASCIIアドレスを得ると、クライアントがトラブルに遭遇する可能性があります。

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.

List-*ヘッダーフィールドで最も一般的に使用されるURIスキームは、HTTPおよびMailtoである傾向があります。MailToの現在の仕様では、ENCODEDのUTF-8文字が許可されていませんが、これを許可するためにMailToを拡張または交換する可能性が高い作業が提案されています。Mailto Urisの場合、別の考慮事項は、UTF-8アドレスに代替ASCIIアドレス（alt-Address）[UTF8SMTP]を含める方法です。各リスト - *ヘッダーフィールド内で複数のURLを指定する既存の機能が1つのソリューションを提供することに注意してください。

[List-*] says:

[list*]と言う：

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

List-IDヘッダーフィールドは、リストを一意に識別する不透明な値を提供します。目的は、リストの操作またはホストに使用されるマシンまたはシステムが変更された場合でも、このヘッダーフィールドの値は一定のままであることです。このヘッダーフィールドは、クライアント側フィルター、シーブフィルターなどのさまざまなフィルターやテストでよく使用されます。このようなフィルターとテストは、ASCIIにエンコードされた非ASCII値を適切に比較しない場合があります。これらの比較に関する考慮事項に加えて、このヘッダーフィールドには、ユーザーが入力できる意味のあるものが含まれることが一般に望まれます。ただし、ASCII非ASCII文字のASCIIエンコーディングは、ユーザーにとって意味のあるものでも、正確に入力することはできません。

6. Further Discussion

6. さらなる議論

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ヘッダーフィールドを使用してメッセージを受け入れ、UTF-8メールおよびUTF8SMTP-AWAREではないシステムを介してAll-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-AWAREであるため、Alt-Address [UTF8SMTP]から送信MTAから輸送に送信するには必要ありません。完了します。メーリングリストがサブスクライバーにメッセージを再送信すると、ダウングレードが必要なパスに遭遇する可能性があります（リレーまたは最終MSAがUTF8SMTPをサポートしていない場合）。この状況を緩和するために、メーリングリストはおそらく、Alt-Addressを欠く国際化された電子メールアドレスからすべての受信メールを拒否することを決定するかもしれません。ただし、一般に、格下げは通常のケースではないことに注意してください。

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

2. Mailto URLの考慮事項のダウングレード-List-* HeaderフィールドのMailToリンクのUTF-8アドレスは、Alt-Address [UTF8SMTP]を含むとダウングレードしやすくなります。

7. Security Considerations

7. セキュリティに関する考慮事項

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-Addressの両方を使用すると、リストサブスクライバーとメッセージ送信者のIDに関する潜在的な曖昧さが導入されるため、実装者はサブスクリプション、送信者フィルター、およびその他の共通リストに関する承認決定を慎重に処理することをお勧めします管理機能。たとえば、UTF-8アドレスとASCII Alt-Addressの間のバインディングを攻撃者が使用して、他の人の入場料を拒否して、EAI Internationalization（EAI）メーリングリストを拒否できます。

Other relevant security considerations are discussed in the Framework document [EAI-Framework].

その他の関連するセキュリティ上の考慮事項については、フレームワークドキュメント[EAIフレームワーク]で説明しています。

8. Acknowledgments

8. 謝辞

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のEdmon Chungは、このドキュメントの元のバージョンを書きました。彼の広範なコメントをしてくれたHarald Alvestrandに感謝します。テッド・ハーディはアイリスに役立つテキストを提供しました。S. MoonesamyとAmanda Baberからの最後のコメント、さらにPete ResnickによるShepherd Reviewがドキュメントを改善しました。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

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

[EAI-Framework] Klensin、J。およびY. Ko、「国際化された電子メールの概要とフレームワーク」、RFC 4952、2007年7月。

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

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.

[List-*] Neufeld、G。およびJ. Baer、「コアメールリストコマンドのメタシンタックスとしてのURLの使用とメッセージヘッダーフィールドを介したその輸送」、RFC 2369、1998年7月。

[List-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[List-Id] Chandhok、R。and G. Wenger、「List-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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。

[RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5335] Abel、Y.、ed。、「Internationalized Email Headers」、RFC 5335、2008年9月。

[submission] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[提出] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。

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

[UTF8SMTP] Yao、J.、ed。、およびW. Mao、ed。、「国際化された電子メールアドレスのSMTP拡張」、RFC 5336、2008年9月。

9.2. Informative References

9.2. 参考引用

[EAI-Downgrade] Fujiwara, K., Ed., and Y. Yoneya, Ed., "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.

[EAI-DownGrade] Fujiwara、K.、ed。、およびY. Youneya、ed。、「電子メールアドレス国際化のための格下げメカニズム」、RFC 5504、2009年3月。

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

[IRI] Duerst、M。およびM. Suignard、「国際化された資源識別子（IRIS）」、RFC 3987、2005年1月。

[IRI-bis] Duerst, M., Suignard, M., and L. Masinter, "Internationalized Resource Identifiers (IRIs)", Work in Progress, July 2010.

[IRI-Bis] Duerst、M.、Suignard、M.、およびL. Masinter、「国際化されたリソース識別子（IRIS）」、2010年7月の作業。

[mailto-bis] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", Work in Progress, May 2010.

[Mailto-bis] Duerst、M.、Masinter、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

Randall Gellens Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 rg ietf@qualcomm.com