RFC5230 日本語訳

Network Working Group                                       T. Showalter
Request for Comments: 5230
Category: Standards Track                                  N. Freed, Ed.
                                                        Sun Microsystems
                                                            January 2008

コメントを求めるワーキンググループT.ショウォーター要求をネットワークでつないでください: 5230年のカテゴリ: 規格は2008年1月にエド解放されたN.、サン・マイクロシステムズを追跡します。

               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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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「休暇」コマンドのものと同様のautoresponderのために言語をフィルターにかけるSieveメールに拡大について説明します。 様々な安全機能は、メッセージ輪などの問題を防ぐために含まれています。

Showalter & Freed           Standards Track                     [Page 1]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[1ページ]: 拡大2008年1月休暇

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンションは本書では.3 3を使用しました。 能力識別子. . . . . . . . . . . . . . . . . . . . 3 4。 休暇動作. . . . . . . . . . . . . . . . . . . . . . . 3 4.1。 何日ものパラメタ. . . . . . . . . . . . . . . . . . . . . . 3 4.2 前の応答追跡. . . . . . . . . . . . . . . . 4 4.3。 受けることがある、パラメタ. . . . . . . . . . . . . . . 6 4.4 パラメタ. . . . . . . . . . . . . . . . . . . . . . 6 4.5をまねてください。 パラメタを記述してください。そうすれば、制限は親書. . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6に答えます。 制限は自動化された過程とメーリングリスト. . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.7に答えます。 他のふるいの動作. . . . . . . . . . . 8 4.8との相互作用。 例. . . . . . . . . . . . . . . . . . . . . . . . . 9 5。 応答メッセージ世代. . . . . . . . . . . . . . . . . 9 5.1。 アドレス. . . . . . . . . . . . . . . . . . 9 5.2からのSMTPメール。 .95.3の日付を入れてください。 .105.4人をかけてください。 .105.5から。 .105.6に。 自動提出される、.105.7 メッセージ本体. . . . . . . . . . . . . . . . . . . . . . . 10 5.8。 に対して参照. . . . . . . . . . . . . . . . 10 6 電子メール. . . . . . . . . . . . . . . . . . . . . . . 11 7への自動応答のための推薦との関係。 国際化問題. . . . . . . . . . . . . 11 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 12 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 13付録A.承認. . . . . . . . . . . . . . . . . . 15

Showalter & Freed           Standards Track                     [Page 2]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[2ページ]: 拡大2008年1月休暇

1.  Introduction

1. 序論

   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言語と拡大を定義します。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   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"、「必須NOT」“SHOULD"、「」、「必要であった」、およびこのドキュメントの「5月」は[RFC2119]で定義されるように解釈されることになっているべきです。

3.  Capability Identifier

3. 能力識別子

   Sieve implementations that implement vacation have an identifier of
   "vacation" for use with the capability mechanism.

休暇を実行するふるいの実現が能力メカニズムによる使用のための「休暇」に関する識別子を持っています。

4.  Vacation Action

4. 休暇動作

   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の多くのバージョンの下で利用可能な休暇命令と同様の休暇autoresponderを実行します。 目的はユーザが時間の長期間の間遠くにいて、彼らが素早い反応を予想するべきでないという通知を通信員に提供することです。

   "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.

「休暇」は、別のメッセージでメッセージに応じるのに使用されます。 休暇のメッセージはいつも応じるメッセージのReturn-経路アドレス(すなわち、アドレスからの封筒)に記述されます。

4.1.  Days Parameter

4.1. 何日ものパラメタ

   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、およびSHOULDより30よりすばらしい状態で大きいに違いありません)。

   If ":days" is omitted, the default value is either 7 or the minimum
   value (as defined above), whichever is greater.

「」 : 何日であるのも」、省略されていて、どれがさらに大きいかなら、デフォルト値は、7か最小値(上で定義されるように)のどちらかです。

Showalter & Freed           Standards Track                     [Page 3]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[3ページ]: 拡大2008年1月休暇

   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.

「」 : 何日であるのも」。代わりにサイトで定義された最大、使用されるサイトで定義された最大を超えています。

4.2.  Previous Response Tracking

4.2. 前の応答追跡

   "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.)

