[要約] RFC 6783は、メーリングリストと非ASCIIアドレスに関するガイドラインです。その目的は、非ASCII文字を含むアドレスの処理と送信に関する標準化を提供することです。
Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 6783 Taughannock Networks
Obsoletes: 5983 R. Gellens
Category: Informational Qualcomm Incorporated
ISSN: 2070-1721 November 2012
Mailing Lists and Non-ASCII Addresses
メーリングリストと非ASCIIアドレス
Abstract
概要
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice.
このドキュメントでは、ASCII以外のUTF-8電子メールアドレスを導入したメーリングリストの考慮事項について説明します。非ASCIIアドレスと従来のアドレスが混在するリストを処理するためのいくつかの考えられるシナリオの概要を示しますが、プロトコルの変更を指定したり、実装や展開のアドバイスを提供したりしていません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6783.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6783で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Mailing List Header Additions and Modifications . . . . . . 3
1.2. Non-ASCII Email Addresses . . . . . . . . . . . . . . . . . 3
2. Scenarios Involving Mailing Lists . . . . . . . . . . . . . . . 4
2.1. Fully SMTPUTF8 Lists . . . . . . . . . . . . . . . . . . . 4
2.2. Mixed SMTPUTF8 and ASCII Lists . . . . . . . . . . . . . . 5
2.3. SMTP Issues . . . . . . . . . . . . . . . . . . . . . . . . 5
3. List Headers . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SMTPUTF8 List Headers . . . . . . . . . . . . . . . . . . . 6
3.2. Downgrading List Headers . . . . . . . . . . . . . . . . . 7
3.3. Subscribers' Addresses in Downgraded Headers . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. The usage of such addresses is described in [RFC6530].
このドキュメントでは、ASCII以外のUTF-8電子メールアドレスを導入したメーリングリストの考慮事項について説明します。そのようなアドレスの使用法は[RFC6530]で説明されています。
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つの主要分野のメーリングリストに影響を与えます。 （2）受信および再送信されたメッセージのメッセージヘッダー。 （3）メーリングリストの運用ポリシー。
A mailing list is a mechanism that distributes a message to multiple recipients when the originator sends it to a single address. An agent, usually software rather than a person, at that single address receives the message and then causes the message to be redistributed to a list of recipients. This agent usually sets the envelope return address (henceforth called the "bounce address") of the redistributed message to a different address from that of the original message. Using a different bounce address directs error and other automatically generated messages to an error-handling address associated with the mailing list. This sends error and other automatic messages to the list agent, which can often do something useful with them, rather than 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 [RFC6409] (as did the sender of the original message). The exception, where the mailing list is not managed by a separate agent that receives and redistributes messages in separate transactions but is implemented by an expansion step within an SMTP transaction where one local address expands to multiple local or non-local addresses, is not addressed by this document.
ほとんどの場合、メーリングリストエージェントは受信したメッセージを新しいメッセージとしてサブスクライバーに再配布します。つまり、概念的にはメッセージ送信[RFC6409]を使用します（元のメッセージの送信者と同様）。例外。メーリングリストは、個別のトランザクションでメッセージを受信して再配信する個別のエージェントでは管理されませんが、1つのローカルアドレスが複数のローカルアドレスまたは非ローカルアドレスに展開されるSMTPトランザクション内の展開手順によって実装されます。このドキュメントによって。
Some list agents 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 headers. 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. Some lists alter or replace other fields, including "From".
一部のリストエージェントはメッセージヘッダーフィールドを変更しますが、他のエージェントは変更しません。多くの標準化されたリスト関連のヘッダーフィールドが定義されており、多くのリストはこれらのヘッダーの1つ以上を追加します。これらの標準化されたリスト固有のヘッダーフィールドとは別にして、相互運用性の問題の歴史にかかわらず、一部のリストは、返信の送信先を制御するためにヘッダーフィールドを変更または追加します。このようなリストは通常、「返信先」フィールドを追加または置換し、一部のリストは「送信者」フィールドを追加または置換します。一部のリストは、「From」を含む他のフィールドを変更または置き換えます。
Among these list-specific header fields are those specified in RFCs 2369 [RFC2369] and 2919 [RFC2919]. For more information, see Section 3.
これらのリスト固有のヘッダーフィールドには、RFC 2369 [RFC2369]および2919 [RFC2919]で指定されているフィールドがあります。詳細については、セクション3を参照してください。
While the mail transport protocol is the same for regular email recipients and mailing list recipients, list agents have special considerations with non-ASCII email addresses because they retransmit messages composed by other agents to potentially many recipients.
メール転送プロトコルは通常のメール受信者とメーリングリスト受信者で同じですが、リストエージェントは他のエージェントによって作成されたメッセージを潜在的に多くの受信者に再送信するため、非ASCIIメールアドレスに関して特別な考慮事項があります。
There are considerations for non-ASCII email addresses in the envelope as well as in header fields of redistributed messages. In particular, a message with non-ASCII addresses in the headers or envelope cannot be sent to non-SMTPUTF8 recipients.
エンベロープ内、および再配布されたメッセージのヘッダーフィールド内の非ASCIIメールアドレスに関する考慮事項があります。特に、ヘッダーまたはエンベロープに非ASCIIアドレスが含まれているメッセージは、SMTPUTF8以外の受信者には送信できません。
With mailing lists, there are two different types of considerations: first, the purely technical ones involving message handling, error cases, and the like, and second, those that arise from the fact that humans use mailing lists to communicate. As an example of the first, list agents might choose to reject all messages from non-ASCII addresses if they are unprepared to handle SMTPUTF8 mail. 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 SMTPUTF8 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 one-to-one communication 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 which list members successfully received a message or if it was undeliverable to some.
メーリングリストには、2つの異なるタイプの考慮事項があります。1つ目は、メッセージ処理やエラーケースなどを含む純粋に技術的な考慮事項、2つ目は、人間がメーリングリストを使用して通信するという事実から生じるものです。最初の例として、リストエージェントは、SMTPUTF8メールを処理する準備ができていない場合、非ASCIIアドレスからのすべてのメッセージを拒否することを選択できます。 2番目の例として、メッセージをリストに送信するユーザーは、リストのメンバーシップを知らないことがよくあります。特に、ユーザーは、メンバーがSMTPUTF8メールユーザーであるかどうかを知らないことが多く、元の送信者も受信者も個人的にお互いを知りません。この結果、1対1のコミュニケーションですぐに利用できる可能性のある救済策は、メーリングリストを扱う場合には適切ではない可能性があります。たとえば、ユーザーが配信できないメッセージを送信した場合、通常、電話、インスタントメッセージング、またはその他の形式の通信を使用してワーキングアドレスを取得できます。メーリングリストでは、ユーザーは頼りにならないかもしれません。もちろん、メーリングリストでは、元の送信者は通常、どのリストのメンバーがメッセージを正常に受信したか、または一部のリストに配信できなかったかを知りません。
Conceptually, a mailing list's internationalization can be divided into three capabilities. First, does the list have a non-ASCII submission address? Second, does the list agent accept subscriptions for addresses containing non-ASCII characters? And third, does the list agent accept messages that require SMTPUTF8 capabilities?
概念的には、メーリングリストの国際化は3つの機能に分けることができます。まず、リストには非ASCII送信アドレスがありますか？次に、リストエージェントは非ASCII文字を含むアドレスのサブスクリプションを受け入れますか？ 3番目に、リストエージェントはSMTPUTF8機能を必要とするメッセージを受け入れますか？
If a list has subscribers with ASCII addresses, those subscribers might or might not be able to accept SMTPUTF8 messages.
リストにASCIIアドレスのサブスクライバーがある場合、それらのサブスクライバーはSMTPUTF8メッセージを受け入れることができる場合とできない場合があります。
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 list agent sending the retransmitted message to one or more list recipients. In both cases, the message might be addressed only to the list address or might have recipients in addition to the list. Furthermore, the list agent might choose to send the retransmitted message to each list recipient in a separate message submission transaction or might choose to include multiple recipients per transaction. Often, list agents are constructed to work in cooperation with, rather than include the functionality of, a message submission server; hence, the list transmits to a single submission server one copy of the retransmitted message. The submission server then decides which recipients to include in which transaction.
一般に（そしてこのドキュメントの範囲内でのみ）、元のメッセージは、再送信されたメッセージを1人以上のリスト受信者に送信するリストエージェントからの完全に独立した独立したトランザクションとしてメーリングリストに送信されます。どちらの場合も、メッセージの宛先はリストのアドレスのみか、リストに加えて受信者がいる可能性があります。さらに、リストエージェントは、再送信されたメッセージを各リスト受信者に個別のメッセージ送信トランザクションで送信するか、トランザクションごとに複数の受信者を含めるかを選択できます。多くの場合、リストエージェントは、メッセージ送信サーバーの機能を含めるのではなく、連携して機能するように構築されています。したがって、リストは再送信されたメッセージのコピーを1つの送信サーバーに送信します。次に、送信サーバーは、どのトランザクションにどの受信者を含めるかを決定します。
Some lists may wish to be fully SMTPUTF8. That is, all subscribers are expected to be able to receive SMTPUTF8 mail. For list hygiene reasons, such a list would probably want to prevent subscriptions from addresses that are unable to receive SMTPUTF8 mail. If a putative subscriber has a non-ASCII address, it must be able to receive SMTPUTF8 mail, but there is no way to tell whether a subscriber with an ASCII address can receive SMTPUTF8 mail short of sending an SMTPUTF8 probe or confirmation message and somehow finding out whether it was delivered, e.g., if the user clicked a link in the confirmation message.
一部のリストは完全にSMTPUTF8であることが望まれる場合があります。つまり、すべてのサブスクライバーがSMTPUTF8メールを受信できる必要があります。リストの衛生上の理由から、このようなリストでは、SMTPUTF8メールを受信できないアドレスからのサブスクリプションを防止する必要があります。推定サブスクライバーが非ASCIIアドレスを持っている場合、SMTPUTF8メールを受信できる必要がありますが、ASCIIアドレスを持つサブスクライバーがSMTPUTF8プローブまたは確認メッセージを送信して何らかの方法で見つける以外に、SMTPUTF8メールを受信できるかどうかを判断する方法はありません。配信されたかどうか、たとえばユーザーが確認メッセージのリンクをクリックしたかどうか。
Other lists may wish to handle a mixture of SMTPUTF8 and ASCII subscribers, either as a transitional measure as subscribers upgrade to SMTPUTF8-capable mail software or as an ongoing feature. While it is not possible in general to downgrade SMTPUTF8 mail to ASCII mail, list software might divide the recipients into two sets, SMTPUTF8 and ASCII recipients, and create a downgraded version of SMTPUTF8 list messages to send to ASCII recipients. See Sections 3.2 and 3.3.
その他のリストでは、SMTPUTF8とASCIIのサブスクライバーの混合を、サブスクライバーがSMTPUTF8対応のメールソフトウェアにアップグレードする際の移行措置として、または継続的な機能として扱いたい場合があります。一般に、SMTPUTF8メールをASCIIメールにダウングレードすることはできませんが、リストソフトウェアは受信者をSMTPUTF8とASCII受信者の2つのセットに分割し、ASCII受信者に送信するSMTPUTF8リストメッセージのダウングレードバージョンを作成します。セクション3.2および3.3を参照してください。
To determine which set an address belongs in, list software might make the conservative assumption that ASCII addresses get ASCII messages, it might try to probe the address with an SMTPUTF8 test message, or it might let the subscriber set the message format manually, similar to the way that some lists now let subscribers choose between plain text and HTML mail, or individual messages and a daily digest.
アドレスがどのセットに属しているかを判断するために、リストソフトウェアは、ASCIIアドレスがASCIIメッセージを取得するという保守的な仮定を行うか、SMTPUTF8テストメッセージでアドレスをプローブしようとするか、またはサブスクライバーにメッセージ形式を手動で設定させます。一部のリストでは、サブスクライバーがプレーンテキストとHTMLメール、または個々のメッセージと毎日のダイジェストを選択できるようになりました。
To determine whether a message needs to be downgraded for ASCII recipients, list software might assume that any message received via an SMTPUTF8 SMTP session is an SMTPUTF8 message or might examine the headers and body of the message to see whether it needs SMTPUTF8 treatment. Depending on the interface between the list software and the Mail Transfer Agent (MTA) and Mail Delivery Agent (MDA) that handle incoming messages, it may not be able to tell the type of session for incoming messages.
ASCII受信者に対してメッセージをダウングレードする必要があるかどうかを判断するために、リストソフトウェアは、SMTPUTF8 SMTPセッションを介して受信されたメッセージはすべてSMTPUTF8メッセージであると想定するか、メッセージのヘッダーと本文を調べてSMTPUTF8処理が必要かどうかを確認します。リストソフトウェアと、着信メッセージを処理するメール転送エージェント（MTA）およびメール配信エージェント（MDA）の間のインターフェイスによっては、着信メッセージのセッションのタイプを通知できない場合があります。
Mailing list software usually changes the envelope addresses on each message. The bounce address is set to an address that will return bounces to the list agent, and the recipient addresses are set to the subscribers of the list. For some lists, all messages to a list get the same bounce address. For others, list software may create a bounce address per recipient or a unique bounce address per message per recipient, bounce management techniques known as Variable Envelope Return Paths or VERP [VERP].
メーリングリストソフトウェアは通常、各メッセージのエンベロープアドレスを変更します。バウンスアドレスは、リストエージェントにバウンスを返すアドレスに設定され、受信者アドレスはリストのサブスクライバーに設定されます。一部のリストでは、リストへのすべてのメッセージに同じバウンスアドレスが割り当てられます。他の人のために、リストソフトウェアは、受信者ごとのバウンスアドレス、または受信者ごとのメッセージごとの一意のバウンスアドレス、Variable Envelope Return PathsまたはVERP [VERP]として知られるバウンス管理技術を作成する場合があります。
The bounce address for a list typically includes the name of the list, so a list with a non-ASCII name will have a non-ASCII bounce address. Given the unknown paths that bounce messages might take, list software might instead use an ASCII bounce address to make it more likely that bounces can be delivered back to the list agent. Similarly, a VERP address for each subscriber typically embeds a version of the subscriber's address so the VERP bounce address for a non-ASCII subscriber address will be a non-ASCII address. For the same reason, the list software might use ASCII bounce addresses that encode the recipient's identity in some other way.
リストのバウンスアドレスには通常、リストの名前が含まれるため、ASCII以外の名前のリストには、ASCII以外のバウンスアドレスが含まれます。バウンスメッセージの経路が不明な場合、リストソフトウェアは代わりにASCIIバウンスアドレスを使用して、バウンスをリストエージェントに配信できる可能性を高めます。同様に、各サブスクライバーのVERPアドレスには通常、サブスクライバーのアドレスのバージョンが埋め込まれているため、非ASCIIサブスクライバーアドレスのVERPバウンスアドレスは非ASCIIアドレスになります。同じ理由で、リストソフトウェアは、他の方法で受信者のIDをエンコードするASCIIバウンスアドレスを使用する場合があります。
List agents typically add list-specific headers to each message before resending the message to list recipients.
リストエージェントは通常、リストの受信者にメッセージを再送信する前に、各メッセージにリスト固有のヘッダーを追加します。
The list headers in RFCs 2369 [RFC2369] and 2919 [RFC2919] were all specified before SMTPUTF8 mail existed, and their definitions do not address where non-ASCII characters might appear. These include, for example:
RFC 2369 [RFC2369]および2919 [RFC2919]のリストヘッダーはすべて、SMTPUTF8メールが存在する前に指定されたものであり、それらの定義は非ASCII文字が表示される可能性がある場所には対応していません。たとえば、次のものが含まれます。
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 [RFC2369], "[t]he contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored". [RFC2919] specifies that "[t]he list identifier will, in most cases, appear like a host name in a domain of the list owner". Since these headers were defined in the context of ASCII mail, these headers permit only ASCII text, including in the URLs.
[RFC2369]で説明されているように、「リストヘッダーフィールドの内容は、ほとんどが山かっこ（ '<'、 '>'）で囲まれたURLで構成され、内部の空白は無視されます。」 [RFC2919]は、「リスト識別子は、ほとんどの場合、リスト所有者のドメイン内のホスト名のように見える」ことを指定しています。これらのヘッダーはASCIIメールのコンテキストで定義されているため、これらのヘッダーはURLを含むASCIIテキストのみを許可します。
The most commonly used URI schemes in List-* headers tend to be http and mailto [RFC6068], although they sometimes include https and ftp and, in principle, can contain any valid URI.
List- *ヘッダーで最も一般的に使用されるURIスキームは、httpとmailto [RFC6068]になる傾向がありますが、httpsとftpが含まれることもあり、原則として、有効なURIを含めることができます。
Even if a scheme permits an internationalized form, it should use a pure ASCII form of the URI described in [RFC3986]. Future work may extend these header fields or define replacements to directly support unencoded non-ASCII outside the ASCII repertoire in these and other header fields, but in the absence of such extension or replacement, non-ASCII characters can only be included by encoding them as ASCII.
スキームが国際化された形式を許可する場合でも、[RFC3986]で説明されているURIの純粋なASCII形式を使用する必要があります。今後の作業では、これらのヘッダーフィールドを拡張するか、置換を定義して、これらのヘッダーフィールドや他のヘッダーフィールドのASCIIレパートリーの外でエンコードされていない非ASCIIを直接サポートする可能性がありますが、そのような拡張または置換がない場合、非ASCII文字は、 ASCII。
The encoding technique specified in [RFC3986] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which can lead to unfortunate interactions with percent-encoded URIs or any URI that includes one of those characters. If a program interpreting a mailto: URI knew that the Mail User Agent (MUA) in use were able to handle non-ASCII data, the program could pass the URI in unencoded non-ASCII, avoiding problems with misinterpreted percent signs, but at this point, there is no standard or even informal way for MUAs to signal SMTPUTF8 capabilities. Also, note that whether internationalized domain names should be percent-encoded or appear in A-label form [RFC5890] depends on the context in which they occur.
[RFC3986]で指定されているエンコーディング手法は、パーセント記号が前に付いた16進数のペアを使用することですが、パーセント記号は、ソースルーティングを行うためにメールアドレスで非公式に使用されています。まだソースルーティングを許可しているメールシステムはほとんどありませんが、多くのメールソフトウェアでは、以前にソースルーティングに使用されていた文字を引き続き禁止またはエスケープします。 mailto：URIを解釈するプログラムが、使用中のメールユーザーエージェント（MUA）が非ASCIIデータを処理できることを知っている場合、プログラムは、エンコードされていない非ASCIIでURIを渡すことができ、誤ったパーセント記号の問題を回避できます。つまり、MUAがSMTPUTF8機能をシグナル通知するための標準的または非公式な方法はありません。また、国際化ドメイン名をパーセントエンコードするか、Aラベル形式で表示するか（RFC5890）は、ドメイン名が発生するコンテキストに依存することに注意してください。
The List-ID header field uniquely identifies a list. The intent is that the value of this header 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 [RFC5228], and so forth. If the definition of a List-ID header field were to be extended to allow non-ASCII text, filters and tests might not properly compare encoded and unencoded versions of a non-ASCII value. 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ヘッダーフィールドは、リストを一意に識別します。リストを操作またはホストするために使用されたマシンまたはシステムが変更されても、このヘッダーの値は一定のままであることが意図されています。このヘッダーフィールドは、クライアント側フィルター、Sieveフィルター[RFC5228]などのさまざまなフィルターやテストでよく使用されます。 List-IDヘッダーフィールドの定義を拡張して非ASCIIテキストを許可する場合、フィルターとテストは非ASCII値のエンコードバージョンと非エンコードバージョンを適切に比較しない可能性があります。これらの比較に関する考慮事項に加えて、このヘッダーフィールドには、ユーザーが入力できる意味のあるものが含まれていることが一般的に望ましいです。ただし、非ASCII文字のASCIIエンコーディングは、ユーザーにとって意味がありそうにないか、正確に入力するのが簡単です。
If list software prepares a downgraded version of an SMTPUTF8 message, all the List-* headers must be downgraded. In particular, if a List-* header contains a non-ASCII mailto (even encoded in ASCII), it may be advisable to edit the header to remove the non-ASCII address or replace it with an equivalent ASCII address if one is known to the list software. Otherwise, a client might run into trouble if the decoded mailto results in a non-ASCII address. If a header that contains a mailto URL is downgraded by percent encoding, some mail software may misinterpret the percent signs as attempted source routing.
リストソフトウェアがダウングレードバージョンのSMTPUTF8メッセージを準備する場合、すべてのList- *ヘッダーをダウングレードする必要があります。特に、List- *ヘッダーに非ASCIIのmailto（ASCIIでエンコードされている場合も含む）が含まれている場合、ヘッダーを編集して非ASCIIアドレスを削除するか、わかっている場合は同等のASCIIアドレスに置き換えることをお勧めします。リストソフトウェア。そうしないと、デコードされたmailtoが非ASCIIアドレスになった場合、クライアントで問題が発生する可能性があります。 mailto URLを含むヘッダーがパーセントエンコーディングによってダウングレードされると、一部のメールソフトウェアはパーセント記号を試行されたソースルーティングと誤って解釈する場合があります。
When downgrading list headers, it may not be possible to produce a downgraded version that is satisfactorily equivalent to the original header. In particular, if a non-ASCII List-ID is downgraded to an ASCII version, software and humans at recipient systems will typically not be able to tell that both refer to the same list.
リストヘッダーをダウングレードすると、元のヘッダーと十分に同等のダウングレードバージョンを生成できない場合があります。特に、ASCII以外のList-IDがASCIIバージョンにダウングレードされた場合、通常、受信者システムのソフトウェアと人間は、両方が同じリストを参照していることを認識できません。
If lists permit mail with multiple MIME parts, some MIME headers in SMTPUTF8 messages may include non-ASCII characters in file names and other descriptive text strings. Downgrading these strings may lose the sense of the names, break references from other MIME parts (such as HTML IMG references to embedded images), and otherwise damage the mail.
リストで複数のMIME部分を持つメールが許可されている場合、SMTPUTF8メッセージの一部のMIMEヘッダーに、ファイル名やその他の説明テキスト文字列に非ASCII文字が含まれている可能性があります。これらの文字列をダウングレードすると、名前の意味が失われ、他のMIMEパーツからの参照（HTML IMGの埋め込み画像への参照など）が壊れ、メールに損傷を与える可能性があります。
List software typically leaves the original submitter's address in the From: line, both so that recipients can tell who wrote the message and so that they have a choice of responding to the list or directly to the submitter. If a submitter has a non-ASCII address, there is no way to downgrade the From: header and preserve the address so that ASCII recipients can respond to it, since non-SMTPUTF8 mail systems can't send mail to non-ASCII addresses.
リストソフトウェアは通常、元の送信者のアドレスをFrom：行に残します。これにより、受信者は誰がメッセージを書いたかを知ることができ、リストに応答するか、送信者に直接応答するかを選択できます。送信者が非ASCIIアドレスを持っている場合、SMTPUTF8以外のメールシステムは非ASCIIアドレスにメールを送信できないため、From：ヘッダーをダウングレードしてアドレスを保持し、ASCII受信者が応答できるようにする方法はありません。
Possible work-arounds (none implemented that we know of) might include allowing subscribers with non-ASCII addresses to register an alternate ASCII address with the list software, having the list software itself create ASCII forwarding addresses, or just putting the list's address in the From: line and losing the ability to respond directly to the submitter.
考えられる回避策（既知の実装はありません）には、ASCII以外のアドレスを持つサブスクライバーがリストソフトウェアに代替ASCIIアドレスを登録できるようにする、リストソフトウェア自体がASCII転送アドレスを作成する、または単にリストのアドレスをFrom：行になり、送信者に直接応答する機能を失います。
None beyond what mailing list agents do now.
メーリングリストエージェントが現在行っていること以外はありません。
[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月。
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[RFC6068] Duerst、M.、Masinter、L。、およびJ. Zawinski、「The 'mailto' URI Scheme」、RFC 6068、2010年10月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409] Gellens、R。およびJ. Klensin、「Mail for Submission for Mail」、STD 72、RFC 6409、2011年11月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J。およびY. Ko、「Overview and Framework for Internationalized Email」、RFC 6530、2012年2月。
[RFC2369] 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.
[RFC2369] Neufeld、G。およびJ. Baer、「コアメールリストコマンドのメタ構文としてのURLの使用とメッセージヘッダーフィールドを介したトランスポート」、RFC 2369、1998年7月。
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[RFC2919] Chandhok、R。およびG. Wenger、「List-Id：A Structured Field and Namespace for the Identification for Mailing Lists」、RFC 2919、2001年3月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228] Guenther、P。およびT. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[VERP] Bernstein, D., "Variable Envelope Return Paths", February 1997, <http://cr.yp.to/proto/verp.txt>.
[VERP] Bernstein、D。、「Variable Envelope Return Paths」、1997年2月、<http://cr.yp.to/proto/verp.txt>。
Authors' Addresses
著者のアドレス
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 US
John Levine Taughannock Networks PO Box 727 Trumansburg、NY 14886 US
Phone: +1 831 480 2300
EMail: standards@taugh.com
URI: http://jl.ly
Randall Gellens Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 US
Randall Gellens Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121 US
EMail: rg+ietf@qti.qualcomm.com