RFC3834 日本語訳
3834 Recommendations for Automatic Responses to Electronic Mail. K.Moore. August 2004. (Format: TXT=53119 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Moore Request for Comments: 3834 University of Tennessee Category: Standards Track August 2004
コメントを求めるワーキンググループK.ムーア要求をネットワークでつないでください: 3834年のテネシー大学カテゴリ: 標準化過程2004年8月
Recommendations for Automatic Responses to Electronic Mail
電子メールへの自動応答のための推薦
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このメモは自動的に入って来る電子メールメッセージに反応するソフトウェアのための推薦状をします、「オフィス」か「休暇」応答ジェネレータと、メールフィルタリングソフトと、メールベースの情報サービスと、他の自動応答者を含んでいて。 これらの推薦の目的は、そのようなソフトウェアによって引き起こされるか、またはいらいらさせられる好ましくない行動に水をさしていて、自動メール応答者の中で一定の振舞い(適切であるところ)を奨励して、自動メール応答者の作成者の中で混乱の何人かの源を解決することです。
1. Introduction
1. 序論
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]からの)
Moore Standards Track [Page 1] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[1ページ]RFC3834
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、またはUsenetなどの他のメッセージング文脈におけるこれらの推薦の使用は、考えられていなくて、このドキュメントの範囲の外にあります。
1.1. Types of automatic responses
1.1. 自動応答のタイプ
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.
いくつかの異なったタイプの自動応答があります。 少なくとも2つのタイプの自動応答はIETF規格で定義されました--受信者のメールボックスに達した後にメッセージ輸送システム、および報告することを意図するメッセージの気質のMessage Disposition Notifications[I3.RFC3798]によるメッセージ配送の状態を報告することを意図する配送Status Notifications[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,
- 「オフィス」か「休暇」通知。(その通知はいつかの時間読まれそうにないか、メッセージが影響されそうにないことをメッセージの送付者に知らせるつもりです)。
- "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
- そしてそれを除いて、それらと同様の情報サービスが、他のプログラムからメッセージを受け入れることを意図すると上に言及した。
Moore Standards Track [Page 2] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[2ページ]RFC3834
- 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.
- 「サービスResponders」は、電子メールのリクエストと応答で何らかのサービスへのアクセスを提供するために存在しています。 これらは永久に1つ以上のEメールアドレスに関連しています、そして、そのようなアドレスに発信するとき、おそらく、送付者は自動応答を予想します。 メールベースのファイル検索サービスはService Responderに関する例です。 メールで作られているというアポイントメント要求を許して、そのような要求に応じるカレンダーサービスはService Responderに関する別の例でしょう。
- "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.
- 「個人的なResponders」は、受取人かメッセージを読んでいるその受取人、ただ一つの受取人アドレスを代表して自動応答をするように存在しています。 1受取人あたり1個のベースで指定された評価基準に従って、これらの応答者は働いています。 UNIX「休暇」プログラムはパーソナルResponderに関する例です。 また、ただ一つのアドレスに送られたメールを受け入れて、コンテンツを分析して、分類するのを試みて、次にその分類に依存する応答を発行する応答者はパーソナルResponderです。
- "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.
- 「グループResponders」は、応答の前か実際の受取人からの応答重要な受取人アドレス(たとえば、特定のDNSドメインのすべての受取人)のどれかを代表して自動応答をするように存在しています。 Group Responderの場合では、応じる評価基準がaに設定されないのを除いて、グループRespondersがパーソナルRespondersと同様である、-、受取人基礎。 特定のサーバでどんな受取人にも送られたすべてのメールをフィルターにかけて、変えられたフォームでメッセージを拒絶したか、または送ったとき応答を送った「ウイルス・スキャナー」プログラムはGroup Responderに関する例であるかもしれません。
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
応答者のための適切な行動は1つのクラスから別のものに異なります。 Service Responder(送付者が自動応答を予想しているところ)から適切であるかもしれない振舞いはパーソナルResponderから適切でないかもしれません。 例えば、Service Responderは人間が読める形式にはない要求、またはものへの非常に長い応答を送るかもしれません、その必要性に従って
Moore Standards Track [Page 3] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[3ページ]RFC3834
service. However a Personal Responder should assume that a human being is reading the response and send only brief responses in plain text.
サービス。 しかしながら、パーソナルResponderは人間が応答を読んでいると仮定して、プレーンテキストにおける簡潔応答だけを送るはずです。
1.2. Notation and Definitions
1.2. 記法と定義
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"、「必須NOT」“SHOULD"、「[N1.RFC2119]で説明されるように本書では」 「推薦されたNOT」、「推薦され」て、および「5月」を解釈してはいけないべきですか?
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.
別の方法で指定されない場合、「受取人」という用語は対象のメッセージが送られた(例えば、応答が送られたアドレスよりむしろ)Eメールアドレスを示します。 「受取人」アドレスは永久に、応答者に関連しているかもしれませんか、それがメールがいくつかの条件のもとで応答者によって答えられる人間のアドレスであるかもしれません。
2. When (not) to send automatic responses
2. 自動応答を送る(not)です。
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.
自動応答者は盲目的に受け取られたあらゆるメッセージのための応答を送ってはいけません。 実際には、数種類の受信されたメッセージ、例えば、輪の防止のために応じて、「ばらまく」応じるかウイルスを避けて、受取人(例えば受取人が最近彼のメールを読んでいないという自動指示を避ける)に関する不適当に顕な個人情報を避ける虐待的なメッセージを洗濯するか、または増幅する手段として使用されるのを避けて、応答者に対してサービス不能攻撃を阻むのを拒否する理由がいつもあります。 応答者の目的によると、応じるかどうか決める評価基準は1人の応答者から別の応答者まで異なるでしょう。 一般に、注意は、役に立たないか余分な応答を送るのを避けて、輪を郵送するために貢献するのを避けるために取るべきであるか、またはサービス不能攻撃を容易にするべきです。
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".
- 自動応答SHOULD NOT、Autoによって提出されたヘッダーフィールドを含むどんなメッセージに対応して発行されてください(以下を見てください)、その分野には「いいえ」を除いたどんな値もあるところで。
Moore Standards Track [Page 4] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[4ページ]RFC3834
- 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.
- メッセージ(例えば、「私のメールから遠くへ」か「忙し過ぎる」通知)SHOULD NOTに読み込むことができないか、受取人のものが答えることができないことに関するメッセージについて送付者に通知することを意図する個人的、そして、Group応答は数日の期間以内に一度より多くの同じ送付者への同じ応答を発行します、その送付者が複数のメッセージを送ったかもしれませんが。 7日間の期間はデフォルトとしてRECOMMENDEDです。
- 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.
- 目的がある個人的、そして、Group応答、受取人にとって、有効なアドレスが受取人に明らかに含まれていない場合受取人(例えば、「休暇」と「オフィス」に気付く)SHOULD NOTの一時的な不在に関するメッセージについて送付者に通知するために、発行されてください、(例えば、To、Cc、Bcc、Resent、-、Resent- Bcc) Resent-cc、または対象のメッセージの分野。 受取人が同じメールボックス、受取人SHOULDに複数のアドレスを転送させるかもしれないので、1セットの応答者へのそれがその受取人にとって有効であるとして認識するアドレスを指定できてください。
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野原なしで受取人のアドレスを明らかに指定する対象のメッセージの送付者を許容するだろうBcc分野の用途を変えるRFC2822部3.6の.3個の許可証。 しかしながら、恐らくBccのものがめったに使用されないので、受取人がTo、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.
- パーソナルとGroup Respondersは、別の方法で「信じられた」個人の知られている通信員かアドレスを除いて、応答を発生させるのを拒否するかもしれません。 また、そのような応答者は「信頼されていなく」に対して「信じられた」アドレスのための異種の応答を発生させるかもしれません。 例えば、これは、個人情報の不適当な公開を任意のアドレスとして避けるために役に立つかもしれません。
- 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 MAIL FROMかReturn-経路が<>であるアドレス)である少しの応答も発生させてはいけません、応答が役に立つ送付先に届けられないでしょう、したがって。 「応答者は、返送先として応答者によって一般的に使用されたアドレスのための応答を発生させるのを拒否するかもしれません--例えば、地方の部分が「所有者*」に合っているそれら」、*要求、」、「メーラ・デーモン」など 渡すことができないか、または役に立ちそうにない応答を発生させるのを避けるために応答を発生させる前に応答者が正当性がないかどうか送付先アドレスをチェックするよう奨励されます。
Moore Standards Track [Page 5] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[5ページ]RFC3834
- 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.
- スパムと、そして、Service Responders SHOULDからのある種類の攻撃、自動応答に応じるのを避けて、非常に奇形の要求のために送られないでください。 これは、対象のメッセージで満足しているタイプと内容がそのサービスに適切になるのをチェックするのを含むかもしれません。
- 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.
- かなりの大多数のメールが非認証されて、返送先が容易に作り出されるので、要求が実際にパーティーによって認可されたという特定の知識のない大きい応答(たとえば、かなり多くのキロバイト)は、サービス不能攻撃(すなわち、求められていない内容がある洪水メールボックスへの)サービスResponders SHOULDの手段が戻らないので使用されるのを避けるために応答が送られるアドレスと交際しました。 同様に、Service Responders SHOULDは要求が影響を受けた当事者によって認可されたという手頃な保証なしで求められていないサイド効果(メーリングリストに送付者を申し込むことなどの)を引き起こしません。
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.)
- 応答者は、どんなヘッダーも含む対象のメッセージかそれが応答が適切でないことを応答者にとって現れさせる内容への応答を送るのを拒否するかもしれません。 例えば、対象のメッセージが「リスト」の値があるPrecedenceヘッダーフィールド[I4.RFC2076]を含んでいるなら、応答者は、交通がメーリングリストから到着したと推測するかもしれなくて、応答が親書のために意図するだけであるなら、こたえないでしょうに。 同様の理由で、応答者はList-*分野[I5.RFC2369]があるどんな対象のメッセージも無視するかもしれません。 (Precedenceが標準のヘッダーフィールドでなく、その使用と解釈が荒野でばらつきが大きいので、Precedenceの面前でどんな特定の応答者の振舞いもこの仕様で推薦されません。)
3. Format of automatic responses
3. 自動応答の形式
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.
以下のセクションは自動応答のコンテンツの詳細を指定します、応答メッセージのヘッダー、応答の内容、および応答がメール輸送システムに伝えられる封筒を含んでいて。
Moore Standards Track [Page 6] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[6ページ]RFC3834
3.1. Message header
3.1. メッセージヘッダー
The fields in the message header should be set as follows:
メッセージヘッダーの分野は以下の通り設定されるべきです:
3.1.1. From field
3.1.1. 分野から
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分野は複数の目的に役立ちます: それはメッセージ(またはだれの代理にメッセージを送ったかのいくつかの場合、パーティーまたは党で)の作者を特定します、そして、人間からの回答のデフォルトの目的地です。 残念ながら、いくつかのメールシステムがまだ非配送レポートと他の種類の自動応答を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分野の役割はそれほど重要ではありません、人間(または、だれも)が自動応答に答えるのが、多くの場合役に立たないで、また適切でないので。 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.
- Service Respondersによって送られた応答のために、From分野SHOULDはそのサービスの(人間)の維持装置に達するのに使用できるアドレスを含んでいます。 From分野(アドレスに先行する表示名)SHOULDの人間読み込み可能な部分は人間に対するサービスを特定するサービスの名前か記述を含んでいます。
- 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.
- パーソナルRespondersによって送られた応答のために、From分野SHOULDは対象のメッセージ(すなわち、だれの代理に応答を送るかときのユーザ)の受取人の名前と通信員にとって認識可能になる対象のメッセージの受取人によって選ばれたアドレスを含んでいます。 しばしば、これは対象のメッセージをその受取人に送るのに使用されたアドレスになるでしょう同じの。
Moore Standards Track [Page 7] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[7ページ]RFC3834
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.
同じメールボックス(そして、応答者)に複数の郵便の宛先を転送させる受取人の場合では、パーソナルResponderは様々なメッセージヘッダーフィールドで利用可能な情報に基づいて送付者がその受取人のためのいくつかのアドレスのどれを使用しそうだったかを推測するのに発見的教授法を使用して、応答のFrom分野でそのアドレスを使用するかもしれません。 しかしながら、応答者がだれの代理を行動させているかときの受取人が応答のFromヘッダーフィールドに使用されるために明らかに人間読み込み可能な名前とアドレスを指定するのは、可能であるに違いありません。
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ユーザ名またはアカウント名)から引き出されるか、または応答が発生したコンピュータの種名を明らかにするアドレスを明らかにするのは、不適当であるかもしれません。 その上、これらは受取人のために必ず有効な公共のEメールアドレスを作り出すというわけではありません。 この理由で、パーソナルRespondersは、パーソナルResponseのFrom分野が応答者がだれの代理を行動させているかときの受取人によって設定されるのを許容しなければなりません。
- 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.
- Group Respondersに関しては、FromアドレスSHOULDはそのGroup Responderの維持装置に達するのに使用できたEメールアドレスを含んでいます。 Postmasterアドレスの使用はこのために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")
Fromアドレス(アドレスの前の「句」は、[N2.RFC2822]を見て、3.2に.6を区分する)SHOULDの人間読み込み可能な部分はGroup Responderとそれがだれの代理を操作するかに実行された機能のしるしを含んでいます。(例えば、「例のAgencyウイルスフィルタ」)
3.1.2. Reply-To field
3.1.2. 分野に答えてください。
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.
回答が応答者によって予想されるならReply、-、分野、回答がこれが同じくらいのアドレスであっても期待しているアドレスへのセットか別の応答者が応答SHOULDの、そうです。 それの要求が応答者に送るために返答する応答者はメール輪と魔術師の見習いモードを防がなければなりません。 応答の(前項によると)From分野以来、SHOULDが人間のアドレスを含むことに注意してください、Reply、-、応答の分野は、それが中のアドレスと同じくらいがFrom分野であったならそうしない応答者に回答を向けるのに使用されます。
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
議論: これが、それが通常、意志が回答を送る人間の受取人のユーザエージェントであると仮定する、Reply、-、それがまだ可能でなかったなら1982年以来[I6.RFC822]によって推薦されるように記述します(存在しているなら)。
Moore Standards Track [Page 8] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[8ページ]RFC3834
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].
受取人がFromに答えるように、アドレスによって、その人であるならそうするのが役に立つのがわかります。 これは[I6.RFC822]と[N2.RFC2822]におけるこれらの分野の意図している使用と一致しています。
3.1.3. To field
3.1.3. 分野に
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ヘッダーフィールドSHOULDは応答の受取人を示します。 一般に、そこ、SHOULD、単にどんな自動応答の1人の受取人になってください。 これは魔術師の見習いモードとサービス不能攻撃の可能性を最小にします。
3.1.4. Date field
3.1.4. 年月日欄
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.
DateヘッダーフィールドSHOULDは応答が発生した日時を示します。 対象のメッセージの納品日、および応答が送られた時のどんなしるしとしてもこれをみなしてはいけません。
3.1.5. Subject field
3.1.5. 対象の分野
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).
Subject分野SHOULDはメッセージがSubject分野(または、それの部分)のコンテンツが対象のメッセージからいうことになった自動応答であるという簡潔な指示を含んでいます。 接頭語、「自動車:」 そのような指示として使用されるかもしれません。 使用されるなら、これはSHOULDを前に置きます。ASCII SPACEキャラクタ(0×20)によって後をつけられてください。
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:」として すなわち、一般的に使用されて、人間が発生している応答を示すのが時々メールユーザエージェントによって他の言語に翻訳されるか、または別の方法でメッセージが回答であるという指示としてメールユーザエージェントによって解釈されて、そうが(ギリシア)の接頭語である、「自動車:」 また、メッセージが自動応答であるという一般的な指示として翻訳されるか、または使用されるかもしれません。 しかしながら、「自動車:」 指示は単に人間への援助としてメッセージを処理する際に意図します。 SHOULD NOTがそれであると仮定する処理ソフトウェアに存在を郵送する、「自動車:」 Subjectの始めに、分野は自動的にメッセージを提出したという指示です。
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
対象のメッセージのSubject分野が[N3.RFC2047]と[N4.RFC2231]に従ってフォーマットされたコード化された単語を含むかもしれないことに注意してください。そうすれば、そのようなテキストは応答のSubject分野に含まれてもよいです。 そのような分野を含む応答を発生させるのにおいて、そのようなテキストを解読して、再コード化する必要がめったにありません。 単にprependingして、それらが対象のメッセージにあったとき通常、それがそれらをコード化された単語である残すことができるくらいの「自動車:」 「他の指示」 しかしながら、コード化された単語を含む結果として起こるSubject分野でどんな線も長さが76人以上のASCII文字でないことを保証するのがまだ必要です。(これがコード化された書式を示す、キャラクタの数でない
Moore Standards Track [Page 9] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[9ページ]RFC3834
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.
テキストではコード化されます) また、応答者が対象のメッセージのSubjectに先端を切らせるなら、コード化された単語の中央でSubjectテキストに先端を切らせるのを避けるのも必要です。
3.1.6. In-Reply-To and References fields
3.1.6. 中で答える、References分野
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.
そして、Inが答える、Referencesは提供されたコネが応答メッセージのヘッダーであったなら対象のメッセージにMessage-ID分野があったならSHOULDをさばきます、[N2.RFC2822]セクション3.6.4における規則に従って
3.1.7. Auto-Submitted field
3.1.7. 自動Submitted分野
The Auto-Submitted field, with a value of "auto-replied", SHOULD be included in the message header of any automatic response. See section 5.
「自動返答すること」の値、SHOULDがあるAutoによって提出された分野、どんな自動応答のメッセージヘッダーでも含められてください。 セクション5を見てください。
3.1.8. Precedence field
3.1.8. 先行分野
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.
応答は、数種類の応答者からのこの仕様より前に起こる応答に水をさしているために、Precedence分野[I4.RFC2076]を含むかもしれません。 Precedence分野の分野本体は適切であると応答者によって考えられたテキスト「くず」、「リスト」、「大量」、または他のテキストから成るかもしれません。 Precedence分野が標準的でなく、解釈がばらつきが大きいので、Precedenceの使用はこの仕様で明確に推薦されません、そして、この仕様は少しの特定の値もその分野に推薦しません。
3.2. Message content
3.2. メッセージ内容
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.
一般に、メッセージはパーソナルかGroup Responders SHOULDで発信しました。簡潔であり、テキスト/明瞭な形式で。 複合の、または、代替の構造物は複数の言語における応答を伝えるのに使用されるかもしれません、特にそうするのにおいて、複数の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.
応答メッセージSHOULD NOTは対象のメッセージからの重要な内容を含んでいます。 特に、パーソナルとGroup応答SHOULD NOTが対象のメッセージからの非テキスト内容を含んでいる、それら、SHOULD NOTは対象のメッセージからの付属を含んでいます。 これらの状態のどちらも彼ら(例えば、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
対象のメッセージのヘッダーからのSubjectか他の分野からのテキストが応答のボディーに含まれているとき、それらの分野に現れたどんなコード化された単語も解読するのが必要であることに注意してください。
Moore Standards Track [Page 10] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[10ページ]RFC3834
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、および満足している転送コード化をメッセージ本体と、使用に含める前に。 いくつかの場合、対象のメッセージのヘッダーで使用されるcharset(s)からのテキストを字訳するのが必要であるかもしれません、応答のボディーで使用されるcharset(s)に。 (対象のメッセージのヘッダーからのテキストが、決して応答のボディーに現れる必要がないなら、応答者を実行するのははるかに簡単です。)
3.2.1. Use of DSNs and MDNs instead of this specification
3.2.1. この仕様の代わりにDSNsとMDNsの使用
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.
一般に、その応答の目的がメールで発生する応答がリレーする試みの結果、システムを前方に輸送するか、またはメールを配達して、その郵便配達の状態の情報を対象のメッセージの送付者に提供するだけことであるときに、Delivery Status Notifications(DSNs)を使用するのは適切です。 例えば、全体のメッセージがセキュリティ理由のため送られないなら、メール配送過程によって動かされる、配送の前に有害コンテンツをフィルターにかける「ウイルス・スキャナー」は5.7のStatusコードで「失敗されて」.1(認可されなかった配送、メッセージは拒否した)にAction分野セットがあるDSNを返すかもしれないでしょうに。 または、メッセージをリレーするか、またはおそらく有害な内容が取り除かれている状態で送るなら、それは、「リレーされること」に設定された分野をActionとDSNに返すか、または2.6に設定された「渡された」(適宜)Statusと共にコードに.4(損失が実行されている変換)を返すかもしれないでしょうに。 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.
同様に、受取人に代わって配送か受信者のメールボックスへの配送の後に発生して、メッセージの気質を示す応答の目的がことである発生する応答にだけ、Message Disposition Notifications(MDNs)を使用するのは適切です。 MDN仕様[I3.RFC3798]はこのドキュメントよりむしろMDNsの世代と形式を決定します。
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仕様通りに発生するべきです。 このドキュメントに応じて、これらのセットの評価基準の1つに合わない応答は発生するべきです。
3.3. Message envelope
3.3. メッセージ封筒
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
SMTP MAIL FROMアドレス、または返送先が選ばれたコネがそのような方法であったならメッセージ、SHOULDを送るのにメール輪をありそうもなくするほど使用した他の封筒。 そして例えば、輪が両方であるなら現れるかもしれない、送付者。
Moore Standards Track [Page 11] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[11ページ]RFC3834
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.
メッセージの受取人には、それぞれ自動応答者がいます--受取人の応答者は送付者の応答者にメールを送ります。(その応答者は、受取人の応答者にメールを送り返します)。
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アドレスはこのために使用されるかもしれません。 明確に自動応答を送る目的に選ばれていて、自動的にそれに送られたどんなメッセージにも応じない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=パラメタも指定されないのは、RECOMMENDEDです。
4. Where to send automatic responses (and where not to send them)
4. 自動応答をどこに送りますか。(そして、それらをどこに送りませんか)
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.
一般に、自動応答SHOULD、配送の後に発生するなら、Return-経路分野に送ってください。 応答は配送の前に発生します、応答SHOULD。非配送しているレポートのための目的地としてSMTP MAIL FROMコマンド、または封筒返送先へのどの(非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.
応答が配送の後に発生することであり、対象のメッセージにReturn-経路分野が全くなければ、メッセージを送ったか、またはSMTPの外でメッセージをgatewayedしたSMTPサーバーには実現か構成誤りがあります。 Return-経路分野がなくなってもSHOULD NOTがReturn-経路分野のそれを除いたどんなアドレスへの応答も渡すパーソナルかGroup応答者。 郵便配達システムに関する問題を修正するのは応答の適切な目的地を推測するために発見的教授法を当てにするより良いです。 そのような発見的教授法が過去に問題を起こすのが知られています。
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.
Service Responderは要求ペイロードから>From分野からのアドレス(es)、または、別のアドレスへの応答を提供するかもしれません、この振舞いがそのサービスのための仕様に基づき正確に定義されるなら。 SHOULD NOTが使用するサービス応答者、Reply、-、このために、さばきます。
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
SHOULD NOTをさばいてください。Reply、-、目的地として、自動応答には、パーソナルかGroup Respondersから、使用されてください。 一般に、この分野はその人の予期に基づく人間の送付者によって設定されます。
Moore Standards Track [Page 12] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[12ページ]RFC3834
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.
人間の受取人はどうそのメッセージの特定の内容に応じるだろうか。 例えば、人間の送付者が使用するかもしれない、Reply、-、回答が全体のメーリングリストに送られるよう要求するために。 人間からの回答のためにさえ、ケースがそれが応じるのが適切でないところにある、Reply、-、アドレス、特に送付者が、回答がグループ、そして/または、メーリングリストに送られるように頼んだなら。 パーソナルかGroup Responderが人間の受取人を代表して作動するのでそれがいずれでもあると仮定するのが、より安全である、Reply、-、メッセージの現在の分野はどんな回答も送付者と他の受取人の役割の何らかの理解を持っていた人間から来るだろうという前提での人間の送付者によって設定されました。 自動応答者はそれらの役割を理解するのに必要な情報を欠いています。 自動応答を送る、Reply、-、アドレス、その結果、役に立たないか求められていないメッセージを受け取る多くの人々はもたらすことができます。 また、それは、輪を郵送するために貢献できます。
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、- 特に、From分野は複数のアドレスを記載するかもしれませんが、ただ一つのアドレスに自動応答を送るだけであるべきです。 または、そして、一般に、From、Reply、-、異なった事情、およびこの理由パーソナルにさまざまな方法でアドレスを使用できないか、Group Respondersが、それがFromのアドレスであると確かに仮定できない、Reply、-、分野は応答のための適切な目的地です。 FromがSHOULD NOTをさばくこれらの理由で、目的地として、自動応答には、使用されてください。
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はSHOULD NOTをさばきます。目的地として、自動応答には、使用されてください。 この分野は、単にメッセージを送った人か実体を特定することを意図して、回答に、有効なアドレスを含むのに必要ではありません。
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-経路アドレスは本当に外交儀礼の問題として送付者によって予期されなかった自動応答に適していると予想できるメッセージヘッダーからの唯一無二です。
5. The Auto-Submitted header field
5. Autoによって提出されたヘッダーフィールド
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.
Autoによって提出されたヘッダーフィールドの目的はメッセージが自動過程、または人間でというよりむしろ自動応答者によって溯源されたのを示すことです。 そして、どの自動的に発生したメッセージと自動応答のために信号経路からのメッセージの自動フィルタリングを容易にするかは望ましくはありません。
5.1. Syntax
5.1. 構文
The syntax of Auto-Submitted is as follows, using the ABNF notation of [N6.RFC2234]:
[N6.RFC2234]のABNF記法を使用して、Autoによって提出されることの構文は以下の通りです:
Moore Standards Track [Page 13] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[13ページ]RFC3834
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]で定義されます。 「象徴」というシンボル、および「パラメタ」が[N7.RFC2045]で定義されるように([N4.RFC2231]によって修正されるように)あります。
The maximum number of Auto-Submitted fields that may appear in a message header is 1.
メッセージヘッダーに現れるかもしれないAutoによって提出された野原の最大数は1です。
5.2. Semantics
5.2. 意味論
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.)
Autoによって提出されたヘッダーはSHOULD NOTをさばきます。人間によって提出されて、手動でそうであったメッセージに供給してください。 (しかしながら、送付者に任意の分野SHOULD NOTを指定させるユーザエージェントは、人間がAutoによって提出された分野を設定するのを防ぎます、それが時々テストすることの役に立つので。)
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,
- SHOULD、直接的な反応でない自動(しばしば周期的な)である工程(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.
- または、(DSNs)[I2.RFC3464]、Message Disposition Notifications(MDNs)[I3.RFC3798]、またはメッセージの他のレポートとDelivery Status Notificationsをラベルするのに使用されてはいけない、(非、)、領収書、(非、)、配送。 以下に注意してください。 いくつかの広く配備されたSMTP実現が現在、「自動発生している」ラベル非配送レポートを使用します。 これらは代わりに使用に「自動返答していた」状態で変わるべきです。
The auto-replied keyword:
自動返答したキーワード:
- SHOULD be used on messages sent in direct response to another
message by an automatic process,
- SHOULD、直接的な反応で送られたメッセージで自動工程で別のメッセージに使用されてください。
Moore Standards Track [Page 14] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[14ページ]RFC3834
- MUST NOT be used on manually-generated messages,
- 手動で発生しているメッセージで使用されてはいけません。
- MAY be used on Delivery Status Notifications (DSNs) and Message
Disposition Notifications (MDNs),
- Delivery Status Notifications(DSNs)とMessage Disposition Notifications(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.
ありそうもなく見えますが、拡大キーワードは将来、定義されるかもしれません。 IETF Consensusの過程[N8.RFC2434]を使用することでそのようなキーワードの構文と意味論をRFCsとして発表されて、承認しなければなりません。 「x」で始まるキーワードは、実験のために控えられて、同意する中でパーティーを使用します。 5月以外のどんなキーワードがあるAutoによって提出された分野も含むメッセージの受取人は、メッセージが人間によって手動で提出されなかったと仮定します。
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 Consensus工程で定義されるかもしれません。 それらが必要であるなら、今後の定義は任意のパラメタの構文をここに考慮させられます。 この仕様へのAutoによって提出された従うことの実現は、Autoが分野とシンタクス上有効な任意のパラメタを含むキーワードを提出したと必ず認めなければなりませんが、それらが存在しているなら、そのような実現はそれらのパラメタを無視するかもしれません。 「x」で始まるパラメタ名は、実験のために控えられて、同意する中でパーティーを使用します。
The "comment" syntactical construct from [N2.RFC2822] can be used to indicate a reason why this message was automatically submitted.
このメッセージが自動的に提出された理由を示すのに[N2.RFC2822]からの「コメント」構文の構造物を使用できます。
6. Security Considerations
6. セキュリティ問題
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;
- 多くのアドレスにメッセージをリレーするか、または多量の求められていない内容で個々のメールボックスをあふれさせるのに応答者を使用するのによるマウントサービス不能攻撃、または両方へのそのような応答者の使用。
Moore Standards Track [Page 15] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[15ページ]RFC3834
- 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),
- そのパーソナルを推薦して、Group Respondersはどんな1期間あたりの個人にも送られた応答の数を制限します(また、輪によって引き起こされた可能性のあるダメージを制限して)。
- 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).
- 簡潔であり、パーソナルとGroup Respondersからの応答がプレーンテキスト形式(メール応答者が有害コンテンツを伝える、そして/または、有害コンテンツの源を変装するのにメカニズムとして使用される可能性を最小にする)でそうするべきであることを勧めます。
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.
しかしながら、Eメールアドレスが容易に作り出されるので、応答を発行する前にアクセスを制限して、認証を必要としないどんなメール応答者にも、攻撃はまだ可能です。 上の測定は、与えられることができる損害を制限するのを試みますが、それらは攻撃を完全に防ぐことができません。
Moore Standards Track [Page 16] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[16ページ]RFC3834
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.
また、パーソナルとGroup Respondersが時々不適当に受取人の個人情報を明らかにすることに注意されました。 これは「手動で自動的(Group Responderが交互の問い合わせ先として自動的に受取人の個人的であるか移動電話番号を供給する時として)か」起こるかもしれません。 自動的に発生した情報SHOULD NOTは既に容易に利用可能な状態で知られていない受取人に関する個人情報を含んでいます、対象のメッセージの送付者。 受取人が応答テキストSHOULDを供給できるユーザインタフェースは、地元の同僚は入手するだけではなく、全体のインターネットがもこの情報を入手するとユーザに断言します、潜在的攻撃者を含んでいて。
7. Example: vacation program
7. 例: 休暇プログラム
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.
休暇プログラムはパーソナル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,
- Autoによって提出されたヘッダーフィールドを含んでいます。
- 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,
- Toの受取人のアドレスの1つ、CC、Bccを含んでいない、Resent、-、Resent-CC、またはResent-Bcc分野
Moore Standards Track [Page 17] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[17ページ]RFC3834
- contains a Precedence field with a value of "list", "junk", or
"bulk",
- 「リスト」、「くず」、または「大量」の値があるPrecedence分野を含んでいます。
- does not have a Return-Path address, or
- またはReturn-経路アドレスを持っていない。
- has a Return-Path address of <>, or a Return-Path address of a
form that is frequently used by non-delivery reports.
- <>のReturn-経路アドレス、または頻繁に非配送レポートによって使用されるフォームのReturn-経路アドレスを持っています。
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ヘッダーフィールドはだれの代理に応答を送るかに関してユーザによって指定された名前とEメールアドレスに設定されます。 (いくつかのシステムの上では、ユーザのアカウント名に基づいている休暇応答の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.
- Reply、-、分野、だれの代理に応答を送るかに関してユーザによって明らかに構成される場合にだけ、設定されます。 例えば、ユーザは、彼の不在の間、要件を扱うよう代表として派遣された秘書か仕事仲間への回答に指示するかもしれません。
- The To field contains the address of the recipient of the
response, as obtained from the Return-Path field of the subject
message.
- To分野は応答の受取人のアドレスを含んでいます、対象のメッセージのReturn-経路分野から得るように。
- The Date field contains the date and time at which the response
was generated.
- Date分野は応答が発生した日時を含んでいます。
- 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分野はAutoを含んでいます: だれの代理に応答を送るかときのユーザによって選ばれたストリングは支えています。 何か「私のメールから遠くへ」のようなものの既定の設定は適切であるかもしれません。 Subject分野が非ASCII文字を含むなら、これらは[N3.RFC2047]単位でコード化されます。
- The In-Reply-To and References fields are generated from the
subject message per [N2.RFC2822].
- そして、Inが答える、References分野は[N2.RFC2822]あたりの対象のメッセージから発生します。
- The Auto-Submitted field has the value "auto-replied".
- Autoによって提出された分野には、値があります。「自動返答」。
- 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.
- メッセージ本体はだれの代理に応答を送るかに関してユーザによって指定された何らかのテキストを含んでいます。 また、対象のメッセージの簡潔な概要は含まれています、対象のメッセージからのメッセージ・テキストのFrom、To、Subject、Date、およびいくつかの線から成って。 どんな付属も非テキストbodypartsも応答に含まれていません。
Moore Standards Track [Page 18] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[18ページ]RFC3834
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 FROMアドレスは<>です。メッセージ封筒のRCPT TOアドレスは応答が送られるユーザのアドレスです。 また、SMTPサーバーによって受入れられるなら、NOTIFY=はRCPT TO線で決して用意ができていません。
8. IANA Considerations
8. IANA問題
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つの新しい拡大メカニズムを定義します--Autoによって提出されたヘッダーフィールドのための新しいキーワード、およびAutoによって提出された分野のための新しい任意のパラメタ。 新しいキーワードかパラメタが未来の任意な点で承認されているなら(IETF Consensusの過程による)、IANAがそのようなキーワードかパラメタの登録を作成するのは、適切であるかもしれません。
9. Acknowledgments
9. 承認
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は一連のインターネット草稿を「メールのベースのサーバの働き」、そして、特に書きました、「サーバに答えます」の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.
Autoによって提出された分野のための考えはX.400/MHSメールシステム[I7.X420]から来ます。 X.400とインターネット・メールの間でgatewayingするとき、[I8.RFC2156]は使用のために"Autosubmitted"分野を定義しました。 ヤコブ・パルメは、「自動提出された」分野のインターネット・メールの使用を定義しながらインターネット草稿を書きましたが、非かなりの反論を決議する試みで停頓しました。インターネット・メールは、Last Callを通して重要な反論なしでそれを作りました。 Autoによって提出されることの定義はそのドキュメントのものから本書では引き出されます(すなわち、わずかに簡素化されます)、何らかのテキストが完全に盗まれている状態で。
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、エリックHall、トニー・ハンセン、Vivek Khera、ダン・コーン、ブルース・リリー、チャールズ・リンジー、derマウス、リンドン・ネーレンバーグ、リチャードRognlie、マーカス・シュトゥンフ、フローリアンバイマー、およびダンは飛んで行きます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1.RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Moore Standards Track [Page 19] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[19ページ]RFC3834
[N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[N2.RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[N5.RFC3461]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、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"、1997年11月のRFC2234。
[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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
10.2. Informative References
10.2. 有益な参照
[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で一度保守されたJargonファイルからの「魔術師の見習いモード」。 現在、ネットの様々な場所で集まります。 例えば 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.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notifications", RFC 3798, May 2004.
[I3.RFC3798] ハンセンとT.とG.ボードルイ、Eds、「メッセージ気質通知」、RFC3798、5月2004日
[I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997.
[I4.RFC2076] パルメ、J.、「一般的なインターネットメッセージヘッダー」、RFC2076、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.ベヤー、「CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta構文としてのURLのUse」、RFC2369、1998年7月。
Moore Standards Track [Page 20] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[20ページ]RFC3834
[I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[I6.RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、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(1992E)。 情報技術--メッセージHandling Systems(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.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、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のキース・ムーアInnovativeのコンピューティング研究所大学
EMail: moore@cs.utk.edu
メール: moore@cs.utk.edu
Moore Standards Track [Page 21] RFC 3834 Automatic E-Mail Responses August 2004
メール応答2004年8月に自動であるムーア標準化過程[21ページ]RFC3834
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Moore Standards Track [Page 22]
ムーア標準化過程[22ページ]
一覧
スポンサーリンク