「休暇」はそれがいつかの時代に各アドレスに送ったすべての応答の動向をおさえます(:daysの任意の議論で指定されるように)。 休暇が定められた時間内に期間に以前にこのアドレスに応答を送らないなら、それはそれが反応しているメッセージのSMTP MAIL FROMアドレス[RFC2821]に「理由」議論を送ります。 (Sieve処理が最終的な配送の後に起こるなら、SMTP MAIL FROMアドレスはReturn-経路: ヘッダーフィールドで利用可能であるべきです。)

   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.

2つの方法の1つで特定の休暇応答を特定できます。 最初の道は名前を応答に付ける明白な:handle議論です。 同じハンドルを使用するすべての休暇声明が追跡目的のための同じ応答であると考えられるでしょう。

   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番目の道は:subject、:from、:mime、および理由休暇コマンド議論の統合です。 明白なハンドルを含まないで、これらの議論の同じ組み合わせを使用するすべての休暇動作が追跡目的のために同じように考えられます。

   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 に送り、対象の「サイラスバグ」による一度、対象による、「夕食には、来てください」、 roadrunner@acme.example.com に以下に示されたスクリプトがあると、 coyote@desert.example.org は2つの応答を受けるでしょう、最初のメッセージがある1、2番目がある1。

   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";
   }

「休暇」を必要としてください。 休暇になってください。ヘッダー:contains「対象」"cyrus"である、「私は出かけています--cyrus-バグにメールを送ってください」;、ほか休暇になってください。「私は出かけています--+1 304 555における私を0123と呼んでください」。

Showalter & Freed           Standards Track                     [Page 4]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[4ページ]: 拡大2008年1月休暇

   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番目のメッセージを得ます。 この振舞いは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";
   }

[「休暇」、「変数」]を必要としてください。 ヘッダー:matches「対象」「*」です。休暇:subject、「: 」 1ドルの「私は遠くにいます--私の留守中にメールをfooに送ってください」への自動応答。

   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つの休暇動作を扱うようにSieveインタプリタに言います。 「」 : ハンドルへの議論」は送られる応答のタイプを特定するストリングです。 例えば、 tweety@cage.example.org は二度メールを spike@doghouse.example.com に送ります、対象の「昼食?」がある1、対象による一度、「夕食?」、 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";
   }

「休暇」を必要としてください。 休暇:handleは「逃走しました」。ヘッダー:contains「対象」「昼食」である、「私は、出かけて、昼食のために会うことができない」;、ほか休暇:handleは「逃走しました」。「私は出かけています」。

   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

実現注意: 休暇動作パラメタの細切れ肉料理を組み立てながら、注意を中に入れなければなりません。 ほとんどのパラメタが任意であるので、異なったパラメタのための値として中古の同じストリングに同じハッシュ値を生産させないのは、特に、重要です。 1つ

Showalter & Freed           Standards Track                     [Page 5]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[5ページ]: 拡大2008年1月休暇

   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未満であるはずがありません。 追跡応答の数を制限するとき、実現SHOULDは最初に、最も古い方を捨てます。

4.3.  Subject and From Parameters

4.3. 受けることがある、パラメタ

   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文字が出席している場合にだけ。 :subjectパラメタが全く指定されないなら、実現は以下で指定されるとして適切なデフォルト件名を発生させなければなりません。

   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]メールボックスリストを指定しなければなりません。 「実現SHOULDが構文をチェックして、aであるときにシンタクス上エラーを起こす、無効である、」 : 」 パラメタから、指定されます。 「また、実現は缶がaでどんなアドレスを指定したかに関する制限を課すかもしれない」: 」 パラメタからの 単にそのようなバリディティチェックに失敗する値が休暇動作が失敗することを引き起こすよりむしろ無視されることが提案されます。

4.4.  MIME Parameter

4.4. MIMEパラメタ

   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.

「」 : 」 パラメタをまねてください、供給するなら、事実上、理由ストリングが[RFC2045]セクション2.4で定義されるようにMIME実体であると指定して、MIMEヘッダーと内容の両方を含んでいて。

   If the optional :mime parameter is not supplied, the reason string is
   considered a UTF-8 string.

任意の:mimeパラメタが提供されないなら、理由ストリングはUTF-8ストリングであると考えられます。

Showalter & Freed           Standards Track                     [Page 6]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[6ページ]: 拡大2008年1月休暇

   require "vacation";
   vacation :mime text:
   Content-Type: multipart/alternative; boundary=foo

「休暇」を必要としてください。 休暇:mimeテキスト: コンテントタイプ: 複合/代替手段。 境界=foo

   --foo

--foo

   I'm at the beach relaxing.  Mmmm, surf...

