[要約] RFC 3834は、電子メールへの自動応答に関する推奨事項を提供しています。その目的は、効果的な自動応答の実装と使用に関するガイドラインを提供することです。
Network Working Group K. Moore
Request for Comments: 3834 University of Tennessee
Category: Standards Track August 2004
Recommendations for Automatic Responses to Electronic Mail
電子メールへの自動応答に関する推奨事項
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders.
このメモは、「Out of the Office」または「Vacation」応答ジェネレーター、メールフィルタリングソフトウェア、電子メールベースの情報サービス、その他の自動レスポンダーなど、着信電子メールメッセージに自動的に応答するソフトウェアに推奨事項を作成します。これらの推奨事項の目的は、そのようなソフトウェアによって引き起こされたり悪化したりする望ましくない動作を阻止し、自動メールレスポンダー間で均一な動作を促進し、自動電子メールレスポンダーの実装者間の混乱のソースをクリアすることです。
Many programs which automatically respond to email are currently in use. Although these programs vary widely in their function, several problems with this class of programs have been observed, including: significant numbers of useless or unwanted response and responses sent to inappropriate addresses, and occasional incidences of mail loops or "sorcerer's apprentice" mode. This memo recommends behavior for programs that automatically respond to electronic mail in order to reduce the number of problems caused by such programs.
電子メールに自動的に応答する多くのプログラムが現在使用されています。これらのプログラムは機能が大きく異なりますが、このクラスのプログラムのいくつかの問題が観察されています。など、かなりの数の役に立たないまたは不要な応答と不適切なアドレスに送信された応答、メールループまたは「魔術師の見習い」モードの発生が時折発生します。このメモは、そのようなプログラムによって引き起こされる問題の数を減らすために、電子メールに自動的に応答するプログラムの動作を推奨しています。
(Note: the term "sorcerer's apprentice mode" is defined as a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug.) (From [I1.JARGON]) This document is limited in scope to Internet electronic mail messages and many of its recommendations are specifically tailored for the protocol elements and data models used in Internet electronic mail messages and SMTP transport envelopes. Use of these recommendations in other messaging contexts such as instant messaging, SMS, or Usenet has not been considered, and is outside of the scope of this document.
（注：「Sorcerer's Apprentice Mode」という用語は、ある状況では、メッセージを受信すると複数のメッセージが送信されるプロトコルのバグとして定義されます。[i1.jargon]から）このドキュメントは、インターネット電子メールメッセージの範囲が限られており、その推奨事項の多くは、インターネット電子メールメッセージおよびSMTPトランスポートエンベロープで使用されるプロトコル要素とデータモデル向けに特別に調整されています。インスタントメッセージング、SMS、またはUSENETなどの他のメッセージングコンテキストでのこれらの推奨事項の使用は考慮されておらず、このドキュメントの範囲外です。
There are several different types of automatic responses. At least two types of automatic responses have been defined in IETF standards - Delivery Status Notifications [I2.RFC3464] which are intended to report the status of a message delivery by the message transport system, and Message Disposition Notifications [I3.RFC3798] which are intended to report of the disposition of a message after it reaches a recipient's mailbox. These responses are defined elsewhere and are generally not within the purview of this document, except that this document recommends specific cases where they should or should not be used.
自動応答にはいくつかの異なるタイプがあります。IETF標準では、少なくとも2種類の自動応答が定義されています - 配信ステータス通知[I2.RFC3464]は、メッセージトランスポートシステムによるメッセージ配信のステータスを報告することを目的としています。受信者のメールボックスに到達した後のメッセージの処分を報告することを目的としています。これらの応答は他の場所で定義されており、一般にこのドキュメントの範囲内にありません。ただし、このドキュメントでは、使用すべきではない特定のケースを推奨することを除きます。
Other types of automatic response in common use include:
一般的な使用における他のタイプの自動応答には次のものがあります。
- "Out of office" or "vacation" notices, which are intended to inform the sender of a message that the message is unlikely to be read, or acted on, for some amount of time,
- 「Out office」または「休暇」通知は、メッセージがある程度読まれたり、行動したりする可能性が低いというメッセージを送信者に通知することを目的としています。
- "Change of address" notices, intended to inform the sender of a message that the recipient address he used is obsolete and that a different address should be used instead (whether or not the subject message was forwarded to the current address),
- 「住所の変更」通知は、彼が使用した受信者アドレスが時代遅れであり、代わりに別のアドレスを使用する必要があることを送信者に通知することを目的としています（主題メッセージが現在のアドレスに転送されたかどうかにかかわらず）
- "Challenges", which require the sender of a message to demonstrate some measure of intelligence and/or willingness to agree to some conditions before the subject message will be delivered to the recipient (often to minimize the effect of "spam" or viruses on the recipient),
- 「課題」は、件名メッセージが受信者に配信される前に、何らかの尺度のインテリジェンスおよび/または何らかの条件に同意する意欲を示すためにメッセージの送信者を必要とする（多くの場合、「スパム」またはウイルスの効果を最小限に抑えるために受信者）、
- Email-based information services, which accept requests (presumably from humans) via email, provide some service, and issue responses via email also. (Mailing lists which accept subscription requests via email fall into this category),
- 電子メールで（おそらく人間から）メールを受け入れる電子メールベースの情報サービス、いくつかのサービスを提供し、電子メールで応答を発行します。（電子メールを介してサブスクリプションリクエストを受け入れるメーリングリストは、このカテゴリに分類されます）、
- Information services similar to those mentioned above except that they are intended to accept messages from other programs, and
- 他のプログラムからのメッセージを受け入れることを意図していることを除いて、上記の情報と同様の情報サービス、および
- Various kinds of mail filters (including "virus scanners") which act on behalf of a recipient to alter the content of messages before forwarding them to that recipient, and issue responses in the event a message is altered.
- 受信者に代わって動作するさまざまな種類のメールフィルター（「ウイルススキャナー」を含む）は、メッセージのコンテンツをその受信者に転送する前に変更し、メッセージが変更された場合に応答を発行します。
Recognizing the wide variety of response types in use, these recommendations distinguish between several classes of automatic responders according to the party or service on whose behalf the responder acts:
使用中のさまざまな応答タイプを認識して、これらの推奨事項は、レスポンダーが行動する当事者またはサービスに従って、自動応答者のいくつかのクラスを区別します。
- "Service Responders" exist to provide access to some service via email requests and responses. These are permanently associated with one or more email addresses, and when sending to such an address the sender presumably expects an automatic response. An email-based file retrieval service is an example of a Service Responder. A calendar service that allows appointment requests to be made via email, and which responds to such requests, would be another example of a Service Responder.
- 「サービスレスポンダー」は、電子メールのリクエストと応答を介してあるサービスへのアクセスを提供するために存在します。これらは1つ以上の電子メールアドレスに永続的に関連付けられており、そのようなアドレスに送信すると、送信者はおそらく自動応答を期待しています。電子メールベースのファイル検索サービスは、サービスレスポンダーの例です。予約リクエストを電子メールで行うことを許可し、そのようなリクエストに応答するカレンダーサービスは、サービスレスポンダーの別の例です。
- "Personal Responders" exist to make automatic responses on behalf of a single recipient address, in addition to, or in lieu of, that recipient reading the message. These responders operate according to criteria specified on a per-recipient basis. The UNIX "vacation" program is an example of a Personal Responder. A responder that accepts mail sent to a single address, attempts to analyze and classify the contents, and then issues a response which is dependent on that classification, is also a Personal Responder.
- 「個人の対応者」は、メッセージを読んでいる受信者に加えて、またはその代わりに、単一の受信者アドレスに代わって自動応答を行うために存在します。これらのレスポンダーは、レシピエントごとに指定された基準に従って動作します。UNIXの「休暇」プログラムは、個人のレスポンダーの例です。単一の住所に送信されたメールを受け入れ、コンテンツを分析および分類しようとするレスポンダーは、その分類に依存する応答を発行することであり、個人のレスポンダーでもあります。
- "Group Responders" exist to make automatic responses on behalf of any of a significant set of recipient addresses (say, every recipient in a particular DNS domain), in advance of, or in lieu of, a response from the actual recipient. Group Responders are similar to Personal Responders except that in the case of a Group Responder the criteria for responding are not set on a per-recipient basis. A "virus scanner" program that filtered all mail sent to any recipient on a particular server, and sent responses when a message was rejected or delivered in an altered form, might be an example of a Group Responder.
- 「グループレスポンダー」は、実際の受信者からの応答の前、またはその代わりに、重要なレシピエントアドレス（たとえば、特定のDNSドメインのすべての受信者など）に代わって自動応答を行うために存在します。グループレスポンダーは、グループレスポンダーの場合、応答の基準がレシピエントごとに設定されていないことを除いて、個人対応者に似ています。特定のサーバーの受信者に送信されたすべてのメールをフィルタリングし、メッセージが拒否または変更された形式で配信されたときに応答を送信した「ウイルススキャナー」プログラムは、グループレスポンダーの例かもしれません。
Appropriate behavior for a responder varies from one class to another. A behavior which might be appropriate from a Service Responder (where the sender is expecting an automatic response) might not be appropriate from a Personal Responder. For example, a Service Responder might send a very long response to a request, or one that is not in a human-readable format, according to the needs of that service. However a Personal Responder should assume that a human being is reading the response and send only brief responses in plain text.
応答者の適切な動作は、クラスごとに異なります。サービスレスポンダー（送信者が自動応答を期待している場合）から適切な動作は、個人のレスポンダーから適切ではない場合があります。たとえば、サービスレスポンダーは、そのサービスのニーズに応じて、非常に長い応答、またはそのサービスのニーズに応じて、人間の読み取り可能な形式ではない要求に送信する場合があります。ただし、個人的なレスポンダーは、人間が応答を読んでいると想定し、単純なテキストで簡単な応答のみを送信する必要があります。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in [N1.RFC2119].
「必須」、「必要はない」、「すべきではない」、「はない」、「推奨」、「推奨されない」、「5月」は、[n1.rfc2119]で説明されているように解釈されるべきです。
The term "subject message" is used to refer to a message which causes a response to be sent.
「サブジェクトメッセージ」という用語は、応答を送信するメッセージを参照するために使用されます。
The term "response" refers to a message that is automatically issued on receipt of a subject message by a responder.
「応答」という用語は、応答者によるサブジェクトメッセージの受信時に自動的に発行されるメッセージを指します。
A "responder" is a process that automatically responds to subject messages under some well-defined set of conditions.
「レスポンダー」とは、いくつかの明確に定義された一連の条件の下でサブジェクトメッセージに自動的に応答するプロセスです。
Unless specified otherwise, the term "recipient" refers to the email addresses to which a subject message was delivered (rather than, for instance, the address to which the response was sent). A "recipient" address might be permanently associated with a responder, or it might be the address of a human being whose mail is, under some conditions, answered by a responder.
特に指定されていない限り、「受信者」という用語は、サブジェクトメッセージが配信された電子メールアドレスを指します（たとえば、応答が送信されたアドレスではなく）。「受信者」アドレスは、レスポンダーに永続的に関連付けられている可能性があります。または、郵便物がある条件下で応答者によって回答された人間の住所である場合があります。
An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks.
自動レスポンダーは、受信したすべてのメッセージに対して盲目的に応答を送信してはなりません。実際には、いくつかの種類の受信メッセージへの応答を拒否する理由が常にあります。たとえば、ループ予防のために、「スパム」やウイルスへの応答を避け、虐待的なメッセージを洗濯または増幅する手段として使用されないように、不適切に回避するために使用されないようにする理由が常にあります。受信者に関する個人情報を明らかにする（例えば、受信者が最近メールを読んでいないという自動兆候を避けるため）、およびレスポンダーに対するサービス拒否攻撃を阻止する。応答するかどうかを決定するための基準は、応答者の目的に従って、応答者から別のレスポンダーに異なります。一般に、役に立たないまたは冗長な応答を送信しないようにし、メールループに貢献したり、サービス拒否攻撃を促進したりすることを避けるために注意する必要があります。
Here are some broad guidelines:
ここにいくつかの幅広いガイドラインがあります：
- Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field (see below), where that field has any value other than "no".
- 自動応答は、自動供給ヘッダーフィールド（以下を参照）を含むメッセージに応じて発行しないでください。このフィールドには「いいえ」以外の値があります。
- Personal and Group responses that are intended to notify the sender of a message of the recipient's inability to read or reply to the message (e.g., "away from my mail" or "too busy" notifications) SHOULD NOT issue the same response to the same sender more than once within a period of several days, even though that sender may have sent multiple messages. A 7-day period is RECOMMENDED as a default.
- 受信者がメッセージを読み取ったり返信できないというメッセージを送信者に通知することを目的とした個人的およびグループ応答その送信者が複数のメッセージを送信した場合でも、数日以内に複数回送信者がいます。デフォルトとして7日間の期間が推奨されます。
- Personal and Group responses whose purpose is to notify the sender of a message of a temporary absence of the recipient (e.g., "vacation" and "out of the office" notices) SHOULD NOT be issued unless a valid address for the recipient is explicitly included in a recipient (e.g., To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc) field of the subject message. Since a recipient may have multiple addresses forwarded to the same mailbox, recipients SHOULD be able to specify a set of addresses to the responder which it will recognize as valid for that recipient.
- 受信者の有効な住所が明示的に含まれていない限り、受信者の一時的な不在のメッセージ（「休暇」および「オフィス外」通知など）を送信者に通知することを目的とする個人的およびグループの回答は、発行されるべきではありません。対象メッセージのフィールド（CC、BCC、BCC、Resent-To、Resent-CC、またはResent BCCなど）では、受信者。受信者は複数のアドレスを同じメールボックスに転送している可能性があるため、受信者はその受信者にとって有効であると認識されるレスポンダーに一連のアドレスを指定できる必要があります。
Note: RFC 2822 section 3.6.3 permits varying uses of the Bcc field, some of which would allow the sender of the subject message to explicitly specify the recipient's address as a "Bcc" recipient without a Bcc field appearing in the message as delivered, or without the Bcc field in the delivered message containing the recipient's address. However, perhaps because Bcc's are rarely used, the heuristic of not responding to messages for which the recipient was not explicitly listed in a To, CC, or Bcc header field has been found to work well in practice.
注：RFC 2822セクション3.6.3 BCCフィールドのさまざまな用途が許可されています。その一部は、主題メッセージの送信者が、メッセージに表示されたメッセージに表示されているBCCフィールドのない「BCC」受信者として受信者のアドレスを明示的に指定できるようにすることを可能にします。または、受信者のアドレスを含む配信されたメッセージにBCCフィールドがありません。しかし、おそらくBCCがめったに使用されないため、受信者がA、CC、またはBCCヘッダーのフィールドに明示的にリストされていないメッセージに応答しないというヒューリスティックは、実際にはうまく機能することがわかっています。
- Personal and Group Responders MAY refuse to generate responses except to known correspondents or addresses of otherwise "trusted" individuals. Such responders MAY also generate different kinds of responses for "trusted" vs. "untrusted" addresses. This might be useful, for instance, to avoid inappropriate disclosure of personal information to arbitrary addresses.
- 個人およびグループレスポンダーは、既知の特派員または他の「信頼できる」個人の住所を除き、回答の生成を拒否する場合があります。このようなレスポンダーは、「信頼できる」対「信頼されていない」アドレスに対する異なる種類の応答を生成する場合があります。これは、たとえば、arbitrary意的な住所への個人情報の不適切な開示を避けるために有用かもしれません。
- Responders MUST NOT generate any response for which the destination of that response would be a null address (e.g., an address for which SMTP MAIL FROM or Return-Path is <>), since the response would not be delivered to a useful destination. Responders MAY refuse to generate responses for addresses commonly used as return addresses by responders - e.g., those with local-parts matching "owner-*", "*-request", "MAILER-DAEMON", etc. Responders are encouraged to check the destination address for validity before generating the response, to avoid generating responses that cannot be delivered or are unlikely to be useful.
- レスポンダーは、その応答の宛先がヌルアドレスになる応答を生成してはなりません（たとえば、SMTPメールまたはReturn-Pathが<> <>）。応答は有用な宛先に配信されないためです。レスポンダーは、レスポンダーによる返品アドレスとして一般的に使用されるアドレスの回答を生成することを拒否する場合があります。妥当性の宛先アドレス応答を生成する前に、配信できない、または有用である可能性が低い応答を生成しないようにします。
- In order to avoid responding to spam and to certain kinds of attacks, automatic responses from Service Responders SHOULD NOT be sent for extremely malformed requests. This may include checking that the subject message has a content-type and content appropriate to that service.
- スパムや特定の種類の攻撃への応答を避けるために、サービスレスポンダーからの自動応答は、非常に不正な要求のために送信されないでください。これには、サブジェクトメッセージにそのサービスに適したコンテンツタイプとコンテンツがあることを確認することが含まれます。
- Because the vast majority of email is unauthenticated, and return addresses are easily forged, in order to avoid being used as a means of denial-of-service attacks (i.e., to flood mailboxes with unwanted content) Service Responders SHOULD NOT return large responses (say, more than a few kilobytes) without specific knowledge that the request was actually authorized by the party associated with the address to which the response will be sent. Similarly, Service Responders SHOULD NOT cause unwanted side-effects (such as subscribing the sender to a mailing list) without reasonable assurance that the request was authorized by the affected party.
- 電子メールの大部分が認知されておらず、サービスの拒否攻撃の手段として使用されないようにするために（つまり、不要なコンテンツでメールボックスを洪水にするため）、サービスレスポンダー（つまり、大規模な応答を返すべきではありません）（つまり、サービス拒否攻撃の手段として使用されることを避けるために簡単に築かれるため、リクエストが実際に応答が送信される住所に関連する当事者によって実際に許可されたという特定の知識なしに、数キロバイト以上）。同様に、サービスレスポンダーは、リクエストが影響を受ける当事者によって許可されたことを合理的に保証することなく、望ましくない副作用（送信者をメーリングリストに購読するなど）を引き起こすべきではありません。
NOTE: Since each responder has a different purpose and a different set of potential threats to which it might be subjected, whether any particular means of authentication is appropriate for a particular responder is not in scope for this document.
注：各レスポンダーには異なる目的があり、特定のレスポンダーに適切である特定の認証手段がこのドキュメントの範囲にないかどうかにかかわらず、それが科せられる可能性のある潜在的な脅威の異なるセットがあるためです。
- A responder MAY refuse to send a response to a subject message which contains any header or content which makes it appear to the responder that a response would not be appropriate. For instance, if the subject message contained a Precedence header field [I4.RFC2076] with a value of "list" the responder might guess that the traffic had arrived from a mailing list, and would not respond if the response were only intended for personal messages. For similar reasons, a responder MAY ignore any subject message with a List-* field [I5.RFC2369]. (Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.)
- レスポンダーは、応答が適切ではないと対応者に表示されるヘッダーまたはコンテンツを含むサブジェクトメッセージへの応答を送信することを拒否する場合があります。たとえば、サブジェクトメッセージに「リスト」の値で優先順位ヘッダーフィールド[I4.RFC2076]が含まれていた場合、レスポンダーはメーリングリストからトラフィックが到着したと推測する可能性があり、応答が個人のみを意図している場合は応答しない場合があります。メッセージ。同様の理由で、レスポンダーは、list* field [i5.rfc2369]を使用して、任意のサブジェクトメッセージを無視する場合があります。（優先順位は標準的なヘッダーフィールドではなく、その使用と解釈は野生で大きく異なるため、この仕様では優先順位の存在下での特定の応答剤の挙動は推奨されません。）
The following sections specify details of the contents of automatic responses, including the header of the response message, the content of the response, and the envelope in which the response is transmitted to the email transport system.
次のセクションでは、応答メッセージのヘッダー、応答の内容、および応答が電子メール輸送システムに送信されるエンベロープなど、自動応答の内容の詳細を指定します。
The fields in the message header should be set as follows:
メッセージヘッダーのフィールドは、次のように設定する必要があります。
In correspondence between humans, the From field serves multiple purposes: It identifies the author of the message (or in some cases, the party or parties on whose behalf the message was sent), and it is the default destination of replies from humans. Unfortunately, some mail systems still send non-delivery reports and other kinds of automatic responses to the From address.
人間間の通信では、From Fieldは複数の目的を果たします。メッセージの著者（または場合によっては、メッセージが送信された当事者または当事者）を特定し、人間からの返信のデフォルトの目的地です。残念ながら、一部のメールシステムは、fromアドレスに対して非配信レポートやその他の種類の自動応答を依然として送信します。
For automatic responses, the role of the From field in determining the destination of replies to the response from humans is less significant, because in most cases it is not useful or appropriate for a human (or anyone) to reply to an automatic response. One exception is when there is some problem with the response; it should be possible to provide feedback to the person operating the responder.
自動応答の場合、人間からの応答に対する応答の目的地を決定する際のフィールドの役割はあまり重要ではありません。ほとんどの場合、人間（または誰）が自動応答に返信することは有用または適切ではないからです。1つの例外は、応答に問題がある場合です。レスポンダーを操作する人にフィードバックを提供できるはずです。
So in most cases the From address in an automatic response needs to be chosen according to the following criteria:
したがって、ほとんどの場合、自動応答のアドレスからのFROMを次の基準に従って選択する必要があります。
- To provide an indication of the party or agent on whose behalf the response was sent,
- 応答が送信された当事者またはエージェントの兆候を提供するために、
- To provide an address to which a recipient of an inappropriate response can request that the situation be corrected, and
- 不適切な対応の受信者が状況を修正することを要求できる住所を提供するために
- To diminish the potential for mail loops.
- メールループの可能性を減らすため。
The following behavior is thus recommended:
したがって、次の動作をお勧めします。
- For responses sent by Service Responders, the From field SHOULD contain an address which can be used to reach the (human) maintainer of that service. The human-readable portion of the From field (the display-name preceding the address) SHOULD contain a name or description of the service to identify the service to humans.
- サービスレスポンダーが送信した回答の場合、From Fieldには、そのサービスの（人間の）メンテナーに到達するために使用できるアドレスを含める必要があります。FROM FIRG（アドレスの前のディスプレイ名）の人間が読み取ることができる部分には、人間へのサービスを識別するためのサービスの名前または説明を含める必要があります。
- For responses sent by Personal Responders, the From field SHOULD contain the name of the recipient of the subject message (i.e., the user on whose behalf the response is being sent) and an address chosen by the recipient of the subject message to be recognizable to correspondents. Often this will be the same address that was used to send the subject message to that recipient.
- 個人の応答者が送信した回答については、From Fieldには、サブジェクトメッセージの受信者の名前（つまり、応答が送信されているユーザー）と、サブジェクトメッセージの受信者が選択したアドレスが認識できるように選択できるアドレスを含める必要があります。特派員。多くの場合、これはサブジェクトメッセージをその受信者に送信するために使用されたのと同じアドレスになります。
In the case of a recipient having multiple mail addresses forwarded to the same mailbox (and responder), a Personal Responder MAY use heuristics to guess, based on the information available in various message header fields, which of several addresses for that recipient the sender is likely to have used, and use that address in the From field of the response. However it MUST be possible for a recipient on whose behalf the responder is acting to explicitly specify the human-readable name and address to be used in the From header fields of responses.
同じメールボックス（およびレスポンダー）に転送された複数のメールアドレスを持っている受信者の場合、個人のレスポンダーは、さまざまなメッセージヘッダーフィールドで利用可能な情報に基づいて、ヒューリスティックを推測することができます。使用している可能性が高く、応答のフィールドからそのアドレスを使用します。ただし、レスポンダーが行動している受信者が、応答のヘッダーフィールドで使用される人間の読み取り可能な名前とアドレスを明示的に指定するように行動している必要があります。
Note: Due to privacy reasons it may be inappropriate for responders to disclose an address that is derived, say, from the recipient's login information (e.g., POP or IMAP user name or account name on a multiuser computer) or which discloses the specific name of the computer where the response was generated. Furthermore these do not necessarily produce a valid public email address for the recipient. For this reason, Personal Responders MUST allow the From field of a Personal Response to be set by the recipient on whose behalf the responder is acting.
注：プライバシーの理由により、レスポンダーが受信者のログイン情報（たとえば、Multiuser ComputerのPOPユーザー名またはアカウント名など）から派生したアドレスを開示することは不適切な場合があります。応答が生成されたコンピューター。さらに、これらは必ずしも受信者に有効な公開メールアドレスを作成するわけではありません。このため、個人の対応者は、個人の応答のフィールドから、レスポンダーが行動しているかどうかを受信者が設定することを許可する必要があります。
- For Group Responders, the From address SHOULD contain an email address which could be used to reach the maintainer of that Group Responder. Use of the Postmaster address for this purpose is NOT RECOMMENDED.
- グループレスポンダーの場合、FROMアドレスには、そのグループレスポンダーのメンテナーに到達するために使用できるメールアドレスを含める必要があります。この目的のためにポストマスターアドレスを使用することは推奨されません。
The human-readable portion of the From address (the "phrase" before the address, see [N2.RFC2822], section 3.2.6) SHOULD contain an indication of the function performed by the Group Responder and on whose behalf it operates (e.g., "Example Agency virus filter")
FROMアドレスの人間の読み取り可能な部分（アドレスの前の「フレーズ」、[n2.RFC2822]、セクション3.2.6を参照）には、グループレスポンダーが実行した関数とそれが運用する関数の兆候を含める必要があります（例えば、「エージェンシーウイルスフィルターの例」）
If a reply is expected by the responder, the Reply-To field of the response SHOULD be set to the address at which the reply is expected, even if this is the address of the same or another responder. Responders which request replies to be sent to responders MUST prevent mail loops and sorcerer's apprentice mode. Note that since (according to the previous section) the From field of the response SHOULD contain the address of a human, if the Reply-To field of the response is used to direct replies to a responder it will not be the same as the address in the From field.
応答者が返信が予想される場合、これが同じまたは別のレスポンダーのアドレスであっても、応答の返信フィールドを返信が予想されるアドレスに設定する必要があります。応答者が応答者に送信する応答者は、メールループと魔術師の見習いモードを防ぐ必要があります。（前のセクションによると）応答のフィールドは人間のアドレスを含める必要があるため、応答の返信フィールドを使用して応答者に対応する場合は、住所と同じではありません。フィールドから。
Discussion: this assumes that the human recipient's user agent will normally send replies to the Reply-To address (if present), as recommended by [I6.RFC822] since 1982, but that it is still possible for a recipient to reply to the From address if he or she finds it useful to do so. This is consistent with the intended use of these fields in [I6.RFC822] and [N2.RFC2822].
議論：これは、1982年以降[i6.rfc822]が推奨するように、人間の受信者のユーザーエージェントが通常、返信者（存在する場合）に返信を送信することを前提としていますが、受信者はから彼または彼女がそうするのが有用であると判断した場合はアドレスしてください。これは、[i6.rfc822]および[n2.rfc2822]でこれらのフィールドの使用を意図した使用と一致しています。
The To header field SHOULD indicate the recipient of the response. In general there SHOULD only be one recipient of any automatic response. This minimizes the potential for sorcerer's apprentice mode and denial-of-service attacks.
ヘッダーへのフィールドは、応答の受信者を示す必要があります。一般に、自動応答の受信者は1人だけでなければなりません。これにより、魔術師の見習いモードとサービス拒否攻撃の可能性が最小限に抑えられます。
The Date header field SHOULD indicate the date and time at which the response was generated. This MUST NOT be taken as any indication of the delivery date of the subject message, nor of the time at which the response was sent.
日付ヘッダーフィールドは、応答が生成された日付と時刻を示す必要があります。これは、サブジェクトメッセージの配信日、また応答が送信された時期の兆候として取られてはなりません。
The Subject field SHOULD contain a brief indication that the message is an automatic response, followed by contents of the Subject field (or a portion thereof) from the subject message. The prefix "Auto:" MAY be used as such an indication. If used, this prefix SHOULD be followed by an ASCII SPACE character (0x20).
サブジェクトフィールドには、メッセージが自動応答であるという簡単な兆候が含まれている必要があり、それに続いてサブジェクトフィールド（またはその一部）のコンテンツ（またはその一部）が続きます。接頭辞「Auto：」は、そのような兆候として使用できます。使用する場合は、このプレフィックスの後にASCIIスペース文字（0x20）が続く必要があります。
NOTE: Just as the (Latin-derived) prefix "Re:" that is commonly used to indicate human-generated responses is sometimes translated to other languages by mail user agents, or otherwise interpreted by mail user agents as indication that the message is a reply, so the (Greek) prefix "Auto:" may also be translated or used as a generic indication that the message is an automatic response. However the "Auto:" indication is intended only as an aid to humans in processing the message. Mail processing software SHOULD NOT assume that the presence of "Auto:" at the beginning of a Subject field is an indication that the message was automatically submitted.
注：（ラテン由来の）接頭辞「Re：」と同様に、これは一般的に人間で生成された応答を示すために使用されます。これは、メールユーザーエージェントによって他の言語に翻訳されることもあります。返信して、（ギリシャ語）接頭辞「Auto：」は、メッセージが自動応答であることを翻訳または一般的な兆候として使用することもできます。ただし、「自動：」の表示は、メッセージの処理において人間への援助としてのみ意図されています。メール処理ソフトウェアは、「Auto：」の存在が件名フィールドの先頭にあることが、メッセージが自動的に送信されたことを示していると想定してはなりません。
Note that the Subject field of the subject message may contain encoded-words formatted according to [N3.RFC2047] and [N4.RFC2231], and such text MAY be included in the Subject field of a response. In generating responses containing such fields there is rarely a need to decode and re-encode such text. It is usually sufficient to leave those encoded-words as they were in the subject message, merely prepending "Auto: " or other indication. However, it is still necessary to ensure that no line in the resulting Subject field that contains an encoded-word is greater than 76 ASCII characters in length (this refers to the encoded form, not the number of characters in the text being encoded). Also, if the responder truncates the Subject from the subject message it is necessary to avoid truncating Subject text in the middle of an encoded-word.
サブジェクトメッセージのサブジェクトフィールドには、[n3.RFC2047]および[n4.RFC2231]に従ってフォーマットされたエンコードワードが含まれている場合があり、そのようなテキストは応答の主題フィールドに含まれる場合があります。そのようなフィールドを含む応答を生成するには、そのようなテキストをデコードして再エンコードする必要性はほとんどありません。通常、それらのエンコードされた単語を主題メッセージに残して、単に「自動：」またはその他の兆候を準備するだけで十分です。ただし、エンコードされたワードを含む結果のサブジェクトフィールドに、長さ76のASCII文字を超えるラインがないことを確認する必要があります（これは、エンコードされたフォームを指し、テキストの文字の数をエンコードされているものではありません）。また、応答者がサブジェクトメッセージから被験者を切り捨てた場合、エンコードされた単語の途中でサブジェクトテキストが切り捨てられないようにする必要があります。
The In-Reply-To and References fields SHOULD be provided in the header of a response message if there was a Message-ID field in the subject message, according to the rules in [N2.RFC2822] section 3.6.4.
[N2.RFC2822]セクション3.6.4のルールに従って、サブジェクトメッセージにメッセージ-IDフィールドがある場合は、応答メッセージのヘッダーに該当するフィールドと参照フィールドを提供する必要があります。
The Auto-Submitted field, with a value of "auto-replied", SHOULD be included in the message header of any automatic response. See section 5.
自動応答のメッセージヘッダーに「自動修正」の値を持つ自動補助フィールドを含める必要があります。セクション5を参照してください。
A response MAY include a Precedence field [I4.RFC2076] in order to discourage responses from some kinds of responders which predate this specification. The field-body of the Precedence field MAY consist of the text "junk", "list", "bulk", or other text deemed appropriate by the responder. Because the Precedence field is non-standard and its interpretation varies widely, the use of Precedence is not specifically recommended by this specification, nor does this specification recommend any particular value for that field.
応答には、この仕様に先行するある種のレスポンダーからの応答を思いとどまらせるために、優先順位フィールド[I4.RFC2076]を含めることができます。優先順位フィールドのフィールドボディは、「ジャンク」、「リスト」、「バルク」、またはレスポンダーによって適切とみなされるその他のテキストで構成されている場合があります。優先順位フィールドは非標準であり、その解釈は大きく異なるため、この仕様では優先順位の使用は特に推奨されず、この仕様はそのフィールドの特定の値を推奨していません。
In general, messages sent by Personal or Group Responders SHOULD be brief, and in text/plain format. A multipart/alternative construct MAY be used to communicate responses in multiple languages, especially if in doing so it is desirable to use multiple charsets.
一般に、個人またはグループのレスポンダーから送信されたメッセージは、簡単なものであり、テキスト/プレーン形式である必要があります。マルチパート/代替コンストラクトを使用して、複数の言語で応答を通信するために使用できます。
Response messages SHOULD NOT include significant content from the subject message. In particular, Personal and Group responses SHOULD NOT contain non-text content from the subject message, and they SHOULD NOT include attachments from the subject message. Neither of these conditions applies to responders that specifically exist for the purpose of altering or translating content sent to them (for instance, a FORTRAN-to-C translator); however, such responders MUST employ measures to avoid being used as a means of laundering or forwarding undesirable content, such as spam or viruses.
応答メッセージは、サブジェクトメッセージから重要なコンテンツを含めるべきではありません。特に、個人およびグループの応答には、サブジェクトメッセージからテキスト以外のコンテンツを含めるべきではなく、サブジェクトメッセージからの添付ファイルを含めるべきではありません。これらの条件はどちらも、送信されたコンテンツを変更または翻訳する目的で具体的に存在するレスポンダーには適用されません（たとえば、fortran-to-c翻訳者）。ただし、そのような応答者は、スパムやウイルスなどの望ましくないコンテンツの洗濯や転送の手段として使用されないようにするための対策を採用する必要があります。
Note that when text from the Subject or other fields from the header of the subject message is included in the body of the response, it is necessary to decode any encoded-words that appeared in those fields before including in the message body, and to use an appropriate content-type, charset, and content-transfer-encoding. In some cases it may be necessary to transliterate text from the charset(s) used in the header of the subject message, to the charset(s) used in the body of the response. (It is much easier to implement a responder if text from the header of the subject message never needs to appear in the body of the response.)
サブジェクトまたはサブジェクトメッセージのヘッダーからの他のフィールドからのテキストが応答の本文に含まれている場合、メッセージ本文を含める前にそれらのフィールドに表示されたエンコードワードをデコードする必要があることに注意してください。適切なコンテンツタイプ、チャーセット、およびコンテンツ移動エンコード。場合によっては、サブジェクトメッセージのヘッダーで使用されているチャーセットから、応答の本体で使用されるcharset（s）までのテキストを音訳する必要がある場合があります。（サブジェクトメッセージのヘッダーからのテキストが応答の本体に表示される必要がない場合、レスポンダーを実装する方がはるかに簡単です。）
In general, it is appropriate to use Delivery Status Notifications (DSNs) for responses that are generated by the mail transport system as a result of attempts to relay, forward, or deliver mail, and only when the purpose of that response is to provide the sender of the subject message with information about the status of that mail delivery. For instance, a "virus scanner" which is activated by a mail delivery process to filter harmful content prior to delivery, could return a DSN with the Action field set to "failed" with a Status code of 5.7.1 (Delivery not authorized, message refused) if the entire message was not delivered due to security reasons; or it could return a DSN with the Action field set to "relayed" or "delivered" (as appropriate) with a Status code set to 2.6.4 (conversion with loss performed) if the message was relayed or delivered with the presumably harmful content removed. The DSN specification [I2.RFC3464], rather than this document, governs the generation and format of DSNs.
一般に、メール輸送システムによって生成される応答には、メール輸送システムによって生成される応答に配信ステータス通知（DSN）を使用することが適切です。そのメール配信のステータスに関する情報を含むサブジェクトメッセージの送信者。たとえば、配達前に有害なコンテンツをフィルタリングするためにメール配信プロセスによってアクティブ化される「ウイルススキャナー」は、アクションフィールドが5.7.1のステータスコードで「失敗」に設定されたDSNを返す可能性があります（配信は許可されていませんが、メッセージは拒否されました）セキュリティ上の理由によりメッセージ全体が配信されなかった場合。または、アクションフィールドが「リレー」または「配信」に設定されたDSNを返すことができます（必要に応じて）。削除。このドキュメントではなく、DSN仕様[I2.RFC3464]は、DSNSの生成と形式を規定しています。
Similarly, it is appropriate to use Message Disposition Notifications (MDNs) only for responses generated on the recipient's behalf, which are generated on or after delivery to a recipient's mailbox, and for which the purpose of the response is to indicate the disposition of the message. The MDN specification [I3.RFC3798], rather than this document, governs the generation and format of MDNs.
同様に、受信者に代わって生成された応答に対してのみメッセージ処分通知（MDN）を使用することが適切です。受信者のメールボックスへの配信および後に生成され、応答の目的はメッセージの処分を示すことです。。このドキュメントではなく、MDN仕様[I3.RFC3798]は、MDNの生成と形式を規定しています。
This document is not intended to alter either the DSN or MDN specifications. Responses that fit within the criteria of DSN or MDN, as defined by the respective specifications, should be generated according to the DSN or MDN specification rather than this document. Responses which do not fit one of these sets of criteria should be generated according to this document.
このドキュメントは、DSN仕様またはMDN仕様のいずれかを変更することではありません。DSNまたはMDNの基準内に適合する応答は、それぞれの仕様で定義されているように、このドキュメントではなくDSNまたはMDN仕様に従って生成する必要があります。これらの基準セットのいずれかに適合しない応答は、このドキュメントに従って生成する必要があります。
The SMTP MAIL FROM address, or other envelope return address used to send the message, SHOULD be chosen in such a way as to make mail loops unlikely. A loop might occur, for instance, if both sender and recipient of a message each have automatic responders - the recipient's responder sends mail to the sender's responder, which sends mail back to the recipient's responder.
アドレスからのSMTPメール、またはメッセージの送信に使用されるその他のエンベロープ返信アドレスは、メールループを可能にするような方法で選択する必要があります。たとえば、メッセージの送信者と受信者の両方がそれぞれ自動レスポンダーを持っている場合、ループが発生する可能性があります。受信者のレスポンダーは、送信者のレスポンダーにメールを送信し、メールを受信者のレスポンダーに送り返します。
The primary purpose of the MAIL FROM address is to serve as the destination for delivery status messages and other automatic responses. Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of <> MAY be used for this purpose. A MAIL FROM address which is specifically chosen for the purpose of sending automatic responses, and which will not automatically respond to any message sent to it, MAY be used instead of <>.
アドレスからのメールの主な目的は、配信ステータスメッセージやその他の自動応答の宛先として機能することです。ほとんどの場合、自動応答に応答することは適切ではなく、レスポンダーは配信ステータスメッセージに関心がないため、<>の住所からのメールがこの目的に使用される場合があります。自動応答を送信する目的で特別に選択され、それに送信されたメッセージに自動的に応答しない住所からのメールは、<>の代わりに使用できます。
The RCPT TO address will (of course) be the address of the intended recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER parameter of the RCPT command be specified if the SMTP server supports the DSN option [N5.RFC3461].
対処するRCPTは（もちろん）対応の意図された受信者のアドレスとなります。SMTPサーバーがDSNオプション[n5.RFC3461]をサポートする場合、rcptコマンドのneverパラメーターを指定することをお勧めします。
In general, automatic responses SHOULD be sent to the Return-Path field if generated after delivery. If the response is generated prior to delivery, the response SHOULD be sent to the reverse-path from the SMTP MAIL FROM command, or (in a non-SMTP system) to the envelope return address which serves as the destination for non-delivery reports.
一般に、配達後に生成された場合、自動応答を返品パスフィールドに送信する必要があります。配信前に応答が生成された場合、応答は、コマンドからSMTPメールから（非SMTPシステムで）SMTPメールから非配信レポートの宛先として機能するエンベロープ返信アドレスにリバースパスに送信する必要があります。。
If the response is to be generated after delivery, and there is no Return-Path field in the subject message, there is an implementation or configuration error in the SMTP server that delivered the message or gatewayed the message outside of SMTP. A Personal or Group responder SHOULD NOT deliver a response to any address other than that in the Return-Path field, even if the Return-Path field is missing. It is better to fix the problem with the mail delivery system than to rely on heuristics to guess the appropriate destination of the response. Such heuristics have been known to cause problems in the past.
応答が配信後に生成される場合、およびサブジェクトメッセージにリターンパスフィールドがない場合、メッセージを配信するか、SMTPの外側にメッセージをゲートウェイしたSMTPサーバーに実装または構成エラーがあります。個人またはグループのレスポンダーは、返品パスフィールドが欠落していても、返品パスフィールドのアドレス以外のアドレスへの応答を提供してはなりません。応答の適切な目的地を推測するために、ヒューリスティックに依存するよりも、メール配送システムの問題を修正する方が良いでしょう。このようなヒューリスティックは、過去に問題を引き起こすことが知られています。
A Service Responder MAY deliver the response to the address(es) from the >From field, or to another address from the request payload, provided this behavior is precisely defined in the specification for that service. Services responders SHOULD NOT use the Reply-To field for this purpose.
サービスレスポンダーは、この動作がそのサービスの仕様で正確に定義されていれば、フィールドから>> from from from from the Request Payloadからのアドレス（es）への応答を提供する場合があります。サービスレスポンダーは、この目的のために返信フィールドを使用しないでください。
The Reply-To field SHOULD NOT be used as the destination for automatic responses from Personal or Group Responders. In general, this field is set by a human sender based on his/her anticipation of how human recipients will respond to the specific content of that message. For instance, a human sender may use Reply-To to request that replies be sent to an entire mailing list. Even for replies from humans, there are cases where it is not appropriate to respond to the Reply-To address, especially if the sender has asked that replies be sent to a group and/or mailing list. Since a Personal or Group Responder operates on behalf of a human recipient, it is safer to assume that any Reply-To field present in the message was set by a human sender on the assumption that any reply would come from a human who had some understanding of the roles of the sender and other recipients. An automatic responder lacks the information necessary to understand those roles. Sending automatic responses to Reply-To addresses can thus result in a large number of people receiving a useless or unwanted message; it can also contribute to mail loops.
返信フィールドは、個人またはグループレスポンダーからの自動応答の宛先として使用しないでください。一般に、このフィールドは、人間の受信者がそのメッセージの特定のコンテンツにどのように反応するかについての彼/彼女の予想に基づいて、人間の送信者によって設定されます。たとえば、人間の送信者は、返信を使用して、返信をメーリングリスト全体に送信するよう要求する場合があります。人間からの返信の場合でも、特に送信者が返信をグループおよび/またはメーリングリストに送信することを求めた場合、返信者に応答することが適切ではない場合があります。個人またはグループのレスポンダーは人間の受信者に代わって動作するため、メッセージに存在する返信フィールドは、ある程度の理解がある人間からの返信が来ると仮定して、人間の送信者によって設定されたと仮定する方が安全です。送信者およびその他の受信者の役割の。自動レスポンダーには、それらの役割を理解するために必要な情報がありません。したがって、自動応答をアドレスに送信すると、役に立たないメッセージまたは不要なメッセージを受け取る多くの人々が得られる可能性があります。また、メールループに貢献できます。
Use of the From field as the destination for automatic responses has some of the same problems as use of Reply-To. In particular, the From field may list multiple addresses, while automatic responses should only be sent to a single address. In general, the From and Reply-To addresses are used in a variety of ways according to differing circumstances, and for this reason Personal or Group Responders cannot reliably assume that an address in the From or Reply-To field is an appropriate destination for the response. For these reasons the From field SHOULD NOT be used as a destination for automatic responses.
自動応答の宛先としてのFROMフィールドの使用には、Reply-Toの使用と同じ問題があります。特に、FROMは複数のアドレスをリストする場合がありますが、自動応答は単一のアドレスにのみ送信する必要があります。一般に、fromとReply-toアドレスは、さまざまな状況に応じてさまざまな方法で使用されます。このため、個人またはグループのレスポンダーは、FromまたはReply-to Fieldの住所が適切な目的地であると確実に想定することはできません。応答。これらの理由により、フィールドからの自動応答の宛先として使用されるべきではありません。
Similarly, the Sender field SHOULD NOT be used as the destination for automatic responses. This field is intended only to identify the person or entity that sent the message, and is not required to contain an address that is valid for replies.
同様に、送信者フィールドは、自動応答の宛先として使用しないでください。このフィールドは、メッセージを送信した個人または団体を識別することのみを目的としており、返信に有効なアドレスを含める必要はありません。
The Return-Path address is really the only one from the message header that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender.
Return-Pathアドレスは、プロトコルの問題として、送信者が予想していない自動応答に適していると予想できるメッセージヘッダーから実際に唯一のアドレスです。
The purpose of the Auto-Submitted header field is to indicate that the message was originated by an automatic process, or an automatic responder, rather than by a human; and to facilitate automatic filtering of messages from signal paths for which automatically generated messages and automatic responses are not desirable.
自動補助ヘッダーフィールドの目的は、メッセージが人間ではなく自動プロセス、または自動レスポンダーによって発信されたことを示すことです。また、自動的に生成されたメッセージと自動応答が望ましくない信号パスからのメッセージの自動フィルタリングを容易にするため。
The syntax of Auto-Submitted is as follows, using the ABNF notation of [N6.RFC2234]: auto-submitted-field = "Auto-Submitted:" [CFWS] auto-submitted [CFWS] CRLF
[n6.RFC2234]のABNF表記を使用して、自動供給の構文は次のとおりです。
auto-submitted = ( "no" / "auto-generated" /
"auto-replied" / extension )
opt-parameter-list
extension = token
opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
The symbols "CFWS" and "CRLF" are defined in [N2.RFC2822]. The symbols "token", and "parameter" are as defined in [N7.RFC2045] (as amended by [N4.RFC2231]).
シンボル「CFWS」と「CRLF」は[N2.RFC2822]で定義されています。シンボル「トークン」と「パラメーター」は、[n7.rfc2045]で定義されています（[n4.rfc2231]によって修正されます）。
The maximum number of Auto-Submitted fields that may appear in a message header is 1.
メッセージヘッダーに表示される可能性のある自動供給フィールドの最大数は1です。
The Auto-Submitted header field SHOULD NOT be supplied for messages that were manually submitted by a human. (However, user agents that allow senders to specify arbitrary fields SHOULD NOT prevent humans from setting the Auto-Submitted field, because it is sometimes useful for testing.)
自動補助ヘッダーフィールドは、人間によって手動で提出されたメッセージに提供されないでください。（ただし、送信者が任意のフィールドを指定できるようにするユーザーエージェントは、テストに有用な場合があるため、人間が自動供給フィールドの設定を防ぐべきではありません。）
The auto-generated keyword:
自動生成キーワード：
- SHOULD be used on messages generated by automatic (often periodic) processes (such as UNIX "cron jobs") which are not direct responses to other messages,
- 他のメッセージへの直接的な応答ではない、自動（多くの場合定期的な）プロセス（UNIX「Cron Jobs」など）によって生成されたメッセージで使用する必要があります。
- MUST NOT be used on manually generated messages,
- 手動で生成されたメッセージで使用しないでください。
- MUST NOT be used on a message issued in direct response to another message,
- 別のメッセージに直接対応して発行されたメッセージで使用してはなりません。
- MUST NOT be used to label Delivery Status Notifications (DSNs) [I2.RFC3464], or Message Disposition Notifications (MDNs) [I3.RFC3798], or other reports of message (non)receipt or (non)delivery. Note: Some widely-deployed SMTP implementations currently use "auto-generated" to label non-delivery reports. These should be changed to use "auto-replied" instead.
- 配信ステータス通知（DSNS）[I2.RFC3464]、メッセージ処分通知（MDNS）[I3.RFC3798]、またはメッセージ（非）領収書または（非）配信のその他のレポートに使用しないでください。注：現在、広く展開されているSMTP実装の一部は、現在「自動生成された」を使用して非配信レポートにラベルを付けています。これらは、代わりに「自動補償」を使用するように変更する必要があります。
The auto-replied keyword:
自動レプリーされたキーワード：
- SHOULD be used on messages sent in direct response to another message by an automatic process,
- 自動プロセスによって別のメッセージに直接応答して送信されたメッセージで使用する必要があります。
- MUST NOT be used on manually-generated messages,
- 手動で生成されたメッセージで使用しないでください、
- MAY be used on Delivery Status Notifications (DSNs) and Message Disposition Notifications (MDNs),
- 配信ステータス通知（DSNS）およびメッセージ処分通知（MDNS）で使用できます。
- MUST NOT be used on messages generated by automatic or periodic processes, except for messages which are automatic responses to other messages.
- 他のメッセージへの自動応答であるメッセージを除き、自動または定期的なプロセスによって生成されたメッセージで使用しないでください。
The "no" keyword MAY be used to explicitly indicate that a message was originated by a human, if for some reason this is found to be appropriate.
「いいえ」キーワードを使用して、何らかの理由でこれが適切であることが判明した場合、メッセージが人間によって発信されたことを明示的に示すことができます。
Extension keywords may be defined in the future, though it seems unlikely. The syntax and semantics of such keywords must be published as RFCs and approved using the IETF Consensus process [N8.RFC2434]. Keywords beginning with "x-" are reserved for experiments and use among consenting parties. Recipients of messages containing an Auto-Submitted field with any keyword other than "no" MAY assume that the message was not manually submitted by a human.
拡張キーワードは将来定義される場合がありますが、ありそうもないようです。このようなキーワードの構文とセマンティクスは、RFCSとして公開され、IETFコンセンサスプロセス[n8.RFC2434]を使用して承認される必要があります。「X-」から始まるキーワードは、実験のために予約され、同意者の間で使用されます。「いいえ」以外のキーワードを含む自動補助フィールドを含むメッセージの受信者は、メッセージが人間によって手動で提出されていないと仮定する場合があります。
Optional parameters may also be defined by an IETF Consensus process. The syntax of optional parameters is given here to allow for future definition should they be needed. Implementations of Auto-Submitted conforming to this specification MUST NOT fail to recognize an Auto-Submitted field and keyword that contains syntactically valid optional parameters, but such implementations MAY ignore those parameters if they are present. Parameter names beginning with "x-" are reserved for experiments and use among consenting parties.
オプションのパラメーターは、IETFコンセンサスプロセスによって定義される場合もあります。オプションのパラメーターの構文は、必要に応じて将来の定義を可能にするためにここに記載されています。この仕様に準拠した自動サブミットされた実装は、構文的に有効なオプションパラメーターを含む自動サブミットされたフィールドとキーワードを認識してはなりませんが、そのような実装は、それらが存在する場合、それらのパラメーターを無視する場合があります。「X-」で始まるパラメーター名は、実験のために予約され、同意者の間で使用されます。
The "comment" syntactical construct from [N2.RFC2822] can be used to indicate a reason why this message was automatically submitted.
[N2.RFC2822]の「コメント」構文コンストラクトを使用して、このメッセージが自動的に送信された理由を示すことができます。
Automatic responders introduce the potential for several kinds of attack, including:
自動応答者は、次のようないくつかの種類の攻撃の可能性を導入します。
- Use of such responders to relay harmful or abusive content (worms, viruses, spam, and spymail) for the purpose of wider distribution of the content or masking the source of such content;
- そのようなレスポンダーを使用して、コンテンツの幅広い分布またはそのようなコンテンツのソースをマスキングする目的で、有害または虐待的なコンテンツ（ワーム、ウイルス、スパム、スパイム油）を中継します。
- Use of such responders to mount denial-of-service attacks by using responders to relay messages to large numbers of addresses, or to flood individual mailboxes with a large amount of unwanted content, or both;
- レスポンダーを使用してメッセージを多数のアドレスに中継するか、個々のメールボックスを大量の不要なコンテンツ、またはその両方で浸水させることにより、そのようなレスポンダーをサービス拒否攻撃に使用します。
- Deliberate or accidental use of such responders to construct mail loops or "sorcerer's apprentice mode", thus taxing the resources of the mail transport system;
- メールループまたは「魔術師の見習いモード」を構築するために、そのようなレスポンダーを意図的または偶発的に使用して、郵便輸送システムのリソースに課税します。
- Use of such responders to determine whether recipient addresses are valid, especially when such information is not otherwise provided (e.g., SMTP RCPT or VRFY command responses) and is not intended to be disclosed;
- このようなレスポンダーを使用して、受信者アドレスが有効かどうかを判断するために、特にそのような情報が別の方法で提供されていない場合（例えば、SMTP RCPTまたはVRFYコマンド応答）、開示することを意図していない場合。
- Use of such responders to obtain personal information about recipients, including information about recipients' recent usage of his mailbox or recent activity;
- そのようなレスポンダーを使用して、受信者に関する情報を含む受信者に関する個人情報を取得するために、彼のメールボックスの最近の使用または最近のアクティビティを含む。
- In addition, the responder itself may be subject to attack by sending it large numbers of requests.
- さらに、レスポンダー自体は、多数のリクエストを送信することにより、攻撃を受ける場合があります。
This document attempts to reduce the vulnerability of responders to such attack, in particular by
このドキュメントは、特にそのような攻撃に対するレスポンダーの脆弱性を減らしようとしています。
- Recommending that responders not relay significant content from the subject message (thus minimizing the potential for use of responders to launder or amplify attacker-chosen content)
- レスポンダーが主題メッセージから重要なコンテンツを中継しないことを推奨します（したがって、攻撃者が選択したコンテンツを洗濯または増幅するためにレスポンダーを使用する可能性を最小限に抑えることができます）
- Recommending that responders clearly mark responses with the "Auto-Submitted: auto-replied" header field to distinguish them from messages originated by humans (in part, to minimize the potential for loops and denial-of-service attacks),
- レスポンダーは、人間が生み出したメッセージと区別するための「自動補助：自動補償」ヘッダーフィールドで応答を明確にマークすることを推奨します（部分的には、ループとサービス拒否攻撃の可能性を最小限に抑えます）。
- Recommending that Personal and Group Responders limit the number of responses sent to any individual per period of time (also limiting the potential damage caused by loops),
- 個人およびグループのレスポンダーが、期間ごとに個人に送信される応答の数を制限することを推奨します（ループによって引き起こされる潜在的なダメージを制限）、
- Recommending that responders respond to at most one address per incoming message (to minimize the potential for deliberate or accidental denial-of-service via "multiplication" or sorcerer's apprentice mode),
- レスポンダーは、着信メッセージごとに最大1つのアドレスに応答することを推奨します（「乗算」または魔術師の見習いモードを介して意図的または偶発的なサービスの可能性を最小限に抑えるため）、
- Recommending that responses from Personal and Group Responders should be brief and in plain text format (to minimize the potential for mail responders to be used as mechanisms for transmitting harmful content and/or disguising the source of harmful content).
- 個人およびグループレスポンダーからの応答は、簡単なテキスト形式であることを推奨します（有害なコンテンツを送信したり、有害なコンテンツのソースを偽装するメカニズムとして使用されるメールレスポンダーの可能性を最小限に抑えるため）。
However, because email addresses are easily forged, attacks are still possible for any email responder which does not limit access and require authentication before issuing a response. The above measures attempt to limit the damage which can be done, but they cannot entirely prevent attacks.
ただし、電子メールアドレスは簡単に偽造されるため、応答を発行する前にアクセスを制限せず、認証を必要とするメールレスポンダーの場合、攻撃はまだ可能です。上記の測定では、発生できる損傷を制限しようとしますが、攻撃を完全に防ぐことはできません。
This section describes vulnerabilities inherent in automatically responding to mail. Other vulnerabilities are associated with some mail-based services which automatically respond to email messages, but these are not caused by the fact that the server automatically responds to incoming messages. In general, any network-based service (including those accessed by email) needs to provide security that is sufficient to prevent the service from being used as a means to inappropriately or destructively access the resources that are accessible by the service.
このセクションでは、メールに自動的に応答することに固有の脆弱性について説明します。その他の脆弱性は、電子メールメッセージに自動的に応答するメールベースのサービスに関連付けられていますが、これらはサーバーが着信メッセージに自動的に応答するという事実に起因するものではありません。一般に、ネットワークベースのサービス（電子メールでアクセスしたものを含む）は、サービスがアクセスできるリソースに不適切または破壊的にアクセスする手段としてサービスが使用されるのを防ぐのに十分なセキュリティを提供する必要があります。
It has also been noted that Personal and Group Responders sometimes inappropriately disclose recipients' personal information. This might happen automatically (as when a Group Responder automatically supplies a recipient's personal or mobile telephone number as alternate contact information) or "manually". Automatically-generated information SHOULD NOT include personal information about the recipient which is not already known to, or easily available to, the sender of the subject message. User interfaces which allow recipients to supply response text SHOULD make it clear to the user that this information will be made available not only to local colleagues but also to the entire Internet, including potential attackers.
また、個人およびグループのレスポンダーが受信者の個人情報を不適切に開示することがあることも注目されています。これは自動的に発生する可能性があります（グループレスポンダーが代替連絡先情報として受信者の個人または携帯電話番号を自動的に提供する場合）または「手動で」。自動化された情報は、サブジェクトメッセージの送信者にまだ知られていない、または簡単に利用可能な受信者に関する個人情報を含めるべきではありません。受信者が応答テキストを提供できるようにするユーザーインターフェイスは、この情報が地元の同僚だけでなく、潜在的な攻撃者を含むインターネット全体にも利用可能になることをユーザーに明確にする必要があります。
This section illustrates how these recommendations might apply to a hypothetical "vacation" program that had the purpose of responding to a single recipient's mail during periods in which that recipient was busy or absent and unable to respond personally. This is intended as illustration only and is not a normative part of this standard.
このセクションでは、これらの推奨事項が、受信者が忙しく、不在で個人的に対応できない期間中に単一の受信者のメールに応答する目的を持っている仮想的な「休暇」プログラムに適用される方法を示しています。これはイラストのみとして意図されており、この標準の規範的な部分ではありません。
The vacation program is a Personal Responder.
休暇プログラムは個人的なレスポンダーです。
The vacation program refuses to respond to any message which:
休暇プログラムは、次のメッセージに応答することを拒否します。
- appears to be spam (for instance, if it has been labelled as advertising by the sender or as potential spam by some intermediary),
- スパムのように見えます（たとえば、それが送信者による広告としてラベル付けされている場合、または一部の仲介者による潜在的なスパムとして）、
- appears to contain a virus (for instance, if it contains an executable attachment),
- ウイルスが含まれているように見えます（たとえば、実行可能な添付ファイルが含まれている場合）、
- contains an Auto-Submitted header field,
- 自動補助ヘッダーフィールドが含まれています。
- has been sent a response within the previous 7 days,
- 過去7日以内に回答が送信されました。
- does not contain one of the recipient's addresses in a To, CC, Bcc, Resent-To, Resent-CC, or Resent-Bcc field,
- A、CC、BCC、Resent-To、Resent-CC、またはResent BCCフィールドの受信者のアドレスの1つは含まれていません。
- contains a Precedence field with a value of "list", "junk", or "bulk",
- 「リスト」、「ジャンク」、または「バルク」の値を持つ優先フィールドが含まれています。
- does not have a Return-Path address, or
- Return-Pathアドレスはありません
- has a Return-Path address of <>, or a Return-Path address of a form that is frequently used by non-delivery reports.
- <>のリターンパスアドレス、または非配信レポートで頻繁に使用されるフォームのリターンパスアドレスがあります。
The format of the vacation response is as follows:
休暇対応の形式は次のとおりです。
- The From header field is set to a name and email address specified by the user on whose behalf the responses are being sent. (On some systems it may be reasonable to have a default setting for the From field of vacation responses that is based on the user's account name and the domain name of the system.)
- From Headerフィールドは、応答が送信されているユーザーが指定した名前とメールアドレスに設定されます。（一部のシステムでは、ユーザーのアカウント名とシステムのドメイン名に基づいた休暇対応のフィールドのデフォルト設定があることが合理的かもしれません。）
- The Reply-To field is set only if explicitly configured by the user on whose behalf the responses are being sent. For example, a user might direct replies to a secretary or co-worker who has been delegated to handle important matters during his absence.
- 返信フィールドは、応答が送信されているユーザーによって明示的に設定された場合にのみ設定されます。たとえば、ユーザーは、不在中に重要な問題を処理するために委任された秘書または同僚に返信を向けることができます。
- The To field contains the address of the recipient of the response, as obtained from the Return-Path field of the subject message.
- TOフィールドには、サブジェクトメッセージの返品パスフィールドから取得されたように、応答の受信者のアドレスが含まれています。
- The Date field contains the date and time at which the response was generated.
- 日付フィールドには、応答が生成された日付と時刻が含まれます。
- The Subject field contains Auto: followed by a string chosen by the user on whose behalf the responses are being sent. A default setting of something like "away from my mail" might be appropriate. If the Subject field contains non-ASCII characters these are encoded per [N3.RFC2047].
- サブジェクトフィールドには自動が含まれています。その後、応答が送信されているユーザーが選択した文字列が続きます。「私のメールから離れて」のようなもののデフォルト設定が適切かもしれません。サブジェクトフィールドに非ASCII文字が含まれている場合、これらは[n3.rfc2047]ごとにエンコードされます。
- The In-Reply-To and References fields are generated from the subject message per [N2.RFC2822].
- In-Reply-toおよびReferencesフィールドは、[N2.RFC2822]ごとにサブジェクトメッセージから生成されます。
- The Auto-Submitted field has the value "auto-replied".
- 自動サブミットされたフィールドには、値「自動修正」があります。
- The message body contains some text specified by the user on whose behalf the response is being sent. A brief summary of the subject message is also included, consisting of From, To, Subject, Date, and a few lines of message text from the subject message. No attachments or non-text bodyparts are included in the response.
- メッセージ本文には、応答が送信されているユーザーが指定したテキストが含まれています。サブジェクトメッセージの簡単な要約も含まれており、サブジェクト、日付、およびサブジェクトメッセージからの数行のメッセージテキストで構成されています。応答には添付ファイルやテキスト以外のボディパートは含まれていません。
The SMTP MAIL FROM address of the message envelope is <>. The RCPT TO address in the message envelope is the address of the user to whom the response is being sent. NOTIFY=NEVER is also set in the RCPT TO line if permitted by the SMTP server.
メッセージエンベロープのアドレスからのSMTPメールは<>です。メッセージエンベロープでアドレス指定するRCPTは、応答が送信されているユーザーのアドレスです。SMTPサーバーで許可されている場合は、notify = neverはrcptに設定されます。
Section 5 of this document defines two new extension mechanisms - new keywords for the Auto-Submitted header field, and new optional parameters for the Auto-Submitted field. If at any point in the future new keywords or parameters are approved (through an IETF Consensus process) it may be appropriate for IANA to create a registry of such keywords or parameters.
このドキュメントのセクション5では、2つの新しい拡張メカニズムを定義します。自動サブミットされたヘッダーフィールドの新しいキーワードと、自動サブミットされたフィールドの新しいオプションパラメーターです。将来の任意の時点で、新しいキーワードまたはパラメーターが承認されている場合（IETFコンセンサスプロセスを通じて）、IANAがこのようなキーワードまたはパラメーターのレジストリを作成することが適切かもしれません。
In the mid-1990s Jeroen Houttuin of TERENA authored a series of internet-drafts on "Behavior of Mail Based Servers", and in particular, one document on "Answering Servers". While these documents were (to this author's knowledge) never formally published, they provided the first well-reasoned argument (known to this author) as to the best way for such servers to interface with email systems and protocols.
1990年代半ば、TerenaのJeroen Houttuinは、「メールベースのサーバーの動作」、特に「サーバーの回答」に関する1つのドキュメントに関する一連のインターネットドラフトを執筆しました。これらのドキュメントは（この著者の知識にとって）正式に公開されることはありませんでしたが、そのようなサーバーが電子メールシステムとプロトコルとインターフェイスする最良の方法について、最初の十分に熟した議論（この著者に知られています）を提供しました。
The idea for the Auto-Submitted field comes from the X.400/MHS mail system [I7.X420]. [I8.RFC2156] defined an "Autosubmitted" field for use when gatewaying between X.400 and Internet mail. Jacob Palme wrote an internet-draft defining use of the "Auto-Submitted" field for Internet mail, which made it through Last Call without significant objections, but got stalled in an attempt to resolve non-substantial objections. The definition of Auto-Submitted in this document is derived (i.e., slightly simplified) from the one in that document, with some text stolen outright.
自動供給フィールドのアイデアは、X.400/MHSメールシステム[I7.x420]に由来しています。[i8.RFC2156]は、X.400とインターネットメールの間のゲートウェイを使用するときに使用するための「AutoSubmitted」フィールドを定義しました。ジェイコブ・パルメは、インターネットメールの「自動供給」フィールドの使用を定義するインターネットドラフトを書きました。このドキュメントで自動補助された定義は、そのドキュメントの文書から派生している（つまり、わずかに簡素化されています）。
Thanks are also due to those who contributed suggestions to this document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield, Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera, Dan Kohn, Bruce Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg, Richard Rognlie, Markus Stumpf, Florian Weimer, and Dan Wing.
また、この文書に提案を提供してくれた人たちにも感謝します：ラス・オールベリー、アダム・コステロ、ネッド・フリード、ローレンス・グリーンフィールド、アート・ガルブランドセン、エリック・ホール、トニー・ハンセン、ヴィヴェク・キーラ、ダン・コーン、ブルース・リリー、チャールズ・リンジー、デル・マウス、リンドンンンネレンバーグ、リチャード・ログリー、マルクス・スタンプフ、フロリアン・ワイマー、ダン・ウィング。
[N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1.RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[N2.RFC2822] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[N3.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[N3.RFC2047] MOORE、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[N4.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[N4.RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2231、1997年11月。
[N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[N5.RFC3461] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[N6.RFC2234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[N7.RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[N8.RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[N8.RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[I1.JARGON] "Sorcerer's apprentice mode", originally from the Jargon file once maintained at MIT-AI and SAIL; now collected at various places on the net. See e.g., http://www.jargon.net/
[i1.jargon]「魔術師の見習いモード」、元々はかつてMit-aiとsailで維持されていた専門用語ファイルから。現在、ネット上のさまざまな場所で収集されています。例を参照、http：//www.jargon.net/
[I2.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[I2.RFC3464] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.
[i3.rfc3798] Hansen、T。およびG. Vaudreuil、eds。、「メッセージ処分通知」、RFC 3798、2004年5月。
[I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[i4.RFC2076] Palme、J。、「Common Internet Message Headers」、RFC 2076、1997年2月。
[I5.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.
[I5.RFC2369] Neufeld、G。およびJ. Baer、「コアメールリストコマンドのメタシンタックスとしてのURLの使用とメッセージヘッダーフィールドを介した輸送」、RFC 2369、1998年7月。
[I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[i6.RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[I7.X420] CCITT Recommendation X.420 (1992 E). Information technology - Message Handling Systems (MHS): Interpersonal messaging system, 1992.
[i7.x420] CCITT推奨X.420（1992 e）。情報技術 - メッセージ処理システム（MHS）：対人メッセージングシステム、1992。
[I8.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[i8.RFC2156]キル、S。、「ミキサー（MIMEインターネットX.400強化リレー）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
Author's Address
著者の連絡先
Keith Moore Innovative Computing Laboratory University of Tennessee, Knoxville 1122 Volunteer Blvd, #203 Knoxville, TN 37996-3450
キースムーアムーア革新的なコンピューティング研究所テネシー大学、ノックスビル1122ボランティアBlvd、＃203ノックスビル、テネシー州37996-3450
EMail: moore@cs.utk.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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エディター機能の資金は現在、インターネット協会によって提供されています。