Network Working Group T. Showalter
Request for Comments: 5230
Category: Standards Track N. Freed, Ed.
Sun Microsystems
January 2008
Sieve Email Filtering: Vacation Extension
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops.
この文書では、メッセージに返信するためのUnixの「休暇」コマンドと同様の自動返信機能のためのふるいのメールフィルタリング言語の拡張機能について説明します。様々な安全機能は、メッセージループなどの問題を防止するために含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3
4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 4
4.3. Subject and From Parameters . . . . . . . . . . . . . . . 6
4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Address Parameter and Limiting Replies to Personal
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Restricting Replies to Automated Processes and Mailing
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 8
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Response Message Generation . . . . . . . . . . . . . . . . . 9
5.1. SMTP MAIL FROM Address . . . . . . . . . . . . . . . . . . 9
5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Auto-Submitted . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 10
5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 10
6. Relationship to Recommendations for Automatic Responses to
Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11
7. Internationalization Considerations . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
This document defines an extension to the Sieve language defined in [RFC5228] for notification that messages to a particular recipient will not be answered immediately.
この文書では、特定の受信者へのメッセージがすぐに答えられないであろう通知の[RFC5228]で定義されたSieve言語への拡張を定義します。
Conventions for notations are as in [RFC5228] section 1.1.
表記の規則は、[RFC5228]セクション1.1のようにしています。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED", and "MAY" in this document are to be interpreted as defined in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "SHOULD"、 "SHOULD NOT"、 "REQUIRED"、および本書では[RFC2119]で定義されるように解釈される "場合があります"。
Sieve implementations that implement vacation have an identifier of "vacation" for use with the capability mechanism.
休暇を実装するふるいの実装は、能力メカニズムで使用するための「休暇」の識別子を持っています。
Usage: vacation [":days" number] [":subject" string] [":from" string] [":addresses" string-list] [":mime"] [":handle" string] <reason: string>
使用法：休暇[ "：日" 数] [ "：件名" 文字列] [ "：から" 文字列] [ "：アドレス" 文字列のリスト] [ "：パントマイム"] [ "：ハンドル" の文字列] <理由：文字列>
The "vacation" action implements a vacation autoresponder similar to the vacation command available under many versions of Unix. Its purpose is to provide correspondents with notification that the user is away for an extended period of time and that they should not expect quick responses.
「休暇」のアクションは、Unixの多くのバージョンで利用可能な休暇コマンドに似休暇オートレスポンダーを実装しています。その目的は、ユーザーが長時間離れていると、彼らは迅速な対応を期待すべきではないことをことを通知して特派を提供することです。
"Vacation" is used to respond to a message with another message. Vacation's messages are always addressed to the Return-Path address (that is, the envelope from address) of the message being responded to.
「休暇」は別のメッセージでメッセージに応答するために使用されます。休暇のメッセージは常にに反応されているメッセージの（つまり、エンベロープFromアドレスです）リターンパスアドレスに宛てています。
The ":days" argument is used to specify the period in which addresses are kept and are not responded to, and is always specified in days. The minimum value used for this parameter is normally 1. Sites MAY define a different minimum value as long as the minimum is greater than 0. Sites MAY also define a maximum days value, which MUST be greater than 7, and SHOULD be greater than 30.
「：日」引数はアドレスが保存されているとに反応していない、と常に日に指定されている期間を指定するために使用されます。このパラメータに使用される最小値は、通常1サイトがあれば最小値が0より大きいサイトはまた、7より大きくなければならない最大日数の値を定義することができ、30より大きくなければならないであるように、異なる最小値を定義するかもしれあります。
If ":days" is omitted, the default value is either 7 or the minimum value (as defined above), whichever is greater.
場合「：日」が省略され、デフォルト値が7以上である方最小値（上記で定義した通り）、のいずれかです。
If the parameter given to ":days" is less than the minimum value, then the minimum value is used instead.
与えられたパラメータ場合「：日は」最小値未満である場合、最小値が代わりに使用されます。
If ":days" exceeds the site-defined maximum, the site-defined maximum is used instead.
場合は「：日は、」サイト定義の最大数を超えて、サイト定義の最大値が代わりに使用されます。
"Vacation" keeps track of all the responses it has sent to each address in some period (as specified by the :days optional argument). If vacation has not previously sent the response to this address within the given time period, it sends the "reason" argument to the SMTP MAIL FROM address [RFC2821] of the message that is being responded to. (The SMTP MAIL FROM address should be available in the Return-path: header field if Sieve processing occurs after final delivery.)
「バケーション」（：日オプションの引数で指定されている）、それはいくつかの期間に、各アドレスに送信されたすべての応答を追跡します。休暇は以前に与えられた時間内にこのアドレスに応答を送信していない場合、それはに対応されているメッセージのアドレス[RFC2821] FROM SMTPメールに「理由」引数を送信します。 （アドレスからのSMTPメールはリターンパスで使用可能にすべきである：ヘッダフィールドふるいの処理は、最終送達後発生した場合）。
Tracking is not just per address, but must also take the vacation response itself into account. A script writer might, for example, have a vacation action that will send a general notice only once in any two-week period. However, even if a sender has received this general notice, it may be important to send a specific notice when a message about something timely or something specific has been detected.
追跡はちょうどアドレスごとではなく、も考慮に休暇応答自体を取る必要があります。スクリプトライターは、例えば、任意の2週間の期間中に一度だけ一般的な通知を送付します休暇のアクションを持っているかもしれません。しかし、送信者がこの一般的な通知を受信した場合でも、タイムリーなものや特定の何かについてのメッセージが検出されたときに、特定の通知を送信することが重要です。
A particular vacation response can be identified in one of two ways. The first way is via an explicit :handle argument, which attaches a name to the response. All vacation statements that use the same handle will be considered the same response for tracking purposes.
特定の休暇の応答は、次のいずれかの方法で識別することができます。応答に名前を付けるハンドル引数、：最初の方法は、明示的に介しています。同じハンドルを使用するすべての休暇文は追跡目的のために同じレスポンスとみなされます。
The second way is via a synthesis of the :subject, :from, :mime, and reason vacation command arguments. All vacation actions that do not contain an explicit handle and that use an identical combination of these arguments are considered the same for tracking purposes.
、から：、件名：パントマイム、との理由休暇のコマンド引数第二の方法は、合成を経由しています。明示的なハンドルを含み、それは、これらの引数の同じ組み合わせを使用していないすべての休暇のアクションが追跡目的のために同じと考えられています。
For instance, if coyote@desert.example.org sends mail to roadrunner@acme.example.com twice, once with the subject "Cyrus bug" and once with the subject "come over for dinner", and roadrunner@acme.example.com has the script shown below, coyote@desert.example.org would receive two responses, one with the first message, one with the second.
例えば、coyote@desert.example.orgが対象で1回、2回roadrunner@acme.example.comするメールを送信する場合、「サイラスバグ」と一度件名の「夕食に来」、およびroadrunner@acme.example。 COMは、以下に示すスクリプトを有し、coyote@desert.example.orgは2つの応答、最初のメッセージを有するもの、第二のものを受け取ることになります。
require "vacation";
if header :contains "subject" "cyrus" {
vacation "I'm out -- send mail to cyrus-bugs";
} else {
vacation "I'm out -- call me at +1 304 555 0123";
}
In the above example, coyote@desert.example.org gets the second message despite having gotten the first one because separate vacation responses have been triggered. This behavior is REQUIRED.
上記の例では、coyote@desert.example.orgは別個休暇応答が誘発されているため、最初のものを得たにも関わらず、第2のメッセージを取得します。この動作が必要です。
There is one important exception to this rule, however. If the Sieve variables extension [RFC5229] is used, the arguments MUST NOT have undergone variable expansion prior to their use in response tracking. This is so that examples like the following script will only generate a single response to each incoming message with a different subject line.
この規則には一つの重要な例外は、しかし、があります。ふるい変数拡張[RFC5229]を使用する場合、引数は前応答の追跡におけるそれらの使用変数の展開を行ってはなりません。次のスクリプトのような実施例は、単に異なる件名の各入力メッセージに対して単一の応答を生成するようにするためです。
require ["vacation", "variables"];
if header :matches "subject" "*" {
vacation :subject "Automatic response to: ${1}"
"I'm away -- send mail to foo in my absence";
}
As noted above, the optional ":handle" parameter can be used to tell the Sieve interpreter to treat two vacation actions with different arguments as the same command for purposes of response tracking. The argument to ":handle" is a string that identifies the type of response being sent. For instance, if tweety@cage.example.org sends mail to spike@doghouse.example.com twice, one with the subject "lunch?" and once with the subject "dinner?", and spike@doghouse.example.com has the script shown below, tweety@cage.example.org will only receive a single response. (Which response is sent depends on the order in which the messages are processed.)
上述のように、オプションの「ハンドル」パラメータは、応答の追跡の目的のために同じコマンドとして異なる引数を持つ2つの休暇のアクションを処理するためにふるいインタプリタを伝えるために使用することができます。 「：ハンドル」への引数は、レスポンスの種類を識別する文字列が送信されています。 tweety@cage.example.orgがメールを送信した場合例えば、二回件名の1 spike@doghouse.example.comする「昼食を？」そして一度件名の「夕食？」、およびspike@doghouse.example.com、以下に示すスクリプトを持って、tweety@cage.example.orgは、単一の応答を受信します。 （送信される応答メッセージが処理される順序に依存します。）
require "vacation";
if header :contains "subject" "lunch" {
vacation :handle "ran-away" "I'm out and can't meet for lunch";
} else {
vacation :handle "ran-away" "I'm out";
}
NOTE: One way to implement the necessary mechanism here is to store a hash of either the current handle and the recipient address or, if no handle is provided, a hash of the vacation action parameters specifying the message content and the recipient address. If a script is changed, implementations MAY reset the records of who has been responded to and when they have been responded to.
注：ここでは、必要なメカニズムを実装する1つの方法は、現在のハンドルと受信者のアドレスまたはいずれかのハッシュを格納することで、何のハンドルが提供されていない場合は、メッセージの内容と受信者のアドレスを指定する休暇のアクションパラメータのハッシュ。スクリプトが変更された場合、実装はに応えてきた人と、彼らはに応えてきたときの記録をリセットしてもよいです。
IMPLEMENTATION NOTE: Care must be taken in constructing a hash of vacation action parameters. In particular, since most parameters are optional, it is important not to let the same string used as the value for different parameters produce the same hash value. One possible way to accomplish this is to apply the hash to a series of counted or null terminated strings, one for each possible parameter in particular order.
実装上の注意：介護休暇のアクションパラメータのハッシュを構築する上で注意する必要があります。ほとんどのパラメータはオプションであるため、特に、異なるパラメータが同じハッシュ値を生成するために値として使用したのと同じ文字列をさせないことが重要です。これを達成するための1つの可能な方法は、カウントまたはnull終端文字列、特定の順序でそれぞれの可能なパラメータの1のシリーズにハッシュを適用することです。
Implementations are free to limit the number of remembered responses; however, the limit MUST NOT be less than 1000. When limiting the number of tracked responses, implementations SHOULD discard the oldest ones first.
実装は覚え応答の数を制限するのは自由です。しかし、限界が追跡応答の数を制限する場合、実装が最も古いものを捨てるべきで1000未満であってはなりません。
The ":subject" parameter specifies a subject line to attach to any vacation response that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST generate an appropriate default subject line as specified below if no :subject parameter is specified.
「：件名」パラメータが生成される任意の休暇の応答に接続するために件名を指定します。 UTF-8文字は、文字列引数で使用することができます。実装は、[RFC2047]に文字列を変換する必要がある場合の単語を符号化し、非ASCII文字が存在する場合にのみ。対象パラメータが指定されている：いいえ場合は下に指定されている実装は、適切なデフォルトの件名を発生させなければなりません。
A ":from" parameter may be used to specify an alternate address to use in the From field of vacation messages. The string must specify a valid [RFC2822] mailbox-list. Implementations SHOULD check the syntax and generate an error when a syntactically invalid ":from" parameter is specified. Implementations MAY also impose restrictions on what addresses can specified in a ":from" parameter; it is suggested that values that fail such a validity check simply be ignored rather than cause the vacation action to fail.
A「：から」パラメータは休暇メッセージのFromフィールドで使用するための代替アドレスを指定するために使用することができます。文字列が有効な[RFC2822]メールボックスのリストを指定する必要があります。実装は、構文をチェックして、構文的に無効なときにエラーを生成する必要があります「：から」パラメータが指定されています。また、実装はで指定できるアドレス何の制限課すことがあります。パラメータ「からの」;このような妥当性チェックに失敗した値は単に無視ではなく、休暇のアクションが失敗することができることが示唆されます。
The ":mime" parameter, if supplied, specifies that the reason string is, in fact, a MIME entity as defined in [RFC2045] section 2.4, including both MIME headers and content.
「：MIME」パラメータは、供給された場合、両方のMIMEヘッダとコンテンツを含む[RFC2045]セクション2.4で定義されているような理由文字列は、実際には、MIMEエンティティであることを指定します。
If the optional :mime parameter is not supplied, the reason string is considered a UTF-8 string.
オプションの場合：MIMEパラメータが供給されていない、理由文字列がUTF-8文字列とみなされます。
require "vacation"; vacation :mime text: Content-Type: multipart/alternative; boundary=foo
「休暇」を必要とします。休暇：MIMEのテキスト：コンテンツタイプ：マルチパート/代替;境界= FOO
--foo
--foo
I'm at the beach relaxing. Mmmm, surf...
私はリラックスしたビーチでです。うーん、サーフィン...
--foo Content-Type: text/html; charset=us-ascii
--fooのContent-Type：text / htmlの。文字セット= US-ASCII
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML><HEAD><TITLE>How to relax</TITLE> <BASE HREF="http://home.example.com/pictures/"></HEAD> <BODY><P>I'm at the <A HREF="beach.gif">beach</A> relaxing. Mmmm, <A HREF="ocean.gif">surf</A>... </BODY></HTML>
<！DOCTYPE HTML PUBLIC " - // W3C // DTD HTML 4.0 // EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML> <HEAD> <TITLE>リラックスする方法</ TITLE> <BASE HREF = "http://home.example.com/pictures/"> </ HEAD> <BODY> <P>私は<HREF = "beach.gif" によ>ビーチ</A>リラックス。うーん、<A HREF="ocean.gif">サーフィン</A> ... </ BODY> </ HTML>
--foo-- .
--foo--。
"Vacation" MUST NOT respond to a message unless the recipient user's email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or "Resent-Bcc" line of the original message. An email address is considered to belong to the recipient if it is one of:
受信者のユーザーの電子メールアドレスは、の「へ」、「CC」、「Bccの」、「のResent-へ」、「憤慨し-CC」、または「憤慨し-BCC」の行にある場合を除き、「休暇」のメッセージに応じてはいけません元のメッセージ。それはの一つである場合にはメールアドレスが受信者に属していると考えられています。
1. an email address known by the implementation to be associated with the recipient,
1.実装によって知られているメールアドレスが受信者に関連付けられます、
2. the final envelope recipient address if it's available to the implementation, or
それは実装に利用できる場合、または2.最終エンベロープ受信者アドレス
3. an address specified by the script writer via the ":addresses" argument described in the next paragraph.
3を介して、スクリプトライターで指定されたアドレス「：アドレス」次の段落で説明する引数。
Users can supply additional mail addresses that are theirs with the ":addresses" argument, which takes a string-list listing additional addresses that a user might have. These addresses are considered to belong to the recipient user in addition to the addresses known to the implementation.
「：アドレス」ユーザーが持っているかもしれない追加のアドレスをリスト文字列のリストを取る引数、ユーザーが持つ彼らの追加のメールアドレスを供給することができます。これらのアドレスは、実装に知られているアドレスに加えて、受信者のユーザーに属すると考えられています。
Implementations MAY refuse to send a vacation response to a message that contains any header or content that makes it appear that a response would not be appropriate.
実装は、応答が適切ではないように見えます任意のヘッダやコンテンツを含むメッセージに休暇応答を送信するために拒否することができます。
Implementations MUST have a list of addresses that "vacation" MUST NOT send mail to. However, the contents of this list are implementation defined. The purpose of this list is to stop mail from going to addresses used by system daemons that would not care if the user is actually reading her mail.
実装は、「休暇」は、にメールを送ってはいけませんというアドレスのリストを持たなければなりません。しかし、このリストの内容は、実装定義されています。このリストの目的は、ユーザが実際に自分のメールを読んでいる場合は気にしませんでしシステムデーモンが使用するアドレスに行くからのメールを停止することです。
Implementations are encouraged, however, to include well-known addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other addresses typically used only by automated systems. Additionally, addresses ending in "-request" or beginning in "owner-", i.e., reserved for mailing list software, are also suggested.
実装は、しかし、一般的に自動化されたシステムでのみ使用される「MAILER-DAEMON」、「LISTSERV」、「majordomoの」のようなよく知られたアドレス、および他のアドレスが含まれるように、奨励されています。また、「-request」で終わるか、「所有者 - 」で始まるアドレスには、すなわち、メーリングリストソフトウェアのために予約も提案されています。
Implementors may take guidance from [RFC2142], but should be careful. Some addresses, like "POSTMASTER", are generally actually managed by people, and people do care if the user is going to be unavailable.
実装者は、[RFC2142]からの指導を取るかもしれないが、注意しなければなりません。 「POSTMASTER」のようないくつかのアドレスは、一般的に、実際に人々によって管理され、ユーザーが使用不能になるだろうされている場合、人々は気にしません。
Implementations SHOULD NOT respond to any message that contains a "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List-Unsubscribe", "List-Post", "List-Owner", or "List-Archive" [RFC2369] header field.
実装は、「リスト-ID」[RFC2919]、「リスト・ヘルプ」、「リスト・サブスクライブ」、「リスト・解除」、「リスト・ポスト」、「リスト・所有者を」含む任意のメッセージに応答すべきでない、または「リスト・アーカイブ」[RFC2369]ヘッダーフィールド。
Implementations SHOULD NOT respond to any message that has an "Auto-submitted" header field with a value other than "no". This header field is described in [RFC3834].
実装は、「いいえ」以外の値を持つ「自動提出」ヘッダフィールドを持つ任意のメッセージに応答すべきでありません。このヘッダーフィールドは、[RFC3834]に記載されています。
Vacation does not affect Sieve's implicit keep action.
休暇は、ふるいの暗黙のキープ行動に影響を与えません。
Vacation can only be executed once per script. A script MUST fail with an appropriate error if it attempts to execute two or more vacation actions.
休暇は一度だけ、スクリプトごとに実行することができます。それが二つ以上の休暇のアクションを実行しようとした場合、スクリプトは、適切なエラーで失敗しなければなりません。
Implementations MUST NOT consider vacation used with discard, keep, fileinto, or redirect an error. The vacation action is incompatible with the Sieve reject and refuse actions [REJECT].
実装は、廃棄で使用する休暇を検討しておく、のfileinto、またはエラーをリダイレクトしてはなりません。休暇のアクションは拒否し、[拒否]アクションを拒否ふるいと互換性がありません。
Here is a simple use of vacation.
ここでは休暇の簡単な使用です。
require "vacation";
vacation :days 23 :addresses ["tjs@example.edu",
"ts4z@landru.example.edu"]
"I'm away until October 19.
If it's an emergency, call 911, I guess." ;
By mingling vacation with other rules, users can do something more selective.
他のルールで休暇を混入することにより、ユーザは、より選択的な何かを行うことができます。
require "vacation";
if header :contains "from" "boss@example.edu" {
redirect "pleeb@isp.example.org";
} else {
vacation "Sorry, I'm away, I'll read your
message when I get around to it.";
}
This section details the requirements for the generated response message.
このセクションでは、生成した応答メッセージのための要件を詳しく説明しています。
It is worth noting that the input message and arguments may be in UTF-8, and that implementations MUST deal with UTF-8 input, although implementations MAY transcode to other character sets as regional taste dictates. When :mime is used, the reason argument also contains MIME header information. The headers must conform to MIME conventions; in particular, 8bit text is not allowed. Implementations SHOULD reject vacation :mime actions containing 8bit header material.
実装は、地域の味のおもむくなど他の文字セットにトランスコードするかもしれないがそれは、入力メッセージと引数はUTF-8であってもよいこと、および実装はUTF-8の入力に対処しなければならないことは注目に値します。とき：MIMEが使用されている、その理由の引数はまた、MIMEヘッダ情報が含まれています。ヘッダは、MIMEの規則に準拠する必要があります。具体的には、8ビットのテキストは許可されていません。 8ビットのヘッダ材料を含むMIMEアクション：実装は休暇を拒否すべきです。
The SMTP MAIL FROM address of the message envelope SHOULD be set to <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.
メッセージエンベロープのアドレスからのSMTP MAILは<>に設定する必要があります。 NOTIFY NOTARY SMTP拡張場合=も[RFC3461] SMTPトランザクション中線にRCPTに設定されるべきではない絶対が利用可能です。
The Date field SHOULD be set to the date and time when the vacation response was generated. Note that this may not be the same as the time the message was delivered to the user.
休暇の応答が生成されたとき、日付フィールドは、日付と時刻に設定する必要があります。このメッセージは、ユーザに配信された時間と同じではないかもしれないことに留意されたいです。
Users can specify the Subject of the reply with the ":subject" parameter. If the :subject parameter is not supplied, then the subject is generated as follows: The subject is set to the characters "Auto: " followed by the original subject. An appropriate fixed Subject, such as "Automated reply", SHOULD be used in the event that :subject isn't specified and the original message doesn't contain a Subject field.
「：件名」パラメータユーザーが持つ返信の件名を指定することができます。場合：件名パラメータが供給されず、次のように被写体が生成される：元の被写体が続く：被験者は文字「自動」に設定されています。被写体が指定されていないと、元のメッセージは、件名フィールドが含まれていない。このような「自動返信メール」などの適切な固定された主題は、そのイベントで使用されるべきです。
Unless explicitly overridden with a :from parameter, the From field SHOULD be set to the address of the owner of the Sieve script.
明示的に上書きされない限り：パラメータから、FromフィールドSieveスクリプトの所有者のアドレスに設定する必要があります。
The To field SHOULD be set to the address of the recipient of the response.
フィールドへの応答の受信者のアドレスに設定する必要があります。
An Auto-Submitted field with a value of "auto-replied" SHOULD be included in the message header of any vacation message sent.
送信された休暇メッセージのメッセージヘッダに含まれるべきである「自動返信」の値を有する自動提出フィールド。
The body of the message is taken from the reason string in the vacation command.
メッセージの本文は休暇コマンドに理由文字列から取得されます。
Replies MUST have the In-Reply-To field set to the Message-ID of the original message, and the References field SHOULD be updated with the Message-ID of the original message.
応答は、In-返信は、元のメッセージのメッセージIDに設定フィールドが必要であり、参照フィールドは、元のメッセージのメッセージIDを用いて更新されるべきです。
If the original message lacks a Message-ID, an In-Reply-To need not be generated, and References need not be changed.
元のメッセージは、メッセージIDがない場合、イン返信-ために生成する必要はなく、参照は変更する必要はありません。
Section 3.6.4 of [RFC2822] provides a complete description of how References fields should be generated.
[RFC2822]のセクション3.6.4参照フィールドを生成する方法の完全な説明を提供します。
6. Relationship to Recommendations for Automatic Responses to Electronic Mail
電子メールへの自動応答のための提言6.関係
The vacation extension implements a "Personal Responder" in the terminology defined in [RFC3834]. Care has been taken in this specification to comply with the recommendations of [RFC3834] regarding how personal responders should behave.
休暇の延長は、[RFC3834]で定義された用語では「個人レスポンダ」を実装しています。ケアは、個人的な応答がどのように振る舞うべきかについては、[RFC3834]の勧告に従うために、この仕様で撮影されました。
Internationalization capabilities provided by the base Sieve language are discussed in [RFC5228]. However, the vacation extension is the first Sieve extension to be defined that is capable of creating entirely new messages. This section deals with internationalization issues raised by the use of the vacation extension.
ベースふるい言語によって提供される国際化機能は、[RFC5228]に記載されています。しかし、休暇の延長は、完全に新しいメッセージを作成することが可能であるように定義された最初のふるいの拡張機能です。このセクションでは、休暇の延長の使用が提起した国際化の問題を扱っています。
Vacation messages are normally written using the UTF-8 charset, allowing text to be written in most of the world's languages. Additionally, the :mime parameter allows specification of arbitrary MIME content. In particular, this makes it possible to use multipart/alternative objects to specify vacation responses in multiple languages simultaneously.
バケーションメッセージは、通常のテキストは、世界の言語のほとんどに書き込むことができるように、UTF-8文字セットを使用して書かれています。また、：MIMEパラメータは、任意のMIMEコンテンツを指定できます。特に、これは、それが可能同時に複数の言語での休暇応答を指定するには、マルチパート/代替オブジェクトを使用することができます。
The Sieve language itself allows a vacation response to be selected based on the content of the original message. For example, the Accept-Language or Content-Language header fields [RFC3282] could be checked and used to select appropriate text:
ふるい言語自体は、休暇応答が元のメッセージの内容に基づいて選択されることを可能にします。例えば、受け入れ言語またはContent-Languageヘッダーフィールド[RFC3282]はチェックされ、適切なテキストを選択するために使用することができます。
require "vacation";
if header :contains ["accept-language", "content-language"] "en"
{
vacation "I am away this week.";
} else {
vacation "Estoy ausente esta semana.";
}
Note that this rather simplistic test of the field values fails to take the structure of the fields into account and hence could be fooled by some more complex field values. A more elaborate test could be used to deal with this problem.
フィールド値のこのかなり単純なテストは、アカウントにフィールドの構造を取ることができないので、いくつかのより複雑なフィールド値にだまさすることができることに注意してください。より複雑なテストでは、この問題に対処するために使用することができます。
The approach of explicitly coding language selection criteria in
scripts is preferred because in many cases language selection issues
are conflated with other selection issues. For example, it may be
appropriate to use informal text in one language for vacation
responses sent to a fellow employee while using more formal text in a
different language in a response sent to a total stranger outside the
company: require "vacation";
if address :matches "from" "*@ourdivision.example.com"
{
vacation :subject "Gone fishing"
"Having lots of fun! Back in a day or two!";
} else {
vacation :subject "Je suis parti cette semaine"
"Je lirai votre message quand je retourne.";
}
IMPLEMENTATION NOTE: A graphical Sieve generation interface could in principle be used to hide the complexity of specifying response selection criteria from end users. Figuring out the right set of options to present in a graphical interface is likely a nontrivial proposition, but this is more because of the need to employ a variety of criteria to select different sorts of responses to send to different classes of people than because of the issues involved in selecting a response in an appropriate language.
実装上の注意：グラフィカルふるい世代のインタフェースは、原理的には、エンドユーザーからの応答の選択基準を指定することの複雑さを隠すために使用することができます。グラフィカルなインターフェースで提示する選択肢の右のセットを考え出すことは可能性が自明な命題であるが、これはより多くの理由ためのより人々の異なるクラスに送信する応答の異なる種類を選択するために、さまざまな基準を採用する必要があるのです適切な言語での応答の選択に関連する問題。
It is critical that implementations correctly implement the behavior and restrictions described throughout this document. Replies MUST NOT be sent out in response to messages not sent directly to the user, and replies MUST NOT be sent out more often than the :days argument states unless the script changes.
実装が正しく、この文書全体で説明した動作と制限を実装することが重要です。返信がないユーザーに直接送信されたメッセージに応答して送信されてはならない、との回答は、より頻繁に出て送ってはいけません：スクリプトが変更されない限りdays引数状態。
If mail is forwarded from a site that uses subaddressing, it may be impossible to list all recipient addresses with ":addresses".
「：アドレス」メールがサブアドレスを使用するサイトから転送されている場合は、持つすべての受信者のアドレスをリストすることは不可能かもしれません。
Security issues associated with mail auto-responders are fully discussed in the security considerations section of [RFC3834]. This document is believed not to introduce any additional security considerations in this general area.
メール自動応答に関連付けられているセキュリティ上の問題が完全に[RFC3834]のセキュリティの考慮事項のセクションで説明されています。この文書は、この一般的な領域内の任意の追加のセキュリティ上の考慮事項を導入しないと考えられています。
The following template specifies the IANA registration of the vacation Sieve extension specified in this document:
次のテンプレートは、この文書で指定された休暇ふるい拡張のIANA登録を指定します。
To: iana@iana.org Subject: Registration of new Sieve extension
To：iana@iana.org件名：新しいふるい拡張の登録
Capability name: vacation Description: adds an action for generating an auto-reply saying that the original message will not be read or answered immediately RFC number: RFC 5230
能力名：休暇説明：元のメッセージがすぐにRFCの番号を読み取るか、答えられないであろうことを言って自動返信を生成するためのアクションを追加します。RFC 5230
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
連絡先アドレス：ふるいディスカッションリスト<ietf-mta-filters@imc.org>
This information has been added to the list of Sieve extensions given on http://www.iana.org/assignments/sieve-extensions.
この情報はhttp://www.iana.org/assignments/sieve-extensionsに与えられたふるい拡張子のリストに追加されました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]ムーア、K.、 "電子メールへの自動応答のための提言"、RFC 3834、2004年8月。
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]ギュンター、P.、エド。 。とT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、RFC 5229、2008年1月。
[REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email Filtering: Reject Extension", Work in Progress, October 2007.
、進歩、2007年10月の作品： "拡張を拒否ふるいメールフィルタリング" ストーン、A.は、Elvey、M.、およびA.メルニコフ、[拒否]を。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142]クロッカー、D.、 "COMMON SERVICES FORメールボックス名、役割・機能"、RFC 2142、1997年5月。
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.
[RFC2369]ノイフェルド、G.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[RFC2919] Chandhok、R.とG.ウェンガー、 "リスト-ID：メーリングリストの識別のための構造化フィールドと名前空間"、RFC 2919、2001年3月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282] Alvestrand、H.、 "コンテンツ言語ヘッダ"、RFC 3282、2002年5月。
Appendix A. Acknowledgements
付録A.謝辞
This extension is obviously inspired by Eric Allman's vacation program under Unix. The authors owe a great deal to Carnegie Mellon University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, Jeffrey Hutzelman, Philip Guenther, and many others whose names have been lost during the inexcusably long gestation period of this document.
この拡張は明らかにUnix上でエリック・オールマンの休暇プログラムに触発されています。著者は、カーネギーメロン大学、サイラスDaboo、ローレンス・グリーンフィールド、マイケルHaardt、はKjetil Torgrimオム、ARNT Gulbrandsenの、マーク・マレット、アレクセイ・メルニコフ、ジェフリーHutzelman、フィリップ・ギュンター、および名前inexcusably中に失われた多くの他の人に多くを負っていますこのドキュメントの長い妊娠期間。
Authors' Addresses
著者のアドレス
Tim Showalter
ティム・ショーウォルター監督
EMail: tjs@psaux.com
メールアドレス：tjs@psaux.com
Ned Freed (editor) Sun Microsystems 3401 Centrelake Drive, Suite 410 Ontario, CA 92761-1205 USA
ネッドフリード（編集者）Sun Microsystemsの3401 Centrelakeドライブ、スイート410、オンタリオ、カリフォルニア州92761から1205 USA
Phone: +1 909 457 4293 EMail: ned.freed@mrochek.com
電話：+1 909 457 4293 Eメール：ned.freed@mrochek.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。