ビーチリラックスには私がいます。 Mmmm、サーフィンしてください…

   --foo
   Content-Type: text/html; charset=us-ascii

--fooコンテントタイプ: テキスト/html。 charsetが私たちと等しい、-、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 HTML4.0//アン」、「 http://www.w3.org/TR/REC-html40/strict.dtd 、「><HTML><ヘッド><がリラックスするために、</タイトル><がHREF=を基礎づける>を題をつける、「 http://home.example.com/pictures/ 、「></ヘッド><ボディー><P>Iが<A HREF=にある、「「>ビーチ</A>リラックスbeach.gif」。 Mmmmに、<A HREFが等しい、「ocean.gif「>サーフ</A>…」 </ボディー></HTML>。

   --foo--
   .

--foo--

4.5.  Address Parameter and Limiting Replies to Personal Messages

4.5. アドレスパラメタと回答を親書に制限すること。

   "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:

受取人ユーザのEメールアドレスが“To"、「cc」、"Bcc"にない場合「休暇」がメッセージに応じてはいけない、「憤慨、-、」、「ccに憤慨する、」、「Bccに憤慨する、」 オリジナルのメッセージの線。 それが1であるなら以下についてEメールアドレスが受取人に属すと考えられます。

   1.  an email address known by the implementation to be associated
       with the recipient,

1. 受取人に関連しているのが実現で知られているEメールアドレス

   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.

「ユーザが彼等のものである追加郵便の宛先に供給できる、」 : 」 議論を記述します。(それは、ユーザが持っているかもしれない追加アドレスを記載しながら、ストリングリストを取ります)。 これらのアドレスが実現に知られているアドレスに加えて受取人ユーザに属すと考えられます。

Showalter & Freed           Standards Track                     [Page 7]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[7ページ]: 拡大2008年1月休暇

4.6.  Restricting Replies to Automated Processes and Mailing Lists

4.6. 回答を自動化された過程とメーリングリストに制限します。

   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.

しかしながら、また、自動化されたシステムすなわち、終わるアドレスが「所有者」でさらに、予約されていた状態で「要求する」か、または始まるというメーリングリストソフトウェアだけによって通常使用される「メーラ・デーモン」、「リストサーブ」、「家令」、および他のアドレスが示されるように実現が周知のアドレスを含んでいるよう奨励されます。

   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.

「リストで申し込んでください」というSHOULD NOTが「リストイド」[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].

実現SHOULD NOTは「いいえ」を除いた値がある「自動提出された」ヘッダーフィールドを持っているどんなメッセージにも応じます。 このヘッダーフィールドは[RFC3834]で説明されます。

4.7.  Interaction with Other Sieve Actions

4.7. 他のふるいの動作との相互作用

   Vacation does not affect Sieve's implicit keep action.

休暇はSieveの暗黙の生活費動作に影響しません。

   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に保ってはいけませんし、また誤りを向け直してはいけません。 休暇動作はSieve廃棄物と廃物動作[REJECT]と両立しないです。

Showalter & Freed           Standards Track                     [Page 8]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[8ページ]: 拡大2008年1月休暇

4.8.  Examples

4.8. 例

   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." ;

「休暇」を必要としてください。 休暇:days23:addresses、[" 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.";
   }

「休暇」を必要としてください。 ヘッダー:contains“from"" boss@example.edu "である、再直接の" pleeb@isp.example.org ";、ほか休暇になってください。「すみません、遠くにいる、私はそれのひまができるあなたのメッセージを読むつもりです」。

5.  Response Message Generation

5. 応答メッセージ世代

   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にあるかもしれなくて、実現が地方としての他の文字の組への実現5月の「移-コード」が命令を味わいますが、入力されたUTF-8に対処しなければならないことに注意する価値があります。 また、:mimeが使用されているとき、理由議論はMIMEヘッダー情報を含んでいます。 ヘッダーはMIMEコンベンションに従わなければなりません。 特に、8ビットのテキストは許容されていません。 実現SHOULDは8ビットのヘッダーの材料を含む休暇:mime動作を拒絶します。

5.1.  SMTP MAIL FROM Address

5.1. アドレスからのSMTPメール

   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 FROMが記述する、NOTIFYがNEVER SHOULDとも等しいというメッセージ封筒SHOULDでは、NOTARY SMTP拡張子[RFC3461]が利用可能であるなら、SMTP取引の間、RCPT TO線で設定されてください。

5.2.  Date

