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）インターネット協会（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.
このメモは自動的に「外出中」や「休暇」応答ジェネレータ、メールフィルタリングソフト、電子メールベースの情報サービス、およびその他の自動応答を含め、受信する電子メールメッセージに応答ソフトウェアのための勧告を行います。これらの勧告の目的は、自動メール応答者の間で均一な行動を（適切な）奨励するために、自動電子メール応答者の実装者の間で混乱のいくつかのソースをクリアするためには、そのようなソフトウェアが原因か、悪化する望ましくない動作を阻止することです。
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])
（注：用語「魔法使いの弟子モード」、いくつかの状況下で、メッセージの受信は、複数のメッセージを引き起こすプロトコルのバグのように定義され送信される、受信された場合、同じバグをトリガそれぞれが。）（ [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.
この文書は、インターネットの電子メールメッセージに範囲が限定されており、その勧告の多くは、具体的には、インターネットの電子メールメッセージおよびSMTPトランスポートの封筒で使用されるプロトコル要素とデータモデルに合わせて調整されています。インスタントメッセージング、SMS、またはユーズネットなどの他のメッセージング・コンテキストでこれらの提言の使用が考えられており、この文書の範囲外であるされていません。
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標準で定義されている - メッセージトランスポートシステムによるメッセージ配信のステータスを報告することを意図している配信状態通知[I2.RFC3464]、およびメッセージ処分通知[I3.RFC3798]でありますそれは受信者のメールボックスに到達した後にメッセージの気質の報告することを意図しました。これらの応答は、この文書は、彼らがまたは使用すべきではないはずです具体的な例を推奨していることを除いて、他の場所で定義されており、この文書の範囲内で、一般的ではありませんされています。
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,
- またはメッセージが読み、あるいはある程度の時間のために、上の行動することはほとんどありません、メッセージの送信者に通知することを意図している「休暇」の通知、「オフィスの外」、
- "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.
応答者のための適切な行動が一つのクラスから別のものに変わります。 （送信者が自動応答を期待している）サービスレスポンダから適切であるかもしれない行動は個人レスポンダから適切ではないかもしれません。例えば、サービスResponderは、そのサービスのニーズに応じて、非常に長い要求に応答して、あるいは人間が読める形式でないものを送信することがあります。しかし、個人Responderは人間が応答を読んでいることを前提とし、プレーンテキストのみの簡単な応答を送信する必要があります。
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].
キーワード "MUST"、 "MUST NOT"、 "RECOMMENDED"、 "SHOULD NOTは" "べきでは"、 "RECOMMENDED NOT"、および本書で[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".
- 自動応答は、そのフィールドが「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の、TO、憤慨-TO、憤慨-CC、または憤慨-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.
注意：件名メッセージの送信者が明示的に配信されたメッセージに出現するのBccフィールドなし「のBcc」受信者として受信者のアドレスを指定することができるようになるそのうちのいくつかのBccフィールドの使用を、様々なRFC 2822社のセクション3.6.3許可証を、または受信者のアドレスを含む配信されるメッセージ内のBccフィールドなし。しかし、Bccの者はほとんど使用されていないかもしれないので、受信者が明示的に、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.
- 個人およびグループレスポンダが知られている特派またはそれ以外の場合は「信頼できる」個人のアドレスを除いて応答を生成するために拒否することができます。このような応答はまた、「信頼できる」対「信頼できない」アドレスに対する応答の種類を生成することがあります。これは、任意のアドレスへの個人情報の不適切な開示を避けるために、例えば、役に立つかもしれません。
- 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メール例えば、FROMまたはリターンパスは、<>である）を生成してはいけません。レスポンダは、一般的に応答でリターンアドレスとして使用されるアドレスのための応答を生成するために拒否することができる - 例えば、「所有者 - *」、「* -requestを」一致するローカルパートを持つもの、「MAILER-DAEMON」などのレスポンダをチェックすることをお勧めします配信または有用性は低いことができない応答の生成を回避するために、応答を生成する前に妥当性の宛先アドレス。
- 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]「リスト」の値とレスポンダは、トラフィックがメーリングリストから到着したことを推測し、応答が唯一の個人のために意図された場合に応答しないでしょうメッセージ。同様の理由により、レスポンダはリスト - *フィールド[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アドレスに配信不能レポートと自動応答の他の種類を送信します。
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.
ほとんどのケースでは、自動応答に返信するために、ヒト（または誰）のために有用であるか、適切ではありませんので、自動応答のために、人間からの応答への応答の送信先を決定する際のFromフィールドの役割は、あまり重要です。応答でいくつかの問題がある場合は例外です。応答を操作者にフィードバックを提供することが可能でなければなりません。
So in most cases the From address in an automatic response needs to be chosen according to the following criteria:
だから、ほとんどの場合、自動応答内のアドレスから、次の基準に従って選択する必要があります：
- 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フィールド（アドレスの前に表示名）の人間可読部分は、ヒトへのサービスを識別するために、サービスの名前または説明を含むべきです。
- 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フィールド件名メッセージの受信者の名前が含まれているべきである（すなわち、その代理として応答上のユーザが送信されている）と対象メッセージの受信者が選択したアドレスが認識可能であることを特派へ。多くの場合、これはその受信者に件名メッセージを送信するために使用したのと同じアドレスになります。
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.
受信者のログイン情報（マルチユーザのコンピュータ上の例えば、POPやIMAPユーザー名またはアカウント名）から、たとえば、原因応答が導出されたアドレスを開示することは不適切であり、プライバシー上の理由や、特定の名前を開示している注：レスポンスが生成されたコンピュータ。さらに、これらは必ずしも受信者の有効な公開電子メールアドレスを生成しません。このため、個人レスポンダは、個人的なレスポンスのフィールドから応答が動作しているその代わりに、受信者によって設定されるようにする必要があります。
- 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.
- グループレスポンダの場合、アドレスからそのグループレスポンダのメンテナに到達するために使用できる電子メールアドレスを含むべきです。この目的のためのポストマスターのアドレスの使用は推奨されません。
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")
アドレス（アドレスの前に「フレーズ」、[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
ディスカッション：これは1982年以来[I6.RFC822]によって推奨されているように、人間の受信者のユーザーエージェントは、通常、返信するには（存在する場合）アドレスへの応答を送信することを前提としていますが、それはまだ可能であること
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].
彼または彼女が見つかった場合、受信者がアドレスからに返信することは便利そうします。これは、[N2.RFC2822] [I6.RFC822]でこれらのフィールドの使用目的と一致しています。
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.
Toヘッダフィールドは、応答の受信者を示すべきです。一般的にのみ任意自動応答の受信者が存在すべきです。これは、魔法使いの弟子モードとサービス拒否攻撃の可能性を最小限に抑えることができます。
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).
件名フィールドは、メッセージは、対象メッセージから件名フィールド（またはその一部）の内容に続いて、自動応答であることを簡単に指示を含むべきです。接頭辞「オート：」そのような指示として使用することができます。使用している場合、このプレフィックスは、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.
注：それは、一般的に、時々メールユーザエージェントによって他の言語に翻訳、または他のメッセージであることを示すように、メールユーザエージェントによって解釈される人間生成された応答を示すために使用される：ちょうど（ラテン語に由来する）の接頭辞「再」としてまた、翻訳され得るか、またはメッセージが自動応答であると一般的な指標として使用：（ギリシャ語）接頭辞「自動」に、返信。しかし「オート：」表示はメッセージのみを処理中に、ヒトへの支援を目的としています。 「オート：」件名欄の冒頭で、メッセージが自動的に提出されたことを示すものであるメール処理ソフトウェアはの存在がいることを仮定するべきではありません。
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.
メッセージIDフィールドは、対象のメッセージであった場合には、返信し、参照フィールドが[N2.RFC2822]セクション3.6.4の規則に従って、応答メッセージのヘッダに提供されるべきです。
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】優先順位フィールドを含んでいてもよいです。 Precedenceフィールドのフィールド・ボディには、テキスト「ジャンク」、「リスト」、「バルク」から構成されてもよく、または他のテキストは、応答者によって適切と思われます。優先順位フィールドは非標準であり、その解釈が大きく異なるので、優先順位の使用は、特にこの仕様で推奨されていない、また、この仕様は、そのフィールドの任意の特定の値を推奨ありません。
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.
一般的には、個人またはグループのレスポンダによって送信されたメッセージは簡潔であり、text / plainの形式ですべきです。マルチパート/代替構築物は、そうすることで、複数の文字セットを使用することが望ましい場合は特に、複数の言語で応答を通信するために使用され得ます。
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ツー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.)
件名メッセージのヘッダから被写体又は他のフィールドからのテキストは、応答のボディに含まれるとき、メッセージ本文に含める前に、これらのフィールドに現れ、任意の符号化されたワードをデコードするために必要であることに注意し、使用します適切なコンテンツタイプ、文字セット、およびコンテンツ転送エンコード。場合によっては、応答のボディに使用される文字セット（単数または複数）に、対象メッセージのヘッダーに使用される文字セット（複数可）からテキストを翻字する必要があるかもしれません。 （件名メッセージのヘッダからのテキストは応答の本文に表示する必要はありません場合は、レスポンダを実装する方がはるかに簡単です。）
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のステータスコード（配達許可されていないと「失敗」に設定ActionフィールドでDSNを返すことができますメッセージ全体がセキュリティ上の理由で配信されなかった場合、メッセージ）が拒否しました。アクションフィールドは、「中継」に設定するか、またはメッセージがおそらく有害コンテンツに中継され又は送達された場合2.6.4（実行損失の変換）に設定されたステータスコードを（適宜）「配信」またはそれがDSNを返すことができ削除しました。 DSN仕様は[I2.RFC3464]、むしろこの文書よりも、のDSNの生成およびフォーマットを司ります。
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仕様は[I3.RFC3798]、むしろこの文書よりも、開封通知の生成およびフォーマットを規定します。
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.
FROMアドレスのSMTP MAIL、またはメッセージを送信するために使用される他のエンベロープのリターンアドレスは、メールがそうループさせるような方法で選択する必要があります。送信者とメッセージの受信者の両方が、それぞれが自動応答を持っている場合、ループは、例えば、発生する可能性があります - 受信者の応答が戻って、受信者の応答者にメールを送信し、送信者の応答、にメールを送信します。
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 <>.
MAIL FROMアドレスの主な目的は、配信ステータスメッセージおよびその他の自動応答のための宛先として機能することです。ほとんどのケースでは、自動応答に対応するために適切ではない、と応答者が配送ステータスメッセージに興味を持っていないので、のアドレスからのメールは、<>この目的に使用することができます。自動的に送信されたメッセージに応答しないであろう具体的に自動応答を送信するために選択されるMAIL FROMアドレスとは、代わりに<>を用いてもよいです。
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 TOアドレスは（もちろん）応答の意図した受信者のアドレスになります。 SMTPサーバがDSNオプション[N5.RFC3461]をサポートしている場合、RCPTコマンドのNOTIFY = 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メールからリバースパスに送信、またはされてください。
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.
サービスレスポンダは、正確にそのサービスの仕様で定義され、この動作を提供>フィールドから、又は要求のペイロードから別のアドレスへのアドレス（複数可）に対する応答を、送達することができます。サービスの応答者は、この目的のために返信-Toフィールドを使用しないでください。
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.
返信先フィールドは、個人またはグループのレスポンダからの自動応答のための宛先として使用しないでください。一般的には、このフィールドは、人間の受信者がそのメッセージの具体的な内容にどのように応答するかを、彼/彼女の期待感に基づいて人間の送信者によって設定されています。例えば、人間の送信者は、応答が全体のメーリングリストに送信することを要求するために、返信先を使用することができます。でも、人間からの応答を、送信者がグループおよび/またはメーリングリストに送られる返信その求めている場合は特に、返信先アドレスに対応することが適切でない場合があります。個人またはグループResponderが人間の受取人に代わって動作するので、任意の返信へのメッセージでは、本フィールドは任意の応答がいくつか理解していた人から来ることを前提に人間の送信者によって設定されたと仮定する方が安全です送信者と他の受信者の役割。自動応答は、それらの役割を理解するために必要な情報が欠けています。返信先アドレスのために自動応答を送信すると、無駄なまたは不要なメッセージを受信する人が多数になることができます。それはまた、ループを郵送するために貢献することができます。
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フィールドの使用は、返信先の使用と同じ問題のいくつかを持っています。自動応答は、単一のアドレスに送信されなければならない一方で、特に、フィールドから、複数のアドレスをリストすることがあります。一般的には、返信にアドレスからとは異なる状況に応じてさまざまな方法で使用されており、このような理由のために個人またはグループレスポンダは確実から、または返信先フィールドのアドレスは、のために適切な宛先であると仮定することはできません応答。これらの理由から、フィールドからの自動応答のための宛先として使用しないでください。
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.
同様に、Senderフィールドには、自動応答の送信先として使用しないでください。このフィールドは、メッセージを送信した人またはエンティティを識別するためだけのものであり、回答のための有効なアドレスを格納する必要はありません。
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.
リターンパスアドレスは、送信者が予想していなかった自動応答のために適していることが、プロトコルの問題として、本当に期待できるメッセージヘッダからの唯一のものです。
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]:
【N6.RFC2234]のABNF表記法を使用して、次のように自動提出の構文は次のとおりです。
auto-submitted-field = "Auto-Submitted:" [CFWS] auto-submitted [CFWS] CRLF
自動提出 - フィールド=「自動提出：」[CFWS]自動提出[CFWS] CRLF
auto-submitted = ( "no" / "auto-generated" / "auto-replied" / extension ) opt-parameter-list
自動提出=（「なし」/「自動生成」/「オート答えた」/拡張）オプトパラメータリスト
extension = token
拡張子=トークン
opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
オプトパラメータリスト= *（[CFWS] "" [CFWS]パラメータ）
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]で定義されています。 （[N4.RFC2231]によって修正されるように）[N7.RFC2045]で定義されるように記号「トークン」、及び「パラメータ」です。
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ジョブ」など）自動（多くの場合、定期的な）プロセスによって生成されたメッセージで使用する必要があり、
- 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.
- 配信状態通知（DSN）[I2.RFC3464]、またはMessage処分通知（開封通知）[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),
- 配信状態通知（DSN）とメッセージ処分通知（開封通知）に使用されるかもしれ、
- 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.
それは考えにくいものの拡張キーワードは、将来的に定義されてもよいです。このようなキーワードの構文と意味はRFCとして公開され、[N8.RFC2434] IETFコンセンサス・プロセスを使用して承認されなければなりません。 「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;
- そのような応答の使用は、より広いコンテンツの配信や、コンテンツのソースをマスクする目的のために有害または不正なコンテンツ（ワーム、ウィルス、スパム、及びspymail）を中継します。
- 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.
また、個人やグループレスポンダは時々不適切受信者の個人情報を開示することが指摘されています。これは、または「手動」（グループResponderが自動的に代替の連絡先情報として、受信者の個人や携帯電話番号を供給するときのように）自動的に発生することがあります。自動的に生成された情報は、既にに知られている、または件名のメッセージの送信者に容易に入手されていない受信者に関する個人情報を含めるべきではありません。受信者がこの情報は潜在的な攻撃者を含め、地元の同僚にも、インターネット全体に限らず利用できるようになり、ユーザーにそれを明確にするべきで応答テキストを供給できるようにするユーザー・インターフェース。
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,
- に、CC、Bccの、のResent-に、憤慨し-CC、または憤慨し-BCCフィールドに受信者のアドレスのいずれかを含んでいません、
- contains a Precedence field with a value of "list", "junk", or "bulk",
- 「リスト」、「ジャンク」、または「バルク」の値が優先フィールドが含まれています、
- does not have a Return-Path address, or
- リターンパスアドレスを持っていない、または
- 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ヘッダーフィールドは、応答が送信されているその代わりに、ユーザーが指定した名前と電子メールアドレスに設定されています。 （いくつかのシステムでは、ユーザーのアカウント名とシステムのドメイン名に基づいて休暇応答のFromフィールドのデフォルト設定を持つことが合理的かもしれません。）
- 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.
- 件名メッセージのリターンパスフィールドから得られたフィールドに、応答の受信者のアドレスが含まれています。
- 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].
- Subjectフィールドが自動含まれています応答が送信されているその代わりに、ユーザーが選択した文字列が続きます。 「離れて私のメールから」のようなもののデフォルト設定は適切かもしれません。件名]フィールドにASCII以外の文字が含まれている場合、これらは[N3.RFC2047]ごとにコードされています。
- The In-Reply-To and References fields are generated from the subject message per [N2.RFC2822].
- イン返信し、参照フィールドが[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 MAILは<>です。メッセージエンベロープのRCPT TOアドレスは、応答が送信されてされているユーザのアドレスです。 NOTIFY =また、SMTPサーバーで許可されている場合の行に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のイェルーンHouttuinは、「メールベースのサーバの動作」のインターネットドラフトのシリーズを執筆し、特に、「応答サーバ」上の一つの文書。これらの文書は（この著者の知識に）決して正式に公表されなかったが、彼らはそのようなサーバは、電子メールシステムとプロトコルとインタフェースするための最良の方法のように（この作者に知られている）最初に、よく考えた引数を提供します。
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.
自動送信されたフィールドのためのアイデアは、[I7.X420] X.400 / MHSメールシステムから来ています。 X.400とインターネットメールの間ゲートウェイ処理時に[I8.RFC2156]使用するため、「Autosubmitted」フィールドを定義しました。ヤコブパルメは、重大な異議のないラストコールを通してそれを作ったインターネットメールのための「自動提出」フィールドの使用を定義するインターネットドラフトを書いたが、非かなりの異議を解決しようとする試みで失速してしまいました。本書で自動提出の定義は完全に盗まれたいくつかのテキストと、その文書内の1つから（すなわち、わずかに単純化された）が導かれます。
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.
ラスAllbery、アダム・コステロ、ネッドフリード、ローレンス・グリーンフィールド、ARNT Gulbrandsenの、エリック・ホール、トニー・ハンセン、のVivek Khera、ダンコーン、ブルース・リリー、チャールズリンジー、デア・マウス、リンドン：おかげでも、この文書への提案を貢献した人々によるものですNerenberg、リチャードRognlie、マルクスStumpfの、フロリアンWeimerさん、そしてダン・ウィング。
[N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1.RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[N2.RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、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]ムーア、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.
、RFC 2231、1997年11月：[N4.RFC2231]、N.、およびK.ムーア、 "文字セット、言語、および継続のMIMEパラメータ値およびエンコードされたWordの拡張機能を" フリード。
[N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[N5.RFC3461]ムーア、K.、RFC 3461 "配信状態通知（DSN）のための簡易メール転送プロトコル（SMTP）サービス拡張"、2003年1月。
[N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[N6.RFC2234]クロッカー、D.、エド。そして、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]ムーア、K.とG.ボードルイ、RFC 3464、2003年1月、 "配信状態通知のための広げることができるメッセージフォーマット"。
[I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004.
[I3.RFC3798]ハンセン、T.およびG.ボードルイ、編、 "メッセージ処分通知"、RFC 3798、2004年5月。
[I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[I4.RFC2076]パルメ、J.、 "一般的なインターネットメッセージヘッダ"、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]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[I6.RFC822]クロッカー、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] Kille、S.、 "MIXER（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ボランティアブルバード、＃203ノックスビル、テネシー州37996から3450
EMail: moore@cs.utk.edu
メールアドレス：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。