RFC5173 日本語訳

Network Working Group                                         J. Degener
Request for Comments: 5173                                   P. Guenther
Updates: 5229                                             Sendmail, Inc.
Category: Standards Track                                     April 2008

Degenerがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5173のP.グンサーアップデート: 5229年のセンドメールInc.カテゴリ: 標準化過程2008年4月

                 Sieve Email Filtering: Body 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 defines a new command for the "Sieve" email filtering
   language that tests for the occurrence of one or more strings in the
   body of an email message.

このドキュメントは「ふるい」というメールメッセージのボディーでの1個以上のストリングの発生がないかどうかテストされる言語をフィルターにかけるメールのための新しいコマンドを定義します。

Degener & Guenther          Standards Track                     [Page 1]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[1ページ]: ボディー拡大2008年4月

1.  Introduction

1. 序論

   The "body" test checks for the occurrence of one or more strings in
   the body of an email message.  Such a test was initially discussed
   for the [SIEVE] base document, but was subsequently removed because
   it was thought to be too costly to implement.

「ボディー」テストはメールメッセージのボディーでの1個以上のストリングの発生がないかどうかチェックします。 そのようなテストを初めは[SIEVE]元にした文書のために議論しましたが、実行できないくらい高価であると考えられたので、次に、取り除きました。

   Nevertheless, several server vendors have implemented some form of
   the "body" test.

それにもかかわらず、いくつかのサーバ業者が「ボディー」テストの何らかのフォームを実行しました。

   This document reintroduces the "body" test as an extension, and
   specifies its syntax and semantics.

このドキュメントは、拡大として「ボディー」テストに再紹介して、その構文と意味論を指定します。

2.  Conventions Used in This Document

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

   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 [KEYWORDS].

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

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

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

   The rules for interpreting the grammar are defined in [SIEVE] and
   inherited by this specification.  In particular, readers of this
   document are reminded that according to [SIEVE] Sections 2.6.2 and
   2.6.3, optional arguments such as COMPARATOR and MATCH-TYPE can
   appear in any order.

文法を解釈するための規則は、[SIEVE]で定義されて、この仕様で引き継がれます。 特に、このドキュメントの読者は[SIEVE]のセクション2.6.2と2.6.3に従って、COMPARATORやMATCH-TYPEなどの任意の議論が順不同に現れることができるのを思い出させられています。

3.  Capability Identifier

3. 能力識別子

   The capability string associated with the extension defined in this
   document is "body".

定義される拡大に関連している能力ストリングは本書では「ボディー」です。

4.  Test body

4. テスト本体

   Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM]
                <key-list: string-list>

用法: 「ボディー」[比較器][マッチタイプ][ボディー変換]<の主要なリスト: ストリングリスト>。

   The body test matches content in the body of an email message, that
   is, anything following the first empty line after the header.  (The
   empty line itself, if present, is not considered to be part of the
   body.)

ボディーテストはメールメッセージ(すなわち、ヘッダーの後に最初の人影のない線に従う何でも)のボディーで内容に合っています。 (存在しているなら、人影のない線自体は身体の一部であると考えられません。)

   The COMPARATOR and MATCH-TYPE keyword parameters are defined in
   [SIEVE].  As specified in Sections 2.7.1 and 2.7.3 of [SIEVE], the
   default COMPARATOR is "i;ascii-casemap" and the default MATCH-TYPE is
   ":is".

COMPARATORとMATCH-TYPEキーワード・パラメータは[SIEVE]で定義されます。 「セクション2.7.1と2.7で指定されるように、.3[SIEVE]、デフォルトCOMPARATORは「i; 」 デフォルトMATCH-TYPEをASCIIでcasemapするのは、そうです」です: あります。」