5.2. 日付

   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.

休暇応答がそうであった日時までのセットが発生していたなら、DateはSHOULDをさばきます。 これがメッセージがユーザに送られた時と同じでないかもしれないことに注意してください。

Showalter & Freed           Standards Track                     [Page 9]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[9ページ]: 拡大2008年1月休暇

5.3.  Subject

5.3. 対象

   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.

「ユーザが回答のSubjectを指定できる、」 : 対象、」 パラメタ。 :subjectパラメタが提供されないなら、対象は以下の通り発生します: 対象がキャラクタに設定される、「自動車:」 「オリジナルの対象で、支えられています」。 固定Subjectを当ててください、「自動化された回答」などのように、SHOULD。:subjectが指定されないで、またオリジナルのメッセージがSubject分野を含まない場合、使用されてください。

5.4.  From

5.4. from

   Unless explicitly overridden with a :from parameter, the From field
   SHOULD be set to the address of the owner of the Sieve script.

:fromパラメタで明らかにくつがえされない場合、FromはSHOULDをさばきます。Sieveスクリプトの所有者のアドレスに、用意ができています。

5.5.  To

5.5. to

   The To field SHOULD be set to the address of the recipient of the
   response.

ToはSHOULDをさばきます。応答の受取人のアドレスに、用意ができています。

5.6.  Auto-Submitted

5.6. 自動提出しています。

   An Auto-Submitted field with a value of "auto-replied" SHOULD be
   included in the message header of any vacation message sent.

「自動返答した」SHOULDの値がどんな自動返信用メッセージのメッセージヘッダーにも含まれているAutoによって提出された野原は発信しました。

5.7.  Message Body

5.7. メッセージ本体

   The body of the message is taken from the reason string in the
   vacation command.

理由ストリングから休暇命令でメッセージ欄を取ります。

5.8.  In-Reply-To and References

5.8. に対して参照

   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.

分野はオリジナルのメッセージ、およびReferences分野SHOULDのMessage-IDにセットしました。回答が持たなければならない、Inが答える、オリジナルのメッセージのMessage-IDと共にアップデートしてください。

   If the original message lacks a Message-ID, an In-Reply-To need not
   be generated, and References need not be changed.

オリジナルのメッセージがMessage-IDを欠いているならInが答える、発生しないでください。そうすれば、Referencesを変える必要はありません。

   Section 3.6.4 of [RFC2822] provides a complete description of how
   References fields should be generated.

.4セクション3.6[RFC2822]がReferences分野がどう発生するべきであるかに関する完全な記述を提供します。

Showalter & Freed           Standards Track                    [Page 10]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[10ページ]: 拡大2008年1月休暇

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]。

7.  Internationalization Considerations

7. 国際化問題

   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]でベースSieve言語で提供された国際化能力について議論します。 しかしながら、休暇延期は完全に新しいメッセージを作成できる定義されるべき最初のSieve拡張子です。 このセクションは休暇拡張子の使用で提起された国際化問題に対処します。

   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 charsetを使用することで書かれています。 さらに、: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:

Sieve言語自体は、休暇応答がオリジナルのメッセージの内容に基づいて選択されるのを許容します。 例えば、適切なテキストを選択するのに、Accept-言語かContent-言語ヘッダーフィールド[RFC3282]をチェックして、使用できました:

   require "vacation";
   if header :contains ["accept-language", "content-language"] "en"
   {
       vacation "I am away this week.";
   } else {
       vacation "Estoy ausente esta semana.";
   }

「休暇」を必要としてください。 ヘッダー:containsである、[「言語を受け入れる、」、「満足している言語」] 「アン」、「私は今週、遠くにいる」休暇、ほか休暇"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:

言語選択問題が多くの場合他の選択問題で融合されるので、スクリプトで明らかに言語選択評価基準をコード化するアプローチは好まれます。 例えば、より正式なテキストを使用している間に仲間の従業員に送られた休暇応答に社外の赤の他人に送られた応答に1つの言語で非公式のテキストを異なった言語に使用するのは適切であるかもしれません:

Showalter & Freed           Standards Track                    [Page 11]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[11ページ]: 拡大2008年1月休暇

   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.";
   }

「休暇」を必要としてください。 :matches“from"" *@ourdivision.example.com "を記述してくださいなら{ 「多く楽し休暇:subject「漁に行き」き!」 「1日か2日の後部!」。 } ほか休暇:subject"Je suis parti cette semaine"「Je lirai votreメッセージ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.

