[要約] RFC 5230は、Sieveメールフィルタリングの拡張機能である「Vacation Extension」に関するものです。このRFCの目的は、ユーザーが休暇中に自動的に応答メッセージを送信できるようにするための仕様を提供することです。
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]で定義されているふるい言語の拡張機能を定義します。
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].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「必要はない」、「必須」、「必要」、「必要」は、[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.
「休暇」は、別のメッセージでメッセージに応答するために使用されます。バケーションのメッセージは、応答されているメッセージの返信パスアドレス（つまり、アドレスからの封筒）に常に宛てられます。
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を超える限り、異なる最小値を定義できます。。
If ":days" is omitted, the default value is either 7 or the minimum value (as defined above), whichever is greater.
"：days"が省略されている場合、デフォルト値は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.
"：days"がサイト定義の最大値を超える場合、代わりにサイト定義の最大値が使用されます。
"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]からSMTPメールに「理由」の引数を送信します。（アドレスからのSMTPメールは、最終配信後にふるい処理が発生した場合、RETURN-PATH：HEADERフィールドで利用できるようにする必要があります。）
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週間の期間で1回だけ一般的な通知を送信する休暇アクションを持つ場合があります。ただし、送信者がこの一般的な通知を受け取ったとしても、タイムリーまたは特定の何かに関するメッセージが検出された場合、特定の通知を送信することが重要かもしれません。
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.
特定の休暇の対応は、2つの方法のいずれかで特定できます。最初の方法は、明示的な：ハンドル引数を介してです。これは、応答に名前を添付します。同じハンドルを使用するすべての休暇声明は、追跡目的で同じ応答と見なされます。
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.
2番目の方法は、次の統合を介してです。明示的なハンドルを含まず、これらの引数の同一の組み合わせを使用するすべての休暇アクションは、追跡目的で同じと見なされます。
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がroadrunner@acme.example.comにメールを2回送信し、1回「Cyrus Bug」と1回「夕食のためにやって来ます」、およびroadrunner@acme.exampleを送信します。comには以下に示されているスクリプトがあり、coyote@desert.example.orgは2つの応答を受け取ります。1つは最初のメッセージと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.
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.
ただし、このルールには1つの重要な例外があります。Sieve変数拡張[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つの休暇アクションを異なる引数で同じコマンドとして扱うように指示することができます。「：handle」への引数は、送信される応答のタイプを識別する文字列です。たとえば、tweety@cage.example.orgがspike@doghouse.example.comにメールを2回送信します。そして、件名「夕食？」と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つの可能な方法は、ハッシュをカウントされた一連のまたはヌル終端文字列に適用することです。
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]エンコードされた単語に変換する必要があります。実装は、NO：件名パラメーターが指定されている場合、以下に指定されている適切なデフォルトの主題行を生成する必要があります。
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"パラメーターを使用して、From From Vacation Messageで使用する代替アドレスを指定できます。文字列は、有効な[RFC2822]メールボックスリストを指定する必要があります。実装は、構文をチェックし、構文的に無効な場合にエラーを生成する必要があります。また、実装は、「：from」パラメーターで指定できるアドレスに制限を課す場合があります。このような妥当性チェックを失敗させる値は、休暇アクションを失敗させるのではなく、単に無視されることが示唆されています。
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
--foo
- フー
I'm at the beach relaxing. Mmmm, surf...
私はビーチにリラックスしています。うーん、サーフ...
--foo
Content-Type: text/html; charset=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>
--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」、 "resent-cc"、または「resent-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]からガイダンスを取得する場合がありますが、注意する必要があります。「ポストマスター」のような一部のアドレスは、一般に実際に人によって管理されており、ユーザーが利用できないかどうかは気にします。
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.
実装は、「list-id」[rfc2919]、 "list-help"、 "list-subscribe"、 "list-unsubscribe"、 "list-post"、 "list-owner"を含むメッセージに応答しないでください。「リストアーチブ」[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].
実装は、「no」以外の値を持つ「自動サビングされた」ヘッダーフィールドを持つメッセージに応答してはなりません。このヘッダーフィールドは[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.
休暇はスクリプトごとに1回しか実行できません。2つ以上の休暇アクションを実行しようとする場合、スクリプトは適切なエラーで失敗する必要があります。
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." ;
「休暇」が必要です。休暇：23日目：住所["tjs@example.edu"、 "ts4z@landru.example.edu"]「10月19日まで離れています。緊急事態の場合は、911に電話してください。」;
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メールは、<>に設定する必要があります。Notify = noter 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.
ユーザーは、「：件名」パラメーターで返信の件名を指定できます。：サブジェクトパラメーターが提供されない場合、被験者は次のように生成されます。被験者は、文字「auto：」に設定されます。「自動応答」などの適切な固定サブジェクトは、次の場合に使用される必要があります。主題が指定されておらず、元のメッセージにはサブジェクトフィールドが含まれていません。
Unless explicitly overridden with a :from parameter, the From field SHOULD be set to the address of the owner of the Sieve script.
a：from parameterで明示的に上書きされない限り、Fromフィールドは、シーブスクリプトの所有者のアドレスに設定する必要があります。
The To field SHOULD be set to the address of the recipient of the response.
TOフィールドは、応答の受信者のアドレスに設定する必要があります。
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.
返信は、元のメッセージのメッセージ-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は、参照フィールドの生成方法の完全な説明を提供します。
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コンテンツの仕様を許可します。特に、これにより、MultiPart/代替オブジェクトを使用して、複数の言語での休暇対応を同時に指定することができます。
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:
シーブ言語自体は、元のメッセージの内容に基づいて休暇の応答を選択できます。たとえば、Accept-LanguageまたはContent-Language Headerフィールド[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.
このドキュメント全体で説明されている動作と制限を実装を正しく実装することが重要です。返信はユーザーに直接送信されないメッセージに応じて送信してはなりません。また、返信は、スクリプトが変更されない限り、次の頻繁に送信されてはなりません。
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
宛先：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
Contact address: The Sieve discussion list <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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、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] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、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] Guenther、P.、ed。and T. Showalter、ed。、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[RFC5229] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、2008年1月。
[REJECT] Stone, A., Elvey, M., and A. Melnikov, "Sieve Email Filtering: Reject Extension", Work in Progress, October 2007.
[Reject] Stone、A.、Elvey、M。、およびA. Melnikov、「Sieve Emailフィルタリング：拒否拡張」、2007年10月の作業進行中。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142] Crocker、D。、「一般的なサービス、役割、機能のメールボックス名」、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] Neufeld、G。およびJ. Baer、「コアメールリストのコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、1998年7月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、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. Wenger、「List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間」、RFC 2919、2001年3月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282] Alvestrand、H。、「コンテンツ言語ヘッダー」、RFC 3282、2002年5月。
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の下でのエリック・オールマンの休暇プログラムに触発されています。著者は、カーネギー・メロン大学、サイラス・ダブー、ローレンス・グリーンフィールド、マイケル・ハード、マイケティ・ハード、キェティル・トーグリム・ホム、アレント・ガルブランドセン、マーク・マレット、メルニコフ、ジェフリー・フッツェルマン、フィリップ・ゲンテル、そしてアレクセイ・メルニコフ、アレクセイ・メルニコフ、その他多くの名前が、おそらく失われた他の多くの人には、おそらく失われました。この文書の長い妊娠期間。
Authors' Addresses
著者のアドレス
Tim Showalter
ティム・ショーラーター
EMail: tjs@psaux.com
Ned Freed (editor) Sun Microsystems 3401 Centrelake Drive, Suite 410 Ontario, CA 92761-1205 USA
Ned Freed（編集者）Sun Microsystems 3401 Centrelake Drive、Suite 410 Ontario、CA 92761-1205 USA
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。