RFC5173 日本語訳
5173 Sieve Email Filtering: Body Extension. J. Degener, P. Guenther. April 2008. (Format: TXT=17429 bytes) (Updates RFC5229) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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ページ]
一覧
スポンサーリンク