実現注意: エンドユーザから応答選択評価基準を指定する複雑さを隠すのに原則としてグラフィカルなSieve世代インタフェースを使用できました。 グラフィカルインタフェースで提示するオプションの右のセットを理解するのは適切な言語で応答を選択するのにかかわる問題より異なった種類の応答が異なったクラスの人々に送るのを選択するさまざまな評価基準を使う必要性のためにしかし、重要な提案、これがそうである傾向があります。

8.  Security Considerations

8. セキュリティ問題

   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]のセキュリティ問題部でメール自動応答機に関連している安全保障問題について完全に議論します。 このドキュメントがこの一般的な領域でどんな追加担保問題も紹介しないと信じられています。

9.  IANA Considerations

9. IANA問題

   The following template specifies the IANA registration of the
   vacation Sieve extension specified in this document:

以下のテンプレートは本書では指定された休暇Sieve拡張子のIANA登録を指定します:

   To: iana@iana.org
   Subject: Registration of new Sieve extension

To: iana@iana.org Subject: 新しいSieve拡張子の登録

   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に数に答えたと言う自動返答を発生させるための動作を加えます: RFC5230

Showalter & Freed           Standards Track                    [Page 12]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[12ページ]: 拡大2008年1月休暇

   Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>

アドレスに連絡してください: Sieve議論 list <ietf-mta-filters@imc.org 、gt。

   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 で与えられたSieve拡張子のリストにこの情報を追加してあります。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

[RFC3461]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。

   [RFC3834]  Moore, K., "Recommendations for Automatic Responses to
              Electronic Mail", RFC 3834, August 2004.

[RFC3834] ムーア、K.、「電子メールへの自動応答のための推薦」、RFC3834、2004年8月。

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, January 2008.

エド[RFC5228]グンサー、P.、T.ショウォーター、エド、「ふるい:」 「言語をフィルターにかけるメール」、RFC5228、2008年1月。

   [RFC5229]  Homme, K., "Sieve Email Filtering: Variables Extension",
              RFC 5229, January 2008.

[RFC5229] オム、K.、「以下をフィルターにかけるふるいのメール」 「変数拡大」、RFC5229、2008年1月。

10.2.  Informative References

10.2. 有益な参照

   [REJECT]   Stone, A., Elvey, M., and A. Melnikov, "Sieve Email
              Filtering: Reject Extension", Work in Progress,
              October 2007.

[拒絶します] ストーン、A.、エルビ、M.、およびA.メリニコフ、「以下をフィルターにかけるふるいのメール」 「廃棄物拡大」、処理中の作業、2007年10月。

   [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
              FUNCTIONS", RFC 2142, May 1997.

[RFC2142]クロッカー(D.、「共益サービス、役割、および機能のためのメールボックス名」、RFC2142)は1997がそうするかもしれません。

   [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.ベヤー、「CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta-構文としてのURLのUse」、RFC2369、1998年7月。

Showalter & Freed           Standards Track                    [Page 13]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[13ページ]: 拡大2008年1月休暇

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、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.ウェンガー、「リストイド:」 「メーリングリストの識別のための構造化された分野と名前空間」(RFC2919)は2001を行進させます。

   [RFC3282]  Alvestrand, H., "Content Language Headers", RFC 3282,
              May 2002.

[RFC3282]Alvestrand(H.、「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。

Showalter & Freed           Standards Track                    [Page 14]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[14ページ]: 拡大2008年1月休暇

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 Homme、Arnt Gulbrandsen、マーク・マレット、Alexeyメリニコフ、ジェフリーHutzelman、フィリップ・グンサー、および多くの他のものから多くを借りています。

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

ネッドは(エディタ)サン・マイクロシステムズ3401Centrelakeドライブ、Suite410オンタリオ、カリフォルニア92761-1205米国を解放しました。

   Phone: +1 909 457 4293
   EMail: ned.freed@mrochek.com

以下に電話をしてください。 +1 4293年の909 457メール: ned.freed@mrochek.com

Showalter & Freed           Standards Track                    [Page 15]

RFC 5230               Sieve: Vacation Extension            January 2008

ショウォーターと解放された規格はRFC5230ふるいを追跡します[15ページ]: 拡大2008年1月休暇

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントは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, 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はどんな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に情報を記述してください。

Showalter & Freed           Standards Track                    [Page 16]

ショウォーターと解放された標準化過程[16ページ]