Degener & Guenther          Standards Track                     [Page 2]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[2ページ]: ボディー拡大2008年4月

   The BODY-TRANSFORM is a keyword parameter that governs how a set of
   strings to be matched against are extracted from the body of the
   message.  If a message consists of a header only, not followed by an
   empty line, then that set is empty and all "body" tests return false,
   including those that test for an empty string.  (This is similar to
   how the "header" test always fails when the named header fields
   aren't present.)  Otherwise, the transform must be followed as
   defined below in Section 5.

BODY-TRANSFORMは合わせられるストリングのセットがメッセージ欄からどう抽出されるかを治めるキーワード・パラメータです。 メッセージが人影のない線のそばで続くのではなく、ヘッダーだけから成るなら、そのセットは空です、そして、すべての「ボディー」テストが虚偽で戻ります、空のストリングがないかどうかテストされるものを含んでいて。 (これは命名されたヘッダーフィールドが存在していないとき、「ヘッダー」テストがどういつも失敗するかと同様です。) さもなければ、以下でセクション5で定義されるように変換に続かなければなりません。

   Note that the transformations defined here do *not* match against
   each line of the message independently, so the strings will usually
   contain CRLFs.  How these can be matched is governed by the
   comparator and match-type.  For example, with the default comparator
   of "i;ascii-casemap", they can be included literally in the key
   strings, or be matched with the "*" or "?" wildcards of the :matches
   match-type, or be skipped with :contains.

通常、ストリングがCRLFsを含むように、ここで定義された変化が独自にメッセージの各線に対して*マッチではなく、*をすることに注意してください。 どうこれらを合わせることができるかは比較器とマッチタイプによって治められます。 例えば「i; ASCIIでcasemapする」デフォルト比較器によるそれらを文字通り主要なストリングで含められているか、:matchesマッチタイプの「*」か“?"ワイルドカードに合わせている、または:containsでスキップできます。

5.  Body Transform

5. ボディー変換

   Prior to matching content in a message body, "transformations" can be
   applied that filter and decode certain parts of the body.  These
   transformations are selected by a "BODY-TRANSFORM" keyword parameter.

メッセージ本体で内容を合わせる前に、身体のある部分をフィルターにかけて、解読する「変化」は、適用できます。 これらの変化は「ボディー変換」キーワード・パラメータによって選択されます。

   Usage: ":raw"
        / ":content" <content-types: string-list>
        / ":text"

用法: 「「: 生で」、/、」 : 」 <内容タイプを満足させてください: 「ストリングリスト>/」: テキスト、」

   The default transformation is :text.

デフォルト変化は:textです。

5.1.  Body Transform ":raw"

5.1. 「ボディー変換」: 生で」

   The ":raw" transform matches against the entire undecoded body of a
   message as a single item.

「」 : 生で、」 変換は1つの項目としてメッセージの全体の非解読されたボディーに対して合っています。

   If the specified body-transform is ":raw", the [MIME] structure of
   the body is irrelevant.  The implementation MUST NOT remove any
   transfer encoding from the message, MUST NOT refuse to filter
   messages with syntactic errors (unless the environment it is part of
   rejects them outright), and MUST treat multipart boundaries or the
   MIME headers of enclosed body parts as part of the content being
   matched against, instead of MIME structures to interpret.

「指定されたボディー変換がそうなら」:、生で」、ボディーの[MIME]構造は無関係です。 実現がメッセージからのどんな転送コード化も取り除いてはいけなくて、NOTが、構文の誤りでメッセージをフィルターにかけるのを拒否しなければならない、(環境が廃棄物を離れさせない、それら、完全に)、MIME構造の代わりに解釈するために合わせられている内容の一部としての同封の身体の部分の御馳走の複合境界かMIMEヘッダーがそうしなければなりません。

Degener & Guenther          Standards Track                     [Page 3]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[3ページ]: ボディー拡大2008年4月

   Example:

例:

        require "body";

「ボディー」を必要としてください。

        # This will match a message containing the literal text
        # "MAKE MONEY FAST" in body parts (ignoring any
        # content-transfer-encodings) or MIME headers other than
        # the outermost RFC 2822 header.

# これは、ボディ・パーツ(どんな#満足している転送encodingsも無視する)の#「速くお金を稼いでください」という文字通りのテキストを含んでいて、メッセージを合わせるか、または#、を除いたヘッダーのために2822年の一番はずれのRFCヘッダーをまねるでしょう。

        if body :raw :contains "MAKE MONEY FAST" {
                discard;
        }

ボディー:raw:containsであるなら「速くお金を稼いでください」破棄。

5.2.  Body Transform ":content"

5.2. 「ボディーは」 : 内容を変えます」

   If the body transform is ":content", the MIME parts that have the
   specified content types are matched against independently.

「ボディー変換がそうなら」:、満足、」、独自に指定された満足しているタイプがあるMIMEの部品に合わせられています。

   If an individual content type begins or ends with a '/' (slash) or
   contains multiple slashes, then it matches no content types.
   Otherwise, if it contains a slash, then it specifies a full
   <type>/<subtype> pair, and matches only that specific content type.
   If it is the empty string, all MIME content types are matched.
   Otherwise, it specifies a <type> only, and any subtype of that type
   matches it.

'独特の満足しているタイプが始まるか、'/'(スラッシュ)で終わるか、または複数のスラッシュを含んでいるなら、それはどんな満足しているタイプにも合っていません。 さもなければ、スラッシュを含んでいるなら、それは、完全な<タイプ>/<「副-タイプ」>組を指定して、その特定の満足しているタイプだけに合っています。 それが空のストリングであるなら、すべてのMIME内容タイプが取り組んでいます。 さもなければ、<タイプ>だけを指定します、そして、そのタイプのどんな「副-タイプ」もそれに合っています。

   The search for MIME parts matching the :content specification is
   recursive and automatically descends into multipart and
   message/rfc822 MIME parts.  All MIME parts with matching types are
   searched for the key strings.  The test returns true if any
   combination of a searched MIME part and key-list argument match.

:content仕様に合っているMIMEの部品の検索は、再帰的であり、自動的に複合とメッセージ/rfc822MIMEの部品の中に降ります。 合っているタイプがあるすべてのMIMEの部品は主要なストリングを捜されます。 テストは捜されたMIME部分と主要なリスト議論マッチのどんな組み合わせであるならも本当に戻ります。

   If the :content specification matches a multipart MIME part, only the
   prologue and epilogue sections of the part will be searched for the
   key strings, treating the entire prologue and the entire epilogue as
   separate strings; the contents of nested parts are only searched if
   their respective types match the :content specification.

:content仕様が複合MIME部分に合っていると、部分のプロローグとエピローグ部だけは主要なストリングを捜されるでしょう、別々のストリングとして全体のプロローグと全体のエピローグを扱って。 彼らのそれぞれのタイプが:content仕様に合っている場合にだけ、入れ子にされた部品の内容は捜されます。

   If the :content specification matches a message/rfc822 MIME part,
   only the header of the nested message will be searched for the key
   strings, treating the header as a single string; the contents of the
   nested message body parts are only searched if their content type
   matches the :content specification.

:content仕様がメッセージ/rfc822MIME部分に合っていると、入れ子にされたメッセージのヘッダーだけは主要なストリングを捜されるでしょう、一連としてヘッダーを扱って。 彼らの満足しているタイプが:content仕様に合っている場合にだけ、入れ子にされたメッセージ身体の部分の内容は捜されます。

   For other MIME types, the entire part will be searched as a single
   string.

他のMIMEの種類に関しては、全体の部分は一連として捜されるでしょう。

Degener & Guenther          Standards Track                     [Page 4]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[4ページ]: ボディー拡大2008年4月

   (Matches against container types with an empty match string can be
   useful as tests for the existence of such parts.)

(空のマッチストリングがある容器タイプに対するマッチはそのような部品の存在のためのテストとして役に立つ場合があります。)

   Example:

例:

        From: Whomever
        To: Someone
        Date: Whenever
        Subject: whatever
        Content-Type: multipart/mixed; boundary=outer

From: 誰でも、To: だれか、日付: いつ、Subject: いかなるコンテントタイプも: 複合か混ぜられる。 境界=外側です。

     &  This is a multi-part message in MIME format.
     &
        --outer
        Content-Type: multipart/alternative; boundary=inner

これはMIME形式において複合メッセージです。 --外側のコンテントタイプ: 複合/代替手段。 境界=内側です。

     &  This is a nested multi-part message in MIME format.
     &
        --inner
        Content-Type: text/plain; charset="us-ascii"

これはMIME形式において入れ子にされた複合メッセージです。 --内側のコンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」

     $  Hello
     $
        --inner
        Content-Type: text/html; charset="us-ascii"

$、こんにちは、$--内側のコンテントタイプ: テキスト/html。 charsetが等しい、「私たち、-、ASCII、」

     %  <html><body>Hello</body></html>
     %
        --inner--
     &
     &  This is the end of the inner MIME multipart.
     &
        --outer
        Content-Type: message/rfc822

Thisは内側の終わりです。%<htmlな><ボディー>Hello</ボディー></html>%--内側--、MIME複合です。 --外側のコンテントタイプ: メッセージ/rfc822

     !  From: Someone Else
     !  Subject: hello request

From: 他の誰か、Subject: こんにちは、要求

     $  Please say Hello
     $
        --outer--
     &
     &  This is the end of the outer MIME multipart.

Thisは外側の終わりです。$をお願いします、言いたい事Hello$--外側--、MIME複合です。

Degener & Guenther          Standards Track                     [Page 5]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[5ページ]: ボディー拡大2008年4月

   In the above example, the '&', '$', '%', and '!' characters at the
   start of a line are used to illustrate what portions of the example
   message are used in tests:

上記の例では、線の始めの'&'、'$'、'%'、および'!'キャラクタは例のメッセージのどんな部分がテストで使用されるかを例証するのに使用されます:

   - the lines starting with '&' are the ones that are tested when a
     'body :content "multipart" :contains "MIME"' test is executed.

- '&'から始まる線は'ボディーの:contentの「複合」の:contains「MIME」'テストが実行されるときテストされるものです。

   - the lines starting with '$' are the ones that are tested when a
     'body :content "text/plain" :contains "Hello"' test is executed.

- '$'から始まる線は「こんにちは」という'ボディーの:contentの「テキスト/明瞭である」':containsテストが実行されるときテストされるものです。

   - the lines starting with '%' are the ones that are tested when a
     'body :content "text/html" :contains "Hello"' test is executed.

- '%'から始まる線は「こんにちは」という'ボディー:content「テキスト/html」:contains'テストが実行されるときテストされるものです。

   - the lines starting with '$' or '%' are the ones that are tested
     when a 'body :content "text" :contains "Hello"' test is executed.

- '$'か'%'から始まる線は「こんにちは」という'ボディー:content「テキスト」:contains'テストが実行されるときテストされるものです。

   - the lines starting with '!' are the ones that are tested when a
     'body :content "message/rfc822" :contains "Hello"' test is
     executed.

- '!'から始まる線は「こんにちは」という'ボディー:content「メッセージ/rfc822」:contains'テストが実行されるときテストされるものです。

   Comparisons are performed on octets.  Implementations decode the
   content-transfer-encoding and convert text to [UTF-8] as input to the
   comparator.  MIME parts that cannot be decoded and converted MAY be
   treated as plain US-ASCII, omitted, or processed according to local
   conventions.  A NUL octet (character zero) SHOULD NOT cause early
   termination of the content being compared against.  Implementations
   MUST support the "quoted-printable", "base64", "7bit", "8bit", and
   "binary" content transfer encodings.  Implementations MUST be capable
   of converting to UTF-8 the US-ASCII, ISO-8859-1, and the US-ASCII
   subset of ISO-8859-* character sets.

比較は八重奏に実行されます。 実現は、満足している転送コード化を解読して、比較器に入力されるように[UTF-8]にテキストを変換します。 地方のコンベンションによると、解読して、変換できないMIMEの部品は、明瞭な米国-ASCIIとして扱われるか、省略されるか、または加工処理されるかもしれません。 比較される内容のNUL八重奏(キャラクタゼロ)SHOULD NOT原因期限前契約解除。 実現は「引用されて印刷可能である」「base64"、「7ビット」、「8ビット」、および満足している「2進」の転送encodings」を支持しなければなりません。 実現は米国-ASCII、ISO-8859-1、およびISO8859*文字の組の米国-ASCII部分集合をUTF-8に変換できなければなりません。

   Each matched part is matched against independently: search
   expressions MUST NOT match across MIME part boundaries.  MIME headers
   of the containing part MUST NOT be included in the data.

それぞれの取り組んでいる部分は独自に合わせられています: 検索表現はMIME部分の限界の向こう側に合ってはいけません。 データに含有のヘッダーが分けるMIMEを含んではいけません。

Degener & Guenther          Standards Track                     [Page 6]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[6ページ]: ボディー拡大2008年4月

   Example:

例:

        require ["body", "fileinto"];

[「ボディー」、"fileinto"]を必要としてください。

        # Save any message with any text MIME part that contains the
        # words "missile" or "coordinates" in the "secrets" folder.

# 「秘密」フォルダーにあらゆる「ミサイル」という#言葉を含むテキストMIME部分や「座標」であらゆるメッセージを保存してください。

        if body :content "text" :contains ["missile", "coordinates"] {
                fileinto "secrets";
        }

:content「テキスト」:containsを具体化させてくださいなら[「ミサイル」は「調整される」]fileinto「秘密」。

        # Save any message with an audio/mp3 MIME part in
        # the "jukebox" folder.

# オーディオ/mp3MIME部分が#にあるあらゆるメッセージへ「ジュークボックス」フォルダーを取っておいてください。

        if body :content "audio/mp3" :contains "" {
                fileinto "jukebox";
        }

ボディー:contentである、「オーディオ/mp3":contains、「」」fileinto「ジュークボックス」。

5.3.  Body Transform ":text"

5.3. 「ボディーは」 : テキストを変えます」

   The ":text" body transform matches against the results of an
   implementation's best effort at extracting UTF-8 encoded text from a
   message.

「」 : 」 ボディーが変えるテキストは実現の結果に対してaからのコード化されたテキストが通信させるUTF-8を抽出するところでベストエフォート型であることで合っています。

   It is unspecified whether this transformation results in a single
   string or multiple strings being matched against.  All the text
   extracted from a given non-container MIME part MUST be in the same
   string.

この変化が一連か合わせられている多連をもたらすか否かに関係なく、それは不特定です。 与えられた非容器のMIME部分から抜粋されたすべてのテキストが同じストリングにあるに違いありません。

   In simple implementations, :text MAY be treated the same as :content
   "text".

簡単な実現では、:textは同じように:content「テキスト」として扱われるかもしれません。

   Sophisticated implementations MAY strip mark-up from the text prior
   to matching, and MAY convert media types other than text to text
   prior to matching.

洗練された実現は、マッチングの前にテキストから値上げを剥取って、マッチングの前にテキストへのテキスト以外のメディアタイプを変換するかもしれません。

   (For example, they may be able to convert proprietary text editor
   formats to text or apply optical character recognition algorithms to
   image data.)

(例えば、彼らは、独占テキストエディタ形式をテキストに変換するか、または光学文字認識アルゴリズムをイメージデータに適用できるかもしれません。)

   Example:
        require ["body", "fileinto"];

例: [「ボディー」、"fileinto"]を必要としてください。

        # Save messages mentioning the project schedule in the
        # project/schedule folder.
        if body :text :contains "project schedule" {
                fileinto "project/schedule";
        }

# #プロジェクト/スケジュールフォルダーでプロジェクト予定表について言及するメッセージを保存してください。ボディー:text:containsであるなら「スケジュールを映し出してください」fileinto「プロジェクト/スケジュール」。

Degener & Guenther          Standards Track                     [Page 7]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[7ページ]: ボディー拡大2008年4月

6.  Interaction with Other Sieve Extensions

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

   Any extension that extends the grammar for the COMPARATOR or MATCH-
   TYPE nonterminals will also affect the implementation of "body".

また、COMPARATORかMATCH- TYPE nonterminalsのために文法を広げるどんな拡大も「ボディー」の実現に影響するでしょう。

   Wildcard expressions used with "body" are exempt from the side
   effects described in [VARIABLES].  That is, they MUST NOT set match
   variables (${1}, ${2}...) to the input values corresponding to
   wildcard sequences in the matched pattern.  However, if the extension
   is present, variable references in the key strings or content type
   strings are evaluated as described in this document.

「ボディー」と共に使用されるワイルドカード表現は[VARIABLES]で説明された副作用によって免除されています。 すなわち、彼らはマッチ変数(1ドルと、2ドル)を取り組んでいるパターンのワイルドカード系列に対応する入力値に設定してはいけません。 しかしながら、拡大が存在しているなら、主要なストリングか満足しているタイプストリングにおける可変参照は本書では説明されるように評価されます。

7.  IANA Considerations

7. IANA問題

   The following template specifies the IANA registration of the 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: body
   Description:     Provides a test for matching against the
                    body of the message being processed
   RFC number:      RFC 5173
   Contact Address: The Sieve discussion list
                    <ietf-mta-filters@imc.org>

能力名: ボディー記述: 処理RFC番号であるメッセージ欄に対して合うためのテストを提供します: RFC5173はアドレスに連絡します: Sieve議論 list <ietf-mta-filters@imc.org 、gt。

8.  Security Considerations

8. セキュリティ問題

   The system MUST be sized and restricted in such a manner that even
   malicious use of body matching does not deny service to other users
   of the host system.

ボディーマッチングの悪意がある使用さえホストシステムの他のユーザに対するサービスを否定しないくらいの方法でシステムを大きさで分けられて、制限しなければなりません。

   Filters relying on string matches in the raw body of an email message
   may be more general than intended.  Text matches are no replacement
   for a spam, virus, or other security related filtering system.

メールメッセージの生のボディーでストリングマッチを当てにするフィルタは意図するより一般的であるかもしれません。 テキストマッチはシステムをフィルターにかけながら関係づけられたスパム、ウイルス、または他のセキュリティへの交換品ではありません。

9.  Acknowledgments

9. 承認

   This document has been revised in part based on comments and
   discussions that took place on and off the SIEVE mailing list.
   Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson,
   Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, Greg
   Shapiro, Tim Showalter, Nigel Swinson, Dowson Tong, and Christian
   Vogt for reviews and suggestions.

このドキュメントはコメントに基づいて一部改訂されました、そして、取った議論は時々SIEVEメーリングリストを置きます。 レビューと提案をサイラスDaboo、ネッド・フリード、ボブJohannessen、サイモンJosefsson、マーク・E.マレット、クリスMarkle、Alexeyメリニコフ、ケン・マーチソン、グレッグ・シャピロ、ティム・ショウォーター、ナイジェル・スウィンソン、ダウスンTong、およびクリスチャンのフォークトをありがとうございます。

Degener & Guenther          Standards Track                     [Page 8]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[8ページ]: ボディー拡大2008年4月

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

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

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

   [MIME]       Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, November 1996.

解放された[MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

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

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

   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日

10.2.  Informative References

10.2. 有益な参照

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

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

Authors' Addresses

作者のアドレス

   Jutta Degener
   5245 College Ave, Suite #127
   Oakland, CA 94618

ユッタDegener5245大学Ave、スイート#127オークランド、カリフォルニア 94618

   EMail: jutta@pobox.com

メール: jutta@pobox.com

   Philip Guenther
   Sendmail, Inc.
   6425 Christie Ave, 4th Floor
   Emeryville, CA 94608

クリスティAve、第4フィリップグンサーセンドメールInc.6425Floorエマリービル、カリフォルニア 94608

   EMail: guenther@sendmail.com

メール: guenther@sendmail.com

Degener & Guenther          Standards Track                     [Page 9]

RFC 5173         Sieve Email Filtering: Body Extension        April 2008

DegenerとグンサーStandardsはRFC5173ふるいのメールフィルタリングを追跡します[9ページ]: ボディー拡大2008年4月

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に情報を記述してください。

Degener & Guenther          Standards Track                    [Page 10]

Degenerとグンサー標準化過程[10ページ]