RFC5232 日本語訳

5232 Sieve Email Filtering: Imap4flags Extension. A. Melnikov. January 2008. (Format: TXT=21964 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                       A.  Melnikov
Request for Comments: 5232                                 Isode Limited
Category: Standards Track                                   January 2008

コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 5232年のIsode株式会社カテゴリ: 標準化過程2008年1月

              Sieve Email Filtering: Imap4flags Extension

ふるいのメールフィルタリング: Imap4flags拡張子

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

要約

   Recent discussions have shown that it is desirable to set different
   IMAP (RFC 3501) flags on message delivery.  This can be done, for
   example, by a Sieve interpreter that works as a part of a Mail
   Delivery Agent.

最近の議論は、異なったIMAP(RFC3501)旗をメッセージ配送に設定するのが望ましいのを示しました。 例えば、メールDeliveryエージェントの一部として働いているSieveインタプリタはこれができます。

   This document describes an extension to the Sieve mail filtering
   language for setting IMAP flags.  The extension allows setting of
   both IMAP system flags and IMAP keywords.

このドキュメントはIMAP旗を設定するために言語をフィルターにかけるSieveメールに拡大について説明します。 拡大は、IMAPシステム旗を両方の設定に許容して、IMAPにキーワードを許容します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Conventions Used ...........................................2
   2. General Requirements for Flag Handling ..........................3
   3. Actions .........................................................3
      3.1. Action setflag .............................................4
      3.2. Action addflag .............................................4
      3.3. Action removeflag ..........................................5
   4. Test hasflag ....................................................6
   5. Tagged Argument :flags ..........................................7
   6. Interaction with Other Sieve Actions ............................8
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
   9. Extended Example ................................................8
   10. Acknowledgments ...............................................10
   11. Normative References ..........................................10

1. 序論…2 1.1. 使用されるコンベンション…2 2. 旗の取り扱いのための一般要件…3 3. 動作…3 3.1. 動作setflag…4 3.2. 動作addflag…4 3.3. 動作removeflag…5 4. hasflagをテストしてください…6 5. 議論:flagsにタグ付けをします…7 6. 他のふるいの動作との相互作用…8 7. セキュリティ問題…8 8. IANA問題…8 9. 例を広げています…8 10. 承認…10 11. 標準の参照…10

Melnikov                    Standards Track                     [Page 1]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[1ページ]: Imap4flags拡大2008年1月

1.  Introduction

1. 序論

   This is an extension to the Sieve language defined by [SIEVE] for
   setting [IMAP] flags.  It adds a new tagged argument to "keep" and
   "fileinto" that describes the list of flags that have to be set when
   the message is delivered to the specified mailbox.  It also adds
   several actions to help manipulate list of flags and a test to check
   whether a flag belongs to a list.

これは[IMAP]旗を設定するために[SIEVE]によって定義されたSieve言語への拡大です。 指定されたメールボックスにメッセージを渡すとき、それは「保つ」新しいタグ付けをされた議論と設定されなければならない旗のリストについて説明する"fileinto"を加えます。 また、それは、旗がリストに属すかどうかチェックするために旗とテストのリストを操るのを助けるためにいくつかの動作を加えます。

   From the user's perspective, this extension provides several
   capabilities.  First, it allows manipulation of sets of IMAP flags.
   Second, it gives the ability to associate a set of IMAP flags with a
   message that is delivered to a mailstore using the keep/fileinto
   actions.  Third, it maintains an internal variable.  The internal
   variable contains the default flags that will be associated with a
   message that is delivered using the keep, implicit keep, or fileinto
   actions, when the :flags tagged argument is not specified.  When the
   Sieve [VARIABLES] extension is also supported by the Sieve engine, it
   enables support for multiple variables containing sets of IMAP flags.

ユーザの見解から、この拡大はいくつかの能力を提供します。 まず最初に、それはIMAP旗のセットの操作を許します。 2番目に、それは生活費/fileinto動作を使用することでmailstoreに渡されるメッセージに1セットのIMAP旗を関連づける能力を与えます。 3番目に、それは内部の変数を維持します。 内部の変数は生活費、暗黙の生活費、またはfileinto動作を使用することで送られるメッセージに関連しているデフォルト旗を含んでいて、:flagsがいつ議論にタグ付けをしたかは指定されません。 また、Sieve[VARIABLES]拡張子がSieveエンジンによってサポートされるとき、それはIMAP旗のセットを含む複数の変数のサポートを可能にします。

   The capability string associated with the extension defined in this
   document is "imap4flags".  All conformant implementations MUST
   implement all Sieve actions (setflag, addflag, removeflag), the
   "hasflag" test, and the ":flags" tagged argument described in this
   document.

定義される拡大に関連している能力ストリングは本書では"imap4flags"です。 そして、「すべてのconformant実現がすべてのSieve動作(setflag、addflag、removeflag)を実行しなければなりません、"hasflag"テスト、」 : 」 タグ付けをされた議論が本書では説明した旗。

   The "imap4flags" extension can be used with or without the
   "variables" extension [VARIABLES].  When the "variables" extension is
   enabled in a script using <require "variables">, the script can use
   explicit variable names in setflag/addflag/removeflag actions and the
   hasflag test.  See also Section 3 for more details.  When the
   "variables" extension is not enabled, the explicit variable name
   parameter to setflag/addflag/removeflag/hasflag MUST NOT be used and
   MUST cause an error according to [SIEVE].

「変数」拡大[VARIABLES]のあるなしにかかわらず"imap4flags"拡張子を使用できます。 「変数」拡大が<を使用するのが必要とするaスクリプトで可能にされる、「変数、「>、スクリプトはsetflag/addflag/removeflag動作とhasflagテストで明白な変数名を使用できます」。 また、その他の詳細に関してセクション3を見てください。 「変数」拡大が可能にされないとき、setflag/addflag/removeflag/hasflagへの明白な変数名パラメタは、使用されてはいけなくて、[SIEVE]に従って、誤りを引き起こさなければなりません。

1.1.  Conventions Used

1.1. 使用されるコンベンション

   Conventions for notations are as in [SIEVE], Section 1.1, including
   use of "Usage:" label for the definition of action and tagged
   arguments syntax.

記法のためのコンベンションが[SIEVE]、セクション1.1にあって、使用を含めている、「用法:」 動作とタグ付けをされた議論構文の定義のために、ラベルします。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。

Melnikov                    Standards Track                     [Page 2]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[2ページ]: Imap4flags拡大2008年1月

2.  General Requirements for Flag Handling

2. 旗の取り扱いのための一般要件

   The following notes apply to processing of addflag/removeflag/setflag
   actions, the "hasflag" test and the ":flags" tagged argument.

そして、「以下の注意がaddflag/removeflag/setflag動作、"hasflag"テストの処理に適用される、」 : 」 タグ付けをされた議論に旗を揚げさせます。

   A Sieve interpreter MUST ignore empty strings (i.e., "") in a list-
   of-flags parameter.

すなわち、Sieveインタプリタが空のストリングを無視しなければならない、(「「)、フラッグ変数のリストで」

   A string containing a space-separated list of flag names is
   equivalent to a string list consisting of the flags.  This
   requirement is to simplify amalgamation of multiple flag lists.

旗の名のスペースで切り離されたリストを含む五弦は旗から成るストリングリストに同等です。 この要件は複数の現役将官名簿の合併を簡素化することです。

   The Sieve interpreter SHOULD check the list of flags for validity as
   described by [IMAP] ABNF.  In particular, according to [IMAP], non-
   ASCII characters are not allowed in flag names.  However, spaces MUST
   always be allowed as delimiters in strings representing a list of
   flags.  In such strings, multiple spaces between flag names MUST be
   treated as a single space character, and leading and trailing spaces
   MUST be ignored.

[IMAP]ABNFによって説明されるようにSieveインタプリタSHOULDは正当性がないかどうか旗のリストをチェックします。 [IMAP]に従って、特に、非ASCII文字は旗の名で許容されていません。 しかしながら、旗のリストを表すストリングのデリミタとしていつも空間を許容しなければなりません。 そのようなストリングでは、旗の名の間の複数の空間をシングルスペースキャラクタとして扱わなければなりません、そして、主で引きずっている空間を無視しなければなりません。

   If a flag validity check fails, the flag MUST be ignored.

旗のバリディティチェックが失敗するなら、旗を無視しなければなりません。

   Note that it is not possible to use this extension to set or clear
   the \Recent flag or any other special system flag that is not
   settable in [IMAP].  Any such flags MUST be ignored if included in a
   flag list.

Recentが旗を揚げさせる\かいかなる他の[IMAP]で「舗装用敷石-可能」でない特別なシステム旗も設定するか、またはきれいにするのにこの拡張子を使用するのが可能でないことに注意してください。 現役将官名簿に含まれているなら、どんなそのような旗も無視しなければなりません。

3.  Actions

3. 動作

   All actions described in this specification (setflag, addflag,
   removeflag) operate on string variables that contain a set of [IMAP]
   flags.  On variable substitution, a set of flags is represented as a
   string containing a space-separated list of flag names.

この仕様(setflag、addflag、removeflag)で説明されたすべての動作が1セットの[IMAP]旗を含む列変数を作動させます。 可変代替のときに、1セットの旗は旗の名のスペースで切り離されたリストを含むストリングとして表されます。

   Any setflag/addflag/removeflag action MAY alter the flag list in any
   way that leaves its semantics as a set of case-insensitive words
   unaltered.  For example, it may reorder the flags, alter the case of
   the letters in them, or add or remove duplicates or extraneous
   spaces.  Scripts MUST NOT make assumptions about the ordering of
   flags in lists or the preservation of their case.

どんなsetflag/addflag/removeflag動作も1セットの大文字と小文字を区別しない単語が非変更されたとき意味論を残すどんな方法でも現役将官名簿を変更するかもしれません。 例えば、そうするかもしれない、追加注文、旗、それらの手紙に関するケースを変更してくださいか、または写しか異質な空間を加えるか、取り除いてください。 スクリプトはリストにおける、旗の注文かそれらのケースの保存に関する仮定をしてはいけません。

   Note that the parameter specifying a variable name to
   setflag/addflag/removeflag actions and the hasflag test is optional.
   If the parameter is not specified, the actions operate on the
   internal variable, which has the empty value when the script starts
   execution.  If the SIEVE interpreter doesn't support the "variables"
   extension [VARIABLES], the presence of the variable name parameter
   will cause a runtime error [SIEVE].

setflag/addflag/removeflag動作とhasflagテストに変数名を指定するパラメタが任意であることに注意してください。 パラメタが指定されないなら、動作は内部の変数を作動させます。(スクリプトが実行を始めるとき、それは、空の値を持っています)。 SIEVEインタプリタが「変数」拡大[VARIABLES]を支持しないと、変数名パラメタの存在はランタイム・エラー[SIEVE]を引き起こすでしょう。

Melnikov                    Standards Track                     [Page 3]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[3ページ]: Imap4flags拡大2008年1月

   The "addflag" action adds flags to an existing set.  The "removeflag"
   action removes flags from an existing set.  The "setflag" action
   replaces an existing set of flags with a new set.  The "set" action
   defined in [VARIABLES] can be used to replace an existing set of
   flags with a new set as well.  However, it should be noted that the
   "set" action can't perform any flag reordering, duplicate
   elimination, etc.

"addflag"動作は既存のセットに旗を追加します。 "removeflag"動作は既存のセットから旗を取り外します。 "setflag"動作は既存のセットの旗を新しいセットに取り替えます。 既存のセットの旗をまた、新しいセットに取り替えるのに[VARIABLES]で定義された「セット」動作は使用できます。 しかしながら、「セット」動作がどんな旗の再命令、写し除去なども実行できないことに注意されるべきです。

   The :flags tagged argument to "keep" and "fileinto" actions is used
   to associate a set of flags with the current message.  If the :flags
   tagged argument is not specified with those two actions, the current
   value of the internal variable is used instead.  The value of the
   internal variable also applies to the implicit keep.

:flagsは「保つ」ために議論にタグ付けをしました、そして、"fileinto"動作は、1セットの旗を現在のメッセージに関連づけるのに使用されます。 :flagsであるなら、タグ付けをされた議論はそれらの2つの動作で指定されないで、内部の変数の現行価値は代わりに使用されます。 また変数が暗黙に当てはまる内部の値は保たれます。

   Note that when keep/fileinto is used multiple times in a script and
   duplicate message elimination is performed (as described in Section
   2.10.3 of [SIEVE]), the last flag list value MUST win.

いつが、/がfileintoであることを保つかというメモが使用されて、スクリプトと写しメッセージ除去における複数の回が実行されるという(.3セクション2.10[SIEVE]で説明されるように)ことである、最後の現役将官名簿値は得られなければなりません。

3.1.  Action setflag

3.1. 動作setflag

   Usage:   setflag [<variablename: string>]
            <list-of-flags: string-list>

用法: 旗のsetflag[<variablename: ストリング>]<リスト: ストリングリスト>。

   Setflag is used for setting [IMAP] system flags or keywords.
   Setflag replaces any previously set flags.

Setflagは、[IMAP]システム旗かキーワードを設定するのに使用されます。 Setflagはどんな以前に設定された旗も置き換えます。

   Example:  if size :over 500K {
                 setflag "\\Deleted";
             }

例: 500Kのサイズ:overです。「」 \\が削除したsetflag、」、。

   A more substantial example is the following:

より実質的な例は以下です:

   Example:
        if header :contains "from" "boss@frobnitzm.example.edu" {
            setflag "flagvar" "\\Flagged";
            fileinto :flags "${flagvar}" "INBOX.From Boss";
        }

例: ヘッダー:contains“from"" boss@frobnitzm.example.edu "です。「INBOX.Fromは牛耳る」「{setflagに、「flagvarに、」 」 \\は弛んだ」; fileinto:flags」という$flagvar」。

3.2.  Action addflag

3.2. 動作addflag

   Usage:   addflag [<variablename: string>]
            <list-of-flags: string-list>

用法: 旗のaddflag[<variablename: ストリング>]<リスト: ストリングリスト>。

   Addflag is used to add flags to a list of [IMAP] flags.  It doesn't
   replace any previously set flags.  This means that multiple
   occurrences of addflag are treated additively.

Addflagは、[IMAP]旗のリストに旗を追加するのに使用されます。 それはどんな以前に設定された旗も置き換えません。 これは、addflagの複数の発生が添加物に扱われることを意味します。

Melnikov                    Standards Track                     [Page 4]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[4ページ]: Imap4flags拡大2008年1月

   The following examples demonstrate requirements described in Section
   2.1.  The following two actions

以下の例はセクション2.1で説明された要件を示します。 以下の2つの動作

      addflag "flagvar" "\\Deleted";
      addflag "flagvar" "\\Answered";

「」 \\が削除したaddflag"flagvar"」。 「」 \\が答えたaddflag"flagvar"」。

   produce the same result as the single action

ただ一つの動作と同じ結果を生んでください。

      addflag "flagvar" ["\\Deleted", "\\Answered"];

「addflag"flagvar"、[「\が削除した\」、」、\が答えた\、」、]、。

   or

または

      addflag "flagvar" "\\Deleted \\Answered";

「」 \\が削除したaddflag"flagvar"\\に答えました」。

   or

または

      addflag "flagvar" "\\Answered \\Deleted";

「」 \\が\が削除した\に答えたaddflag"flagvar"」。

3.3.  Action removeflag

3.3. 動作removeflag

   Usage:   removeflag [<variablename: string>]
            <list-of-flags: string-list>

用法: 旗のremoveflag[<variablename: ストリング>]<リスト: ストリングリスト>。

   Removeflag is used to remove flags from a list of [IMAP] flags.
   Removeflag clears flags previously set by "set"/"addflag".  Calling
   removeflag with a flag that wasn't set before is not an error and is
   ignored.  Note that if an implementation doesn't perform automatic
   duplicate elimination, it MUST remove all occurrences of the flags
   specified in the second parameter to removeflag.  Empty strings in
   the list-of-flags MUST be ignored.  Also note that flag names are
   case-insensitive, as described in [IMAP].  Multiple removeflag
   actions are treated additively.

Removeflagは、[IMAP]旗のリストから旗を取り外すのに使用されます。 Removeflagは以前に「セット」/"addflag"によって設定された旗をきれいにします。 以前設定されなかった旗でremoveflagと呼ぶのが、誤りでなく、無視されます。 実現が自動写し除去を実行しないなら、2番目のパラメタでremoveflagに指定された旗のすべての発生を取り除かなければならないことに注意してください。 旗のリストの空のストリングを無視しなければなりません。 また、[IMAP]で説明されるように旗の名が大文字と小文字を区別しないことに注意してください。 複数のremoveflag動作が添加物に扱われます。

      Example:
        if header :contains "Disposition-Notification-To"
           "mel@example.com" {
            addflag "flagvar" "$MDNRequired";
        }
        if header :contains "from" "imap@cac.washington.example.edu" {
            removeflag "flagvar" "$MDNRequired";
            fileinto :flags "${flagvar}" "INBOX.imap-list";
        }

例: 「ヘッダー:containsである、「気質通知、」 " mel@example.com "、addflagは「」 」 $MDNRequiredをflagvarする」;、ヘッダー:contains“from"" imap@cac.washington.example.edu "です。「{removeflagは「」 」 $MDNRequiredをflagvarする」; fileinto:flags」という$flagvar」「INBOX.imap-リスト」。

Melnikov                    Standards Track                     [Page 5]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[5ページ]: Imap4flags拡大2008年1月

4.  Test hasflag

4. テストhasflag

   Usage: hasflag [MATCH-TYPE] [COMPARATOR]
          [<variable-list: string-list>]
          <list-of-flags: string-list>

用法: 旗のhasflag[MATCH-TYPE][COMPARATOR][<の可変リスト: ストリングリスト>]<リスト: ストリングリスト>。

   The hasflag test evaluates to true if any of the variables matches
   any flag name.  The type of match defaults to ":is".  If the list of
   variables is omitted, value of the internal variable is used instead.

テストがもしあれば本当に評価する変数のhasflagはどんな旗の名にも合っています。 「マッチのタイプはデフォルトとする」:、」 変数のリストが省略されるなら、内部の変数の値は代わりに使用されます。

   The default comparator is "i;ascii-casemap", which is the same case-
   insensitive comparison as defined for IMAP flags by [IMAP].

デフォルト比較器がそうである、「i; ASCIIでcasemapする」、IMAP旗のために[IMAP]によって定義されるように同じケースの神経の鈍い比較である。

   The "relational" extension [RELATIONAL] adds a match type called
   ":count".  The :count of a variable returns the number of distinct
   flags in it.  The count of a list of variables is the sum of the
   counts of the member variables.

「「関係している」拡大[RELATIONAL]は」 : カウントと呼ばれるマッチタイプを加えます。」 変数の:countはそれの異なった旗の数を返します。 変数のリストのカウントはメンバー変数のカウントの合計です。

   Example:
     If the internal variable has the value "A B", the following test

例: 内部の変数に値「B」があるなら、以下はテストされます。

      hasflag :is "b A"

hasflag:is「b A」

     evaluates to true.  The above test can also be written as

本当に評価します。 また、上のテストとして、書くことができます。

      hasflag ["b","A"]

hasflag[「b」、「A」]

   Example:
     If the variable "MyVar" has value "NonJunk Junk gnus-forward
     $Forwarded NotJunk JunkRecorded $Junk $NotJunk", the following
     tests evaluate to true:

例: 可変"MyVar"に値の「NonJunk Junkヌー前進の$Forwarded NotJunk JunkRecorded$Junk$NotJunk」があるなら、以下のテストは本当に以下を評価します。

      hasflag :contains "MyVar" "Junk"
      hasflag :contains "MyVar" "forward"
      hasflag :contains "MyVar" ["label", "forward"]
      hasflag :contains "MyVar" ["junk", "forward"]

hasflag:contains"MyVar"「くず」hasflagの:containsの"MyVar"「前進」のhasflag:contains"MyVar"[「前方の」「ラベル」]hasflag:contains"MyVar"[「前方の」「くず」]

     Note that the last of these tests can be rewritten
     as

これらのテストの最終を書き直すことができる注意

      hasflag :contains "MyVar" "junk forward"

hasflag:contains"MyVar"「くずのフォワード」

     or

または

      hasflag :contains "MyVar" "forward junk"

hasflag:contains"MyVar"「前進のくず」

     However, the last two forms are not recommended.

しかしながら、最後の2つの書式は推薦されません。

Melnikov                    Standards Track                     [Page 6]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[6ページ]: Imap4flags拡大2008年1月

     And the following tests will evaluate to false:

そして、以下のテストは誤っているのに以下を評価するでしょう。

      hasflag :contains "MyVar" "label"

hasflag:contains"MyVar"「ラベル」

      hasflag :contains "MyVar" ["label1", "label2"]

hasflag:contains"MyVar"[「label1"、「label2"]」

   Example:
     If the variable "MyFlags" has the value "A B", the following test

例: 可変「MyFlags」に値「B」があるなら、以下はテストされます。

       hasflag :count "ge" :comparator "i;ascii-numeric"
               "MyFlags" "2"

hasflag:count"ge":comparator、「i、; 」 ASCII数値「MyFlags」、「2インチ」

     evaluates to true, as the variable contains 2 distinct flags.

変数が2個の異なった旗を含んでいて、本当に評価します。

5.  Tagged Argument :flags

5. タグ付けをされた議論:flags

   This specification adds a new optional tagged argument ":flags" that
   alters the behavior of actions "keep" and "fileinto".

「キープ「この仕様は新しい任意のタグ付けをされた議論に」 : 旗を加え」動作の振舞いを変更する」と"fileinto"。

   The :flags tagged argument specifies that the flags provided in the
   subsequent argument should be set when fileinto/keep delivers the
   message to the target mailbox/user's main mailbox.  If the :flags
   tagged argument is not specified, "keep" or "fileinto" will use the
   current value of the internal variable when delivering the message to
   the target mailbox.

/が保つfileintoが目標メールボックス/ユーザの主なメールボックスにメッセージを渡すとき、その後の議論に提供された旗をあるはずであるタグ付けをされた議論が指定する:flagsはセットしました。 目標メールボックスにメッセージを渡すとき、:flagsであるなら、タグ付けをされた議論が指定されません、「保ってください」"fileinto"は内部の変数の現行価値を使用するでしょう。

   Usage:   ":flags" <list-of-flags: string-list>

用法: <が旗について記載された「: 旗」: ストリングリスト>。

   The copy of the message filed into the mailbox will have only flags
   listed after the :flags tagged argument.

メールボックスの中にファイルされたメッセージのコピーには、:flagsが議論にタグ付けをした後に記載された旗しかないでしょう。

   The Sieve interpreter MUST ignore all flags that it can't store
   permanently.  This means that the interpreter MUST NOT treat failure
   to store any flag as a runtime failure to execute the Sieve script.
   For example, if the mailbox "INBOX.From Boss" can't store any flags,
   then

Sieveインタプリタはそれが永久に収納できないすべての旗を無視しなければなりません。 これは、インタプリタがSieveスクリプトを作成しないランタイムのこととしてどんな旗も収納しないことを扱ってはいけないことを意味します。 例えば、その時でないメールボックス「INBOX.Fromボス」がどんな旗も収納できないなら

     fileinto :flags "\\Deleted" "INBOX.From Boss";

「fileinto:flags」\\は」 「INBOX.Fromボス」を削除しました。

   and

そして

     fileinto "INBOX.From Boss";

fileinto「INBOX.Fromボス」。

   are equivalent.

同等物はそうですか?

   This document doesn't dictate how the Sieve interpreter will set the
   [IMAP] flags.  In particular, the Sieve interpreter may work as an
   IMAP client or may have direct access to the mailstore.

このドキュメントはSieveインタプリタがどう[IMAP]旗を設定するかを決めません。 特に、Sieveインタプリタは、IMAPクライアントとして働いているか、またはmailstoreにダイレクトに近づく手段を持っているかもしれません。

Melnikov                    Standards Track                     [Page 7]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[7ページ]: Imap4flags拡大2008年1月

6.  Interaction with Other Sieve Actions

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

   This extension works only on the message that is currently being
   processed by Sieve; it doesn't affect another message generated as a
   side effect of any action or any other message already in the
   mailstore.

この拡大は現在Sieveによって処理されているメッセージだけに取り組みます。 それはどんな動作の副作用としても発生する別のメッセージか既にmailstoreのいかなる他のメッセージにも影響しません。

   The extension described in this document doesn't change the implicit
   keep (see Section 2.10.2 of [SIEVE]).

本書では説明された拡大は暗黙の生活費を変えません(.2セクション2.10[SIEVE]を見てください)。

7.  Security Considerations

7. セキュリティ問題

   Security considerations are discussed in [IMAP], [SIEVE], and
   [VARIABLES].

[IMAP]、[SIEVE]、および[VARIABLES]でセキュリティ問題について議論します。

   This extension intentionally doesn't allow setting [IMAP] flags on an
   arbitrary message in the [IMAP] message store.

この拡大で、故意に[IMAP]メッセージ店で[IMAP]旗を任意のメッセージにけしかけません。

   It is believed that this extension doesn't introduce any additional
   security concerns.

この拡大が少しの追加担保関心も導入しないと信じられています。

8.  IANA Considerations

8. IANA問題

   The following template specifies the IANA registration of the
   variables 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: imap4flags
   Description:     Adds actions and tests for manipulating IMAP flags
   RFC number:      RFC 5232
   Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>

能力名: imap4flags記述: IMAP旗のRFC番号を操るための動作とテストを加えます: RFC5232Contactアドレス: 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拡張子のリストにこの情報を追加してあります。

9.  Extended Example

9. 拡張例

   #
   # Example Sieve Filter
   # Declare any optional features or extension used by the script
   #
   require ["fileinto", "imap4flags", "variables"];

# # 例のSieve Filter#Declare、スクリプト#で使用されるどんなオプション機能や拡張子も["fileinto"、"imap4flags"「変数」]を必要とします。

   #
   # Move large messages to a special mailbox
   #

# # 大きいメッセージを特別なメールボックス#に動かしてください。

Melnikov                    Standards Track                     [Page 8]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[8ページ]: Imap4flags拡大2008年1月

   if size :over 1M
           {
           addflag "MyFlags" "Big";
           if header :is "From" "boss@company.example.com"
                      {
   # The message will be marked as "\Flagged Big" when filed into
   # mailbox "Big messages"
                      addflag "MyFlags" "\\Flagged";
                      }
           fileinto :flags "${MyFlags}" "Big messages";
           }

1Mのサイズ:overです。「ヘッダー:is“From"" boss@company.example.com "であるなら「大きく」「MyFlags」をaddflagする、#」 \が」 #メールボックス「大きいメッセージ」addflag「」 」 \\が旗を揚げさせたMyFlags」にファイルされたいつに大きく旗を揚げさせたかので、メッセージはマークされるでしょう;、fileinto:flags、」 $MyFlags、」 「大きいメッセージ」。

   if header :is "From" "grandma@example.net"
           {
           addflag "MyFlags" ["\\Answered", "$MDNSent"];
   # If the message is bigger than 1Mb it will be marked as
   # "Big \Answered $MDNSent" when filed into mailbox "grandma".
   # If the message is shorter than 1Mb it will be marked as
   # "\Answered $MDNSent"
           fileinto :flags "${MyFlags}" "GrandMa";
           }

ヘッダー:is“From"" grandma@example.net "です。「addflag「MyFlags」、[「\が答えた\」、」、$MDNSent、」、]、; #If、メッセージ、メールボックス「おばあちゃん」 #Ifにファイルされて、メッセージが#」 \が」 fileinto:flagsに$MDNSentに答えたのでそれが1Mbマークされるより短くそれが#として1Mbマークされるより大きい「大きい$MDNSentに答えた\」が」 $MyFlagsである、」 「おばあちゃん」。

   #
   # Handle messages from known mailing lists
   # Move messages from IETF filter discussion list to filter folder
   #
   if header :is "Sender" "owner-ietf-mta-filters@example.org"
           {
           set "MyFlags" "\\Flagged $Work";
   # Message will have both "\Flagged" and $Work flags
           keep :flags "${MyFlags}";
           }

# # IETFフィルタ議論からの知られているメーリングリスト#Moveメッセージからのハンドルメッセージは、ヘッダー:is「送付者」" owner-ietf-mta-filters@example.org "であるならフォルダー#をフィルターにかけるためにリストアップされています。「」 \\が旗を揚げさせた「MyFlags」$仕事を設定してください、」、;、#Messageには両方がある 」 \、旗を揚げられて、」 $Work旗が、:flagsが」 $MyFlagsであることを保つ、」、。

   #
   # Keep all messages to or from people in my company
   #
   elsif anyof address :domain :is ["From", "To"] "company.example.com"
           {
           keep :flags "${MyFlags}"; # keep in "Inbox" folder
           }

# # 人々か私の会社#elsif anyofアドレス:domain:is[“From"、“To"]"company.example.com"の人々からのすべてのメッセージを保ってください。「:flagsが」 $MyFlagsであることを保ってください、」、;#「受信トレイ」フォルダーに閉じ込めてください

   # Try to catch unsolicited email.  If a message is not to me,
   # or it contains a subject known to be spam, file it away.
   #
   elsif anyof (not address :all :contains
                  ["To", "Cc"] "me@company.example.com",
                header :matches "subject"
                  ["*make*money*fast*", "*university*dipl*mas*"])

# 求められていないメールを捕らえるようにしてください。 メッセージが私に、スパムであることが知られている対象を含んでいるということでないなら、それを記録してください。 # elsif anyof「(:all:contains[“To"、「cc」]" me@company.example.com "、ヘッダー:matches「対象」を記述しない、[「**お金*を速い*にしてください」、」、*大学*dipl*mas*、」、)

Melnikov                    Standards Track                     [Page 9]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[9ページ]: Imap4flags拡大2008年1月

           {
           remove "MyFlags" "\\Flagged";
           fileinto :flags "${MyFlags}" "spam";
           }
   else
           {
           # Move all other external mail to "personal"
           # folder.
           fileinto :flags "${MyFlags}" "personal";
           }

「{「」 」 \\が旗を揚げさせたMyFlags」を取り除いてください; fileinto:flags」という$MyFlags」は「ばらまく」;、ほか「他のすべての外部が「個人的な」#フォルダーfileinto:flagsに」 $MyFlagsを郵送する#移動、」 「個人的」。

10.  Acknowledgments

10. 承認

   This document has been revised in part based on comments and
   discussions that took place on and off the Sieve mailing list.

このドキュメントはコメントに基づいて一部改訂されました、そして、取った議論は時々Sieveメーリングリストを置きます。

   The help of those who took the time to review the document and make
   suggestions is appreciated, especially that of Tim Showalter, Barry
   Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, Matthew Elvey,
   Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, Kjetil Torgrim
   Homme, Mark E.  Mallett, Dave Cridland, Arnt Gulbrandsen, Philip
   Guenther, Rob Austein, Sam Hartman, Eric Gray, and Cullen Jennings.

ドキュメントを再検討して、提案をするのに感謝するとき取った人の助け、特にティム・ショウォーターのもの、バリーLeiba、ランドルGellens、ケン・マーチソン、サイラスDaboo、マシュー・エルビ、ユッタDegener、ネッド・フリード、マークMutz、ナイジェル・スウィンソン、Kjetil Torgrim Homme、マーク・E.マレット、デーヴCridland、Arnt Gulbrandsen、フィリップ・グンサー、ロブAustein、サム・ハートマン、エリック・グレー、およびCullenジョニングス。

   Special thanks to Tony Hansen and David Lamb for helping me better
   explain the concept.

私をよりよく助けるためのトニー・ハンセンとデヴィッドLambへの特別な感謝で、概念がわかります。

11.  Normative References

11. 引用規格

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

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

   [IMAP]       Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
                4rev1", RFC 3501, March 2003.

[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

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

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

   [RELATIONAL] Segmuller, W. and B. Leiba "Sieve Email Filtering:
                Relational Extension", RFC 5231, January 2008.

「以下をフィルターにかけて、ふるいはメールする」[関係する]のSegmuller、W.、およびB.Leiba 「関係拡大」、RFC5231、2008年1月。

Melnikov                    Standards Track                    [Page 10]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[10ページ]: Imap4flags拡大2008年1月

Author's Address

作者のアドレス

   Alexey Melnikov
   Isode Limited

AlexeyメリニコフIsode株式会社

   5 Castle Business Village
   Hampton, Middlesex
   United Kingdom, TW12 2BX

5 城のビジネス村のハンプトン、ミドルセックスイギリスのTW12 2BX

   EMail: alexey.melnikov@isode.com

メール: alexey.melnikov@isode.com

Melnikov                    Standards Track                    [Page 11]

RFC 5232              Sieve: Imap4flags Extension           January 2008

メリニコフStandardsはRFC5232ふるいを追跡します[11ページ]: Imap4flags拡大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に情報を記述してください。

Melnikov                    Standards Track                    [Page 12]

メリニコフ標準化過程[12ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

FLASHの全てのアクションから文字を検索する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る