RFC5228 日本語訳
5228 Sieve: An Email Filtering Language. P. Guenther, Ed., T.Showalter, Ed.. January 2008. (Format: TXT=87531 bytes) (Obsoletes RFC3028) (Updated by RFC5229) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Guenther, Ed. Request for Comments: 5228 Sendmail, Inc. Obsoletes: 3028 T. Showalter, Ed. Category: Standards Track January 2008
ワーキンググループのP.グンサー、エドをネットワークでつないでください。コメントのために以下を要求してください。 5228 センドメールInc.は以下を時代遅れにします。 3028 エドT.ショウォーター、カテゴリ: 標準化過程2008年1月
Sieve: An Email Filtering Language
ふるい: 言語をフィルターにかけるメール
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 a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.
このドキュメントは、最終的な配送の時にメールメッセージをフィルターにかけるために言語を説明します。 それは、メールクライアントかメールサーバのどちらかで実装可能になるように設計されています。広げることができて、簡単で、アクセス・プロトコル、メールアーキテクチャ、およびオペレーティングシステムから独立していることが意味されます。 それは基本言語にどんな変数、輪も、または能力もないときユーザが外部プログラムへの外でブラックボックスインターネットMessage Accessプロトコル(IMAP)サーバなどの任意のプログラムをシェルに実行できないかもしれないメールサーバで動くのに適当です。
Guenther & Showalter Standards Track [Page 1] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[1ページ]: 2008年1月に言語をフィルターにかけるメール
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Example Mail Messages ......................................5
2. Design ..........................................................6
2.1. Form of the Language .......................................6
2.2. Whitespace .................................................7
2.3. Comments ...................................................7
2.4. Literal Data ...............................................7
2.4.1. Numbers .............................................7
2.4.2. Strings .............................................8
2.4.2.1. String Lists ...............................9
2.4.2.2. Headers ....................................9
2.4.2.3. Addresses .................................10
2.4.2.4. Encoding Characters Using
"encoded-character" .......................10
2.5. Tests .....................................................11
2.5.1. Test Lists .........................................12
2.6. Arguments .................................................12
2.6.1. Positional Arguments ...............................12
2.6.2. Tagged Arguments ...................................12
2.6.3. Optional Arguments .................................13
2.6.4. Types of Arguments .................................13
2.7. String Comparison .........................................13
2.7.1. Match Type .........................................14
2.7.2. Comparisons across Character Sets ..................15
2.7.3. Comparators ........................................15
2.7.4. Comparisons against Addresses ......................16
2.8. Blocks ....................................................17
2.9. Commands ..................................................17
2.10. Evaluation ...............................................18
2.10.1. Action Interaction ................................18
2.10.2. Implicit Keep .....................................18
2.10.3. Message Uniqueness in a Mailbox ...................19
2.10.4. Limits on Numbers of Actions ......................19
2.10.5. Extensions and Optional Features ..................19
2.10.6. Errors ............................................20
2.10.7. Limits on Execution ...............................20
3. Control Commands ...............................................21
3.1. Control if ................................................21
3.2. Control require ...........................................22
3.3. Control stop ..............................................22
4. Action Commands ................................................23
4.1. Action fileinto ...........................................23
4.2. Action redirect ...........................................23
4.3. Action keep ...............................................24
4.4. Action discard ............................................25
1. 序論…4 1.1. このドキュメントで中古のコンベンション…4 1.2. 例のメール・メッセージ…5 2. デザイン…6 2.1. 言語のフォーム…6 2.2. 空白…7 2.3. コメント…7 2.4. 文字通りのデータ…7 2.4.1. 数…7 2.4.2. ストリング…8 2.4.2.1. リストを結んでください…9 2.4.2.2. ヘッダー…9 2.4.2.3. 扱います。10 2.4.2.4. 「コード化されたキャラクタ」を使用することでキャラクターをコード化します…10 2.5. テスト…11 2.5.1. テストは記載します…12 2.6. 議論…12 2.6.1. 位置の議論…12 2.6.2. 議論にタグ付けをします…12 2.6.3. 任意の議論…13 2.6.4. 議論のタイプ…13 2.7. 比較を結んでください…13 2.7.1. タイプを合わせてください…14 2.7.2. 文字コードの向こう側の比較…15 2.7.3. 比較器…15 2.7.4. アドレスに対する比較…16 2.8. ブロック…17 2.9. コマンド…17 2.10. 評価…18 2.10.1. 動作相互作用…18 2.10.2. 暗黙の生活費…18 2.10.3. メールボックスの中のメッセージのユニークさ…19 2.10.4. 動作の数における限界…19 2.10.5. 拡大と任意の特徴…19 2.10.6. 誤り…20 2.10.7. 実行における限界…20 3. コントロールは命令します…21 3.1. コントロール、…21 3.2. コントロール、必要です。22 3.3. 停止を制御してください…22 4. 動作は命令します…23 4.1. 動作fileinto…23 4.2. 動作再直接…23 4.3. 動作は保たれます…24 4.4. 動作破棄…25
Guenther & Showalter Standards Track [Page 2] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[2ページ]: 2008年1月に言語をフィルターにかけるメール
5. Test Commands ..................................................26
5.1. Test address ..............................................26
5.2. Test allof ................................................27
5.3. Test anyof ................................................27
5.4. Test envelope .............................................27
5.5. Test exists ...............................................28
5.6. Test false ................................................28
5.7. Test header ...............................................29
5.8. Test not ..................................................29
5.9. Test size .................................................29
5.10. Test true ................................................30
6. Extensibility ..................................................30
6.1. Capability String .........................................31
6.2. IANA Considerations .......................................31
6.2.1. Template for Capability Registrations ..............32
6.2.2. Handling of Existing Capability Registrations ......32
6.2.3. Initial Capability Registrations ...................32
6.3. Capability Transport ......................................33
7. Transmission ...................................................33
8. Parsing ........................................................34
8.1. Lexical Tokens ............................................34
8.2. Grammar ...................................................36
8.3. Statement Elements ........................................36
9. Extended Example ...............................................37
10. Security Considerations .......................................38
11. Acknowledgments ...............................................39
12. Normative References ..........................................39
13. Informative References ........................................40
14. Changes from RFC 3028 .........................................41
5. テストは命令します…26 5.1. アドレスをテストしてください…26 5.2. allofをテストしてください…27 5.3. anyofをテストしてください…27 5.4. 封筒を検査してください…27 5.5. テストは存在しています…28 5.6. 虚偽でテストしてください…28 5.7. ヘッダーをテストしてください…29 5.8. テスト、…29 5.9. サイズをテストしてください…29 5.10. 本当にテストしてください…30 6. 伸展性…30 6.1. 能力ストリング…31 6.2. IANA問題…31 6.2.1. 能力登録証明書のためのテンプレート…32 6.2.2. 既存の能力登録証明書の取り扱い…32 6.2.3. 能力登録証明書に頭文字をつけてください…32 6.3. 能力輸送…33 7. トランスミッション…33 8. 構文解析…34 8.1. 字句…34 8.2. 文法…36 8.3. 声明要素…36 9. 例を広げています…37 10. セキュリティ問題…38 11. 承認…39 12. 標準の参照…39 13. 有益な参照…40 14. RFC3028からの変化…41
Guenther & Showalter Standards Track [Page 3] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[3ページ]: 2008年1月に言語をフィルターにかけるメール
1. Introduction
1. 序論
This memo documents a language that can be used to create filters for electronic mail. It is not tied to any particular operating system or mail architecture. It requires the use of [IMAIL]-compliant messages, but should otherwise generalize to many systems.
このメモは電子メールのためにフィルタを作成するのに使用できる言語を記録します。 それはどんな特定のオペレーティングシステムやメールアーキテクチャにも結ばれません。 それは、[IMAIL]対応するメッセージの使用を必要としますが、そうでなければ、多くのシステムに総合されるべきです。
The language is powerful enough to be useful but limited in order to allow for a safe server-side filtering system. The intention is to make it impossible for users to do anything more complex (and dangerous) than write simple mail filters, along with facilitating the use of graphical user interfaces (GUIs) for filter creation and manipulation. The base language was not designed to be Turing- complete: it does not have a loop control structure or functions.
言語は安全なサーバサイドフィルタリング・システムを考慮するために役に立つ、しかし、制限されているほど強力です。 意志は簡単なメールフィルタを書くよりユーザが、より複雑で何でも(危険)であることをするのを不可能にすることです、グラフィカルユーザーインターフェース(GUIs)のフィルタ作成と操作の使用を容易にすると共に。 基本言語はチューリング完全になるように設計されませんでした: それには、ループ制御構造か機能がありません。
Scripts written in Sieve are executed during final delivery, when the message is moved to the user-accessible mailbox. In systems where the Mail Transfer Agent (MTA) does final delivery, such as traditional Unix mail, it is reasonable to filter when the MTA deposits mail into the user's mailbox.
メッセージがユーザアクセスしやすいメールボックスに動かされるとき、Sieveに書かれたスクリプトは最終的な配送の間、作成されます。 MTAがユーザのメールボックスの中にメールを預けるとき、メール配達エージェント(MTA)が伝統的なUnixメールなどの最終的な配送をするシステムでは、それはフィルターにかけるのが妥当です。
There are a number of reasons to use a filtering system. Mail traffic for most users has been increasing due to increased usage of email, the emergence of unsolicited email as a form of advertising, and increased usage of mailing lists.
フィルタリング・システムを使用する多くの理由があります。 ほとんどのユーザのための郵便運送は、メールの増強された用法のため増加する広告のフォームとしての求められていないメールの出現であり、メーリングリストの用法を増強しました。
Experience at Carnegie Mellon has shown that if a filtering system is made available to users, many will make use of it in order to file messages from specific users or mailing lists. However, many others did not make use of the Andrew system's FLAMES filtering language [FLAMES] due to difficulty in setting it up.
カーネギー・メロンでの経験は、フィルタリング・システムをユーザにとって利用可能にすると、多くが特定のユーザかメーリングリストからメッセージをファイルするのにそれを利用するのを示しました。 しかしながら、多くの他のものはそれをセットアップすることにおける苦労のため、言語[フレームズ]をフィルターにかけるアンドリューシステムのフレームズを利用しませんでした。
Because of the expectation that users will make use of filtering if it is offered and easy to use, this language has been made simple enough to allow many users to make use of it, but rich enough that it can be used productively. However, it is expected that GUI-based editors will be the preferred way of editing filters for a large number of users.
ユーザが提供していて使用するのが簡単であるならフィルタリングの使用をする期待のために、この言語を多くのユーザがそれを利用するのを許容するほど簡単ですが、それを生産的に使用できるくらい豊かにしました。 しかしながら、GUIベースのエディタが多くのユーザのためにフィルタを編集する都合のよい方法になると予想されます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
In the sections of this document that discuss the requirements of various keywords and operators, the following conventions have been adopted.
様々なキーワードとオペレータの要件について論ずるこのドキュメントのセクションでは、以下のコンベンションは採用されました。
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は[キーワード]で説明されるように本書では解釈されることであるべきですか?
Guenther & Showalter Standards Track [Page 4] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[4ページ]: 2008年1月に言語をフィルターにかけるメール
Each section on a command (test, action, or control) has a line
labeled "Usage:". This line describes the usage of the command,
including its name and its arguments. Required arguments are listed
inside angle brackets ("<" and ">"). Optional arguments are listed
inside square brackets ("[" and "]"). Each argument is followed by
its type, so "<key: string>" represents an argument called "key" that
is a string. Literal strings are represented with double-quoted
strings. Alternatives are separated with slashes, and parentheses
are used for grouping, similar to [ABNF].
コマンド(テスト、動作、またはコントロール)の各セクションが系列をラベルさせる、「用法:」 この系列は名前とその議論を含むコマンドの用法を説明します。 必要な議論は角ブラケット("<"と">")の中に記載されています。 そして、任意の議論が角括弧で記載されている、(「[「」、]、」、) 各議論はタイプによって後をつけられていて、そうは「<は以下を合わせます」です。 「ストリング>」は「主要である」と呼ばれるストリングである議論を表します。 文字通りのストリングは二重引用文字列で表されます。 括弧は、代替手段がスラッシュで切り離されて、組分けに中古であって、[ABNF]と同様です。
In the "Usage:" line, there are three special pieces of syntax that are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, respectively.
中、「用法:」 立ち並んでください、そして、繰り返されて、頻繁にそうである構文の3つの特別な断片、MATCH-TYPE、COMPARATOR、およびADDRESS-PARTがあります。 議論されたコネセクション2.7.1、2.7は、.3と、2.7です。これら、それぞれ.4。
The formal grammar for these commands is defined in section 8 and is the authoritative reference on how to construct commands, but the formal grammar does not specify the order, semantics, number or types of arguments to commands, or the legal command names. The intent is to allow for extension without changing the grammar.
これらのコマンドのための形式文法は、セクション8で定義されて、どうコマンドを構成するかに関する正式の参照ですが、形式文法は議論のオーダー、意味論、数またはタイプをコマンド、または法的なコマンド名に指定しません。 意図は文法を変えないで拡大を考慮することです。
1.2. Example Mail Messages
1.2. 例のメール・メッセージ
The following mail messages will be used throughout this document in examples.
以下のメール・メッセージは例のこのドキュメント中で使用されるでしょう。
Message A ----------------------------------------------------------- Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST) From: coyote@desert.example.org To: roadrunner@acme.example.com Subject: I have a present for you
メッセージA----------------------------------------------------------- 日付: 火曜日、1997年4月1日09:06:31 -0800(太平洋標準時の)のFrom: coyote@desert.example.org To: roadrunner@acme.example.com Subject: あなたにプレゼントがあります
Look, I'm sorry about the whole anvil thing, and I really didn't mean to try and drop it on you from the top of the cliff. I want to try to make it up to you. I've got some great birdseed over here at my place--top of the line stuff--and if you come by, I'll have it all wrapped up for you. I'm really sorry for all the problems I've caused for you over the years, but I know we can work this out. -- Wile E. Coyote "Super Genius" coyote@desert.example.org -----------------------------------------------------------
ほら、全体の金床ものをお詫びします、私はあなたでがけの頂上からそれを下げてみるのを本当に意図しませんでした。 それをあなたまで作ろうとしたいと思います。 私はここ、場所(系列ものの先端)でいくらかのすばらしい粒餌を乗り切りました、そして、あなたがやって来るなら、あなたのためにそれのすべてを包ませるつもりです。 私は本当にあなたのために数年間引き起こしているすべての問題に残念ですが、私たちがこれを解決できるのを知っています。 -- ワイリーコヨーテ「最高の天才」 coyote@desert.example.org -----------------------------------------------------------
Guenther & Showalter Standards Track [Page 5] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[5ページ]: 2008年1月に言語をフィルターにかけるメール
Message B ----------------------------------------------------------- From: youcouldberich!@reply-by-postal-mail.invalid Sender: b1ff@de.res.example.com To: rube@landru.example.com Date: Mon, 31 Mar 1997 18:26:10 -0800 Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
メッセージB----------------------------------------------------------- From: youcouldberich!@reply-by-postal-mail.invalid 送付者: b1ff@de.res.example.com To: rube@landru.example.com 日付: 月曜日、1997年3月31日の18:26:10 -0800Subject: $$$、また、あなたは大金持ちであるかもしれません! $$$
YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY! MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER $20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!! !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW! -----------------------------------------------------------
あなたは既に1000万ドルを勝ち取ったかもしれませんが、私はそれを疑います! それで、ちょっと600のニュースグループにこれを掲示してください! それは、あなたがお金で少なくとも5つの応答を得るのを保証するでしょう! お金! お金! 現金! あなたは2カ月で2万ドルの上で受信するでしょう! そして、ITは法的です! !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 ちょっと小さくて、無印の請求書を以下のアドレスに5ドル送ってください! -----------------------------------------------------------
2. Design
2. デザイン
2.1. Form of the Language
2.1. 言語のフォーム
The language consists of a set of commands. Each command consists of a set of tokens delimited by whitespace. The command identifier is the first token and it is followed by zero or more argument tokens. Arguments may be literal data, tags, blocks of commands, or test commands.
言語は1セットのコマンドから成ります。 各コマンドは空白によって区切られた1セットのトークンから成ります。 コマンド識別子は最初のトークンです、そして、ゼロか、より多くの議論トークンがそれのあとに続いています。 議論は、文字通りのデータ、タグ、ブロックのコマンド、またはテスト命令であるかもしれません。
With the exceptions of strings and comments, the language is limited to US-ASCII characters. Strings and comments may contain octets outside the US-ASCII range. Specifically, they will normally be in UTF-8, as specified in [UTF-8]. NUL (US-ASCII 0) is never permitted in scripts, while CR and LF can only appear as the CRLF line ending.
ストリングとコメントの例外で、言語は米国-ASCII文字に制限されます。 ストリングとコメントは米国-ASCII範囲の外に八重奏を保管するかもしれません。 明確に、通常、彼らは[UTF-8]で指定されるようにUTF-8にいるでしょう。 NUL(米国-ASCII0)はスクリプトで決して受入れられませんが、CRとLFはCRLF系列結末として現れることができるだけです。
Note: While this specification permits arbitrary octets to appear
in Sieve scripts inside strings and comments, this has made it
difficult to robustly handle Sieve scripts in programs that are
sensitive to the encodings used. The "encoded-character"
capability (section 2.4.2.4) provides an alternative means of
representing such octets in strings using just US-ASCII
characters. As such, the use of non-UTF-8 text in scripts should
be considered a deprecated feature that may be abandoned.
以下に注意してください。 この仕様は、任意の八重奏がストリングとコメントにSieveスクリプトで現れることを許可しますが、これで、使用されるencodingsに機密のプログラムでSieveスクリプトを強壮に扱うのは難しくなりました。 「コード化されたキャラクタ」能力、(セクション2.4 .2 .4は、)まさしく米国-ASCII文字を使用することでそのような八重奏を表す代替の手段をストリングに供給します。 そういうものとして、スクリプトにおける非UTF-8テキストの使用は捨てられるかもしれない推奨しない特徴であると考えられるべきです。
Tokens other than strings are considered case-insensitive.
ストリング以外のトークンは大文字と小文字を区別しないと考えられます。
Guenther & Showalter Standards Track [Page 6] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[6ページ]: 2008年1月に言語をフィルターにかけるメール
2.2. Whitespace
2.2. 空白
Whitespace is used to separate tokens. Whitespace is made up of tabs, newlines (CRLF, never just CR or LF), and the space character. The amount of whitespace used is not significant.
空白は、トークンを切り離すのに使用されます。 空白はタブ、ニューライン(CRLF、CRまたは決してLFであるだけではない)、および間隔文字で作られます。 使用される空白の量はかなりではありません。
2.3. Comments
2.3. コメント
Two types of comments are offered. Comments are semantically equivalent to whitespace and can be used anyplace that whitespace is (with one exception in multi-line strings, as described in the grammar).
2つのタイプのコメントを提供します。 コメントは、空白に意味的に同等であり、どこへでも使用されて、その空白があるということであるかもしれません(ただ1つを例外としてマルチ系列ストリング文法で説明されるように)。
Hash comments begin with a "#" character that is not contained within a string and continue until the next CRLF.
ハッシュコメントは、ストリングの中に含まれていない「#」キャラクタと共に始まって、次のCRLFまで続きます。
Example: if size :over 100k { # this is a comment
discard;
}
例: サイズ:over100kです。#これはコメント破棄です。
Bracketed comments begin with the token "/*" and end with "*/" outside of a string. Bracketed comments may span multiple lines. Bracketed comments do not nest.
「腕木を付けられたコメントはトークンで」 /*を始め」て」 ストリングにおける外の*/がある終わり。 腕木を付けられたコメントは複数の系列にかかるかもしれません。 腕木を付けられたコメントはどんな巣もしません。
Example: if size :over 100K { /* this is a comment
this is still a comment */ discard /* this is a comment
*/ ;
}
例: 100Kのサイズ:overです。/、*これはそれでも、コメント*/であるコメント*/破棄/*であるというaコメントです。
2.4. Literal Data
2.4. 文字通りのデータ
Literal data means data that is not executed, merely evaluated "as is", to be used as arguments to commands. Literal data is limited to numbers, strings, and string lists.
文字通りのデータは、実行されない単に「そのままで」評価のデータが議論としてコマンドに使用されることを意味します。 文字通りのデータは数、ストリング、およびストリングリストに制限されます。
2.4.1. Numbers
2.4.1. 数
Numbers are given as ordinary decimal numbers. As a shorthand for expressing larger values, such as message sizes, a suffix of "K", "M", or "G" MAY be appended to indicate a multiple of a power of two. To be comparable with the power-of-two-based versions of SI units that computers frequently use, "K" specifies kibi-, or 1,024 (2^10) times the value of the number; "M" specifies mebi-, or 1,048,576 (2^20) times the value of the number; and "G" specifies gibi-, or 1,073,741,824 (2^30) times the value of the number [BINARY-SI].
普通の10進数として数を与えます。 メッセージサイズなどの、より大きい値を言い表すための速記として、2のパワーの倍数を示すために「K」、「M」、または「G」の接尾語を追加するかもしれません。 コンピュータが頻繁に使用するSI単位系の2ベースのパワーバージョンに匹敵しているために、「K」は数の値のkibi倍か1,024(2^10)倍を指定します。 「M」は数の値のmebi倍か104万8576(2^20)倍を指定します。 そして、「G」は数[2進のSIの]の値のgibi倍か10億7374万1824(2^30)倍を指定します。
Guenther & Showalter Standards Track [Page 7] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[7ページ]: 2008年1月に言語をフィルターにかけるメール
Implementations MUST support integer values in the inclusive range zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
実装は、包括的な範囲でゼロ〜21億4748万3647(2^31--1)に整数値をサポートしなければなりませんが、より大きい値をサポートするかもしれません。
Only non-negative integers are permitted by this specification.
非負の整数だけがこの仕様で受入れられます。
2.4.2. Strings
2.4.2. ストリング
Scripts involve large numbers of string values as they are used for pattern matching, addresses, textual bodies, etc. Typically, short quoted strings suffice for most uses, but a more convenient form is provided for longer strings such as bodies of messages.
それらがパターン・マッチング、アドレス、原文のボディーなどに使用されるとき、スクリプトは多くのストリング値を伴います。 短い引用文字列はほとんどの用途に通常、十分ですが、メッセージのボディーなどの、より長いストリングにより便利なフォームを提供します。
A quoted string starts and ends with a single double quote (the <">
character, US-ASCII 34). A backslash ("\", US-ASCII 92) inside of a
quoted string is followed by either another backslash or a double
quote. These two-character sequences represent a single backslash or
double quote within the value, respectively.
引用文字列は、ただ一つの二重引用文で始まって、終わります。(<「>キャラクタの、そして、米国のASCIIの34)」。 別のバックスラッシュか二重引用文のどちらかが引用文字列のバックスラッシュ(「\」、米国-ASCII92)内部のあとに続いています。 これらの2キャラクタシーケンスが値の中にそれぞれただ一つのバックスラッシュか二重引用文を表します。
Scripts SHOULD NOT escape other characters with a backslash.
バックスラッシュでSHOULD NOTエスケープ他のキャラクタに原稿を書きます。
An undefined escape sequence (such as "\a" in a context where "a" has no special meaning) is interpreted as if there were no backslash (in this case, "\a" is just "a"), though that may be changed by extensions.
「まるでバックスラッシュが全くないかのように未定義のエスケープシーケンス(」 “a"がどんな特別な意味も持っていない文脈の\a」などの)が解釈される、(この場合」、\a」がただ“a"である、)、拡大でそれを変えるかもしれませんが。
Non-printing characters such as tabs, CRLF, and control characters are permitted in quoted strings. Quoted strings MAY span multiple lines. An unencoded NUL (US-ASCII 0) is not allowed in strings; see section 2.4.2.4 for how it can be encoded.
タブや、CRLFや、制御文字などの非表示文字は引用文字列で受入れられます。 引用文字列は複数の系列にかかるかもしれません。 暗号化されていないNUL(米国-ASCII0)はストリングに許容されていません。 セクション2.4を見てください。.2 .4 どうそれをコード化できるように。
As message header data is converted to [UTF-8] for comparison (see section 2.7.2), most string values will use the UTF-8 encoding. However, implementations MUST accept all strings that match the grammar in section 8. The ability to use non-UTF-8 encoded strings matches existing practice and has proven to be useful both in tests for invalid data and in arguments containing raw MIME parts for extension actions that generate outgoing messages.
メッセージヘッダー・データが比較のために変えられるとき[UTF-8](セクション2.7.2を見てください)、ほとんどのストリング値がUTF-8コード化を使用するでしょう。 しかしながら、実装はセクション8で文法に合っているすべてのストリングを受け入れなければなりません。 非UTF-8のコード化されたストリングを使用する能力は、既存の習慣を合わせて、無効のデータのためのテストと生のMIMEの部品を含む議論で送信されるメッセージを生成する拡大動作の役に立つと判明しました。
For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. The CRLF before the final period is considered part of the value. In order to allow the message to contain lines with a single dot, lines are dot-stuffed. That is, when composing a message body, an extra '.' is added before each line that begins with a '.'. When the server interprets the script, these extra dots are removed. Note that a line that begins with a dot followed by a non-dot character is not interpreted as dot-stuffed;
メールメッセージなどの多く以上の量のテキストに入るのにおいて、マルチ系列フォームは許容されています。 それはキーワードから「テキスト:」 ただ一つの期間、および別のCRLFをCRLFの系列でCRLF、および終わりで続かれて、始動します。 ファイナルピリオドの前のCRLFは価値の一部であると考えられます。 ただ一つのドットがある系列を含むメッセージを許容するために、系列はドットによって詰められます。 'いつがメッセージ本体、エキストラを構成して、それはいます'。. 'aで始まる各系列の前に加えられる'、' サーバがスクリプトを解釈すると、これらの付加的なドットを取り除きます。 ドットが非ドットキャラクタによって従われている状態で始まる系列がドットによって詰められるのは解釈されないことに注意してください。
Guenther & Showalter Standards Track [Page 8] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[8ページ]: 2008年1月に言語をフィルターにかけるメール
that is, ".foo" is interpreted as ".foo". However, because this is potentially ambiguous, scripts SHOULD be properly dot-stuffed so such lines do not appear.
すなわち、".foo"は".foo"として解釈されます。 しかしながら、これが潜在的にあいまいであるのでスクリプトSHOULDがドットによって適切に詰められるので、そのような系列は現れません。
Note that a hashed comment or whitespace may occur in between the "text:" and the CRLF, but not within the string itself. Bracketed comments are not allowed here.
論じ尽くされたコメントか空白が中間で起こるかもしれないことに注意してください、「テキスト:」 CRLF、ストリング自体でない 腕木を付けられたコメントはここに許容されていません。
2.4.2.1. String Lists
2.4.2.1. ストリングリスト
When matching patterns, it is frequently convenient to match against groups of strings instead of single strings. For this reason, a list of strings is allowed in many tests, implying that if the test is true using any one of the strings, then the test is true.
パターンを合わせるとき、一連の代わりにストリングのグループに対して合っているのは頻繁に便利です。 この理由で、ストリングのリストは多くのテストで許容されています、テストがストリングに関していくらか1つを使用することで本当であるならテストが本当であることを含意して。
For instance, the test 'header :contains ["To", "Cc"] ["me@example.com", "me00@landru.example.com"]' is true if either a To header or Cc header of the input message contains either of the email addresses "me@example.com" or "me00@landru.example.com".
例えば、ヘッダーへのaか入力メッセージのccヘッダーのどちらかがEメールアドレス" me@example.com "か" me00@landru.example.com "のどちらかを含んでいるなら、テスト'ヘッダー:contains[“To"、「cc」][" me@example.com "、" me00@landru.example.com "]'は本当です。
Conversely, in any case where a list of strings is appropriate, a single string is allowed without being a member of a list: it is equivalent to a list with a single member. This means that the test 'exists "To"' is equivalent to the test 'exists ["To"]'.
逆に、ストリングのリストが適切であるどんな場合でも、一連はリストのメンバーであるのなしで許容されています: 独身のメンバーにとって、それはリストに同等です。 これがそれを意味する、テスト、'、存在、“To"'によるテストと同等物が'存在[“To"]であっている'ということである、'
2.4.2.2. Headers
2.4.2.2. ヘッダー
Headers are a subset of strings. In the Internet Message Specification [IMAIL], each header line is allowed to have whitespace nearly anywhere in the line, including after the field name and before the subsequent colon. Extra spaces between the header name and the ":" in a header field are ignored.
ヘッダーはストリングの部分集合です。 インターネットMessage Specification[IMAIL]では、それぞれのヘッダー系列は系列、フィールド名の後とその後のコロンの前の包含でどこでも空白をほとんど持つことができます。 そして、「ヘッダーの間の付加的な空間が命名する、」、:、」 ヘッダーフィールドでは、無視されます。
A header name never contains a colon. The "From" header refers to a line beginning "From:" (or "From :", etc.). No header will match the string "From:" due to the trailing colon.
ヘッダー名はコロンを決して含んでいません。 “From"ヘッダーは「From:」を始める系列について言及します。 (または、「以下」など。) どんなヘッダーもストリング「From:」に合わないでしょう。 引きずっているコロンのため。
Similarly, no header will match a syntactically invalid header name. An implementation MUST NOT cause an error for syntactically invalid header names in tests.
同様に、どんなヘッダーもシンタクス上無効のヘッダー名に合わないでしょう。 実装はテストにおけるシンタクス上無効のヘッダー名のための誤りを引き起こしてはいけません。
Header lines are unfolded as described in [IMAIL] section 2.2.3. Interpretation of header data SHOULD be done according to [MIME3] section 6.2 (see section 2.7.2 below for details).
ヘッダー系列は[IMAIL]セクション2.2.3で説明されるように繰り広げられます。 解釈、ヘッダー・データSHOULDでは、[MIME3]セクション6.2に従って、してください(詳細に関してセクション2.7.2未満を見てください)。
Guenther & Showalter Standards Track [Page 9] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[9ページ]: 2008年1月に言語をフィルターにかけるメール
2.4.2.3. Addresses
2.4.2.3. アドレス
A number of commands call for email addresses, which are also a subset of strings. When these addresses are used in outbound contexts, addresses must be compliant with [IMAIL], but are further constrained within this document. Using the symbols defined in [IMAIL], section 3, the syntax of an address is:
多くのコマンドがEメールアドレスを求めます。(また、Eメールアドレスはストリングの部分集合です)。 これらのアドレスが外国行きの文脈で使用されるとき、アドレスは、[IMAIL]と共に言いなりにならなければなりませんが、このドキュメントの中にさらに抑制されます。 [IMAIL]、セクション3で定義されたシンボルを使用して、アドレスの構文は以下の通りです。
sieve-address = addr-spec ; simple address
/ phrase "<" addr-spec ">" ; name & addr-spec
ふるいアドレスはaddr-仕様と等しいです。 簡単なアドレス/句の"<"addr-仕様">"。 名前とaddr-仕様
That is, routes and group syntax are not permitted. If multiple addresses are required, use a string list. Named groups are not permitted.
すなわち、ルートとグループ構文は受入れられません。 複数のアドレスが必要であるなら、ストリングリストを使用してください。 命名されたグループは受入れられません。
It is an error for a script to execute an action with a value for use as an outbound address that doesn't match the "sieve-address" syntax.
「ふるいアドレス」構文を合わせないのは、スクリプトが使用のために外国行きのアドレスとして値で動作を実行する誤りです。
2.4.2.4. Encoding Characters Using "encoded-character"
2.4.2.4. 「コード化されたキャラクタ」を使用することでキャラクターをコード化します。
When the "encoded-character" extension is in effect, certain character sequences in strings are replaced by their decoded value. This happens after escape sequences are interpreted and dot- unstuffing has been done. Implementations SHOULD support "encoded- character".
「コード化されたキャラクタ」拡大が有効であるときに、ストリングのあるキャラクタシーケンスをそれらの解読された値に取り替えます。 エスケープシーケンスを解釈して、ドット「非-物質」をした後にこれは起こります。 実装SHOULDサポートは「キャラクタをコード化しました」。
Arbitrary octets can be embedded in strings by using the syntax encoded-arb-octets. The sequence is replaced by the octets with the hexadecimal values given by each hex-pair.
構文のコード化されたarb八重奏を使用することによって、任意の八重奏をストリングに埋め込むことができます。 16進値がそれぞれの十六進法組によって与えられている状態で、系列を八重奏に取り替えます。
blank = WSP / CRLF
encoded-arb-octets = "${hex:" hex-pair-seq "}"
hex-pair-seq = *blank hex-pair *(1*blank hex-pair) *blank
hex-pair = 1*2HEXDIG
「空白の=WSP / CRLFコード化されたarb八重奏=」$、十六進法: 」 十六進法組seq、」、」 十六進法組seqは*空白の十六進法組*(空白の1*十六進法組)*空白の十六進法組=1*2HEXDIGと等しいです。
Where WSP and HEXDIG non-terminals are defined in Appendix B.1 of [ABNF].
WSPとHEXDIG非端末が[ABNF]のAppendix B.1で定義されるところ。
It may be inconvenient or undesirable to enter Unicode characters verbatim, and for these cases the syntax encoded-unicode-char can be used. The sequence is replaced by the UTF-8 encoding of the specified Unicode characters, which are identified by the hexadecimal value of unicode-hex.
ユニコード文字に逐語的に入るのが不便であるか、または望ましくないかもしれなく、これらのケースに、構文のコード化されたユニコード炭は使用できます。 系列を指定されたユニコード文字のUTF-8コード化に取り替えます。(ユニコード文字は、ユニコード十六進法の16進値によって特定されます)。
encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = *blank unicode-hex
*(1*blank unicode-hex) *blank
unicode-hex = 1*HEXDIG
「コード化されたユニコード炭の=」$、ユニコード: 」 ユニコード十六進法seq、」、」 ユニコード十六進法seqは*空白のユニコード十六進法*(1つの*空白のユニコード十六進法)*空白のユニコード十六進法=1*HEXDIGと等しいです。
Guenther & Showalter Standards Track [Page 10] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[10ページ]: 2008年1月に言語をフィルターにかけるメール
It is an error for a script to use a hexadecimal value that isn't in either the range 0 to D7FF or the range E000 to 10FFFF. (The range D800 to DFFF is excluded as those character numbers are only used as part of the UTF-16 encoding form and are not applicable to the UTF-8 encoding that the syntax here represents.)
10FFFFにはD7FFへの範囲0か範囲のどちらかに000Eないのは、スクリプトが16進値を使用する誤りです。 (それらのキャラクタ番号がフォームをコード化するUTF-16の一部として使用されるだけであり、ここの構文が表すUTF-8コード化に適切でないときに、DFFFへの範囲D800は除かれます。)
Note: Implementations MUST NOT raise an error for an out-of-range
Unicode value unless the sequence containing it is well-formed
according to the grammar.
以下に注意してください。 文法によると、それを含む系列が整形式でないなら、実装は範囲で出ているユニコード値のための誤りを上げてはいけません。
The capability string for use with the require command is "encoded- character".
必要コマンドによる使用のための能力ストリングは「コード化されたキャラクタ」です。
In the following script, message B is discarded, since the specified test string is equivalent to "$$$".
「以下のスクリプトで、指定されたテストストリングが」 $$$に同等であるので、メッセージBは捨てられます。」
Example: require "encoded-character";
if header :contains "Subject" "$${hex:24 24}" {
discard;
}
The following examples demonstrate valid and invalid encodings and
how they are handled:
例: 「コード化されたキャラクタ」を必要としてください。 「ヘッダー:contains「対象」であるなら、」 $$は: 24 24人に魔法をかけます」。破棄; 以下の例は有効で無効のencodingsとそれらがどう扱われるかのデモをします:
"$${hex:40}" -> "$@"
"${hex: 40 }" -> "@"
"${HEX: 40}" -> "@"
"${hex:40" -> "${hex:40"
"${hex:400}" -> "${hex:400}"
"${hex:4${hex:30}}" -> "${hex:40}"
"${unicode:40}" -> "@"
"${ unicode:40}" -> "${ unicode:40}"
"${UNICODE:40}" -> "@"
"${UnICoDE:0000040}" -> "@"
"${Unicode:40}" -> "@"
"${Unicode:Cool}" -> "${Unicode:Cool}"
"${unicode:200000}" -> error
"${Unicode:DF01} -> error
"$${hex:40}" -> "$@" "${hex: 40 }" -> "@" "${HEX: 40}" -> "@" "${hex:40" -> "${hex:40" "${hex:400}" -> "${hex:400}" "${hex:4${hex:30}}" -> "${hex:40}" "${unicode:40}" -> "@" "${ unicode:40}" -> "${ unicode:40}" "${UNICODE:40}" -> "@" "${UnICoDE:0000040}" -> "@" "${Unicode:40}" -> "@" "${Unicode:Cool}" -> "${Unicode:Cool}" "${unicode:200000}" -> error "${Unicode:DF01} -> error
2.5. Tests
2.5. テスト
Tests are given as arguments to commands in order to control their actions. In this document, tests are given to if/elsif to decide which block of code is run.
彼らの動作を制御するために議論としてテストをコマンドに与えます。 本書では、コードのどのブロックについて決めるか/elsifを実行するなら、テストを与えます。
Guenther & Showalter Standards Track [Page 11] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[11ページ]: 2008年1月に言語をフィルターにかけるメール
2.5.1. Test Lists
2.5.1. テストリスト
Some tests ("allof" and "anyof", which implement logical "and" and
logical "or", respectively) may require more than a single test as an
argument. The test-list syntax element provides a way of grouping
tests as a comma-separated list in parentheses.
いくつかのテスト(それぞれ論理的な“and"と論理的な“or"を実装する"allof"と"anyof")が議論としてただ一つのテスト以上を必要とするかもしれません。 試リスト構文要素は括弧のコンマで切り離されたリストとしてテストを分類する方法を提供します。
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.com") {
discard;
}
例: anyofである、(存在していない、[“From"、「日付」]ヘッダー:contains“from"" fool@example.com ")破棄。
2.6. Arguments
2.6. 議論
In order to specify what to do, most commands take arguments. There are three types of arguments: positional, tagged, and optional.
何をしたらよいかを指定するために、ほとんどのコマンドが議論を取ります。 3つのタイプの議論があります: 位置であって、タグ付けされて、任意です。
It is an error for a script, on a single command, to use conflicting arguments or to use a tagged or optional argument more than once.
それはただ一つのコマンドに関するスクリプト闘争議論を使用するか、またはタグ付けをされたか任意の議論に一度以上を使用する誤りです。
2.6.1. Positional Arguments
2.6.1. 位置の議論
Positional arguments are given to a command that discerns their meaning based on their order. When a command takes positional arguments, all positional arguments must be supplied and must be in the order prescribed.
彼らのオーダーに基づくそれらの意味について明察するコマンドに位置の議論を与えます。 コマンドが位置の議論を取るとき、すべての位置の議論は、供給しなければならなくて、定められた順序に従って供給するに違いありません。
2.6.2. Tagged Arguments
2.6.2. タグ付けをされた議論
This document provides for tagged arguments in the style of CommonLISP. These are also similar to flags given to commands in most command-line systems.
このドキュメントはCommonLISPのスタイルでタグ付けをされた議論に備えます。 また、これらもほとんどのコマンドラインシステムにおけるコマンドに与えられた旗と同様です。
A tagged argument is an argument for a command that begins with ":" followed by a tag naming the argument, such as ":contains". This argument means that zero or more of the next tokens have some particular meaning depending on the argument. These next tokens may be literal data, but they are never blocks.
「タグ付けをされた議論はそれが始まるコマンドのための議論です」:、」 「議論と、そのようなものを命名するタグは支えている」:、含有、」 この議論は、次のトークンのゼロか以上には議論による何らかの特定の意味があることを意味します。 これらの次のトークンは文字通りのデータであるかもしれませんが、それらは決してブロックではありません。
Tagged arguments are similar to positional arguments, except that instead of the meaning being derived from the command, it is derived from the tag.
タグ付けをされた議論は位置の議論と同様です、コマンドから得られる意味の代わりにタグからそれを得るのを除いて。
Tagged arguments must appear before positional arguments, but they may appear in any order with other tagged arguments. For simplicity of the specification, this is not expressed in the syntax definitions
タグ付けをされた議論は位置の議論の前に現れなければなりませんが、それらは他のタグ付けをされた議論と共に順不同に現れるかもしれません。 仕様の簡単さにおいて、これは構文定義で表現されません。
Guenther & Showalter Standards Track [Page 12] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[12ページ]: 2008年1月に言語をフィルターにかけるメール
with commands, but they still may be reordered arbitrarily provided they appear before positional arguments. Tagged arguments may be mixed with optional arguments.
コマンドで、位置の議論の前に現れるなら、まだ任意にそれらだけを再命令していてもよいです。 タグ付けをされた議論は任意の議論に混ぜられるかもしれません。
Tagged arguments SHOULD NOT take tagged arguments as arguments.
タグ付けをされた議論SHOULD NOTは議論としてタグ付けをされた議論をみなします。
2.6.3. Optional Arguments
2.6.3. 任意の議論
Optional arguments are exactly like tagged arguments except that they may be left out, in which case a default value is implied. Because optional arguments tend to result in shorter scripts, they have been used far more than tagged arguments.
それらが省かれるかもしれないのを除いて、任意の議論はちょうどタグ付けをされた議論に似ています、その場合、デフォルト値が含意されます。 任意の議論が、より短いスクリプトをもたらす傾向があるので、それらはタグ付けをされた議論よりはるかにさらに使用されています。
One particularly noteworthy case is the ":comparator" argument, which allows the user to specify which comparator [COLLATION] will be used to compare two strings, since different languages may impose different orderings on UTF-8 [UTF-8] strings.
「1つの特に注目に値するケースがそう、」 : 異なった言語が課すかもしれないので、」 ユーザがその比較器[COLLATION]を指定できる議論がそうする比較器が2個のストリングを比較するのに使用されて、UTF-8[UTF-8]ストリングに異なった受注業務を課してください。
2.6.4. Types of Arguments
2.6.4. 議論のタイプ
Abstractly, arguments may be literal data, tests, or blocks of commands. In this way, an "if" control structure is merely a command that happens to take a test and a block as arguments and may execute the block of code.
抽象的に、議論は文字通りのデータ、テスト、またはブロックのコマンドであるかもしれません。 このように、“if"制御構造は単に議論としてたまたまテストとブロック取って、コードのブロックを実行するかもしれないコマンドです。
However, this abstraction is ambiguous from a parsing standpoint.
しかしながら、この抽象化は構文解析見地からあいまいです。
The grammar in section 8.2 presents a parsable version of this: Arguments are string lists (string-lists), numbers, and tags, which may be followed by a test or a test list (test-list), which may be followed by a block of commands. No more than one test or test list, or more than one block of commands, may be used, and commands that end with a block of commands do not end with semicolons.
セクション8.2の文法はこの「パー-可能」バージョンを提示します: 議論は、1ブロックのコマンドがあとに続くかもしれないテストかテストリスト(試しに記載する)がいうことになるかもしれないストリングリスト(ストリングリスト)と、数と、タグです。 1つ未満のテスト、テストリスト、または1ブロック以上のコマンド、使用されるかもしれなくて、その終わりの1ブロックのコマンドによるコマンドはセミコロンで終わりません。
2.7. String Comparison
2.7. ストリング比較
When matching one string against another, there are a number of ways of performing the match operation. These are accomplished with three types of matches: an exact match, a substring match, and a wildcard glob-style match. These are described below.
別のものに対して1個のストリングを合わせるとき、マッチ操作を実行する多くの方法があります。 これらは3つのタイプのマッチで達成されます: 完全な一致、サブストリングマッチ、およびワイルドカード塊スタイルは合っています。 これらは以下で説明されます。
In order to provide for matches between character sets and case insensitivity, Sieve uses the comparators defined in the Internet Application Protocol Collation Registry [COLLATION].
文字集合と大文字小文字の同一視とのマッチに備えるために、SieveはインターネットApplicationプロトコルCollation Registry[COLLATION]で定義された比較器を使用します。
Guenther & Showalter Standards Track [Page 13] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[13ページ]: 2008年1月に言語をフィルターにかけるメール
However, when a string represents the name of a header, the comparator is never user-specified. Header comparisons are always done with the "i;ascii-casemap" operator, i.e., case-insensitive comparisons, because this is the way things are defined in the message specification [IMAIL].
しかしながら、ストリングがヘッダーの名前を表すとき、比較器はユーザによって決して指定されていません。 いつもすなわち、「i; ASCIIでcasemapする」オペレータ、大文字と小文字を区別しない比較でヘッダー比較をします、これがことがメッセージ仕様[IMAIL]に基づき定義される方法であるので。
2.7.1. Match Type
2.7.1. タイプを合わせてください。
Commands that perform string comparisons may have an optional match type argument. The three match types in this specification are ":contains", ":is", and ":matches".
ストリング比較を実行するコマンドで、任意のマッチは議論をタイプするかもしれません。 「この仕様による3つのマッチタイプがそうです」:、含有、」、」、:、」 」 : マッチである、」
The ":contains" match type describes a substring match. If the value
argument contains the key argument as a substring, the match is true.
For instance, the string "frobnitzm" contains "frob" and "nit", but
not "fbm". The empty key ("") is contained in all values.
「The」、:、含有、」 マッチタイプはサブストリングマッチについて説明します。 値の議論がサブストリングとして主要な議論を含んでいるなら、マッチは本当です。 例えば、ストリング"frobnitzm"は"fbm"ではなく"frob"と「夜」を含んでいます。 空のキー、(「「)、すべての値に含まれている、」
The ":is" match type describes an absolute match; if the contents of
the first string are absolutely the same as the contents of the
second string, they match. Only the string "frobnitzm" is the string
"frobnitzm". The empty key ("") only ":is" matches with the empty
value.
「」 : 」 マッチタイプが絶対マッチについて説明するということです。 最初のストリングの内容が2番目のストリングのコンテンツと絶対に同じであるなら、それらは合っています。 ストリングだけ"frobnitzm"はストリング"frobnitzm"です。 空のキー、(「「)、唯一、」 : 」 空の値とのマッチはそうですか?
The ":matches" match type specifies a wildcard match using the characters "*" and "?"; the entire value must be matched. "*" matches zero or more characters in the value and "?" matches a single character in the value, where the comparator that is used (see section 2.7.3) defines what a character is. For example, the comparators "i;octet" and "i;ascii-casemap" define a character to be a single octet, so "?" will always match exactly one octet when one of those comparators is in use. In contrast, a Unicode-based comparator would define a character to be any UTF-8 octet sequence encoding one Unicode character and thus "?" may match more than one octet. "?" and "*" may be escaped as "\\?" and "\\*" in strings to match against themselves. The first backslash escapes the second backslash; together, they escape the "*". This is awkward, but it is commonplace in several programming languages that use globs and regular expressions.
「」 : 」 マッチがタイプするマッチはキャラクタ「*」と“?"を使用することでワイルドカードマッチを指定します。 全体の値を合わせなければなりません。 「*」は値でゼロか、より多くのキャラクタに合っています、そして、“?"は値で単独のキャラクタに合っています。(そこでは、キャラクタが何であるかを定義します)使用された(セクション2.7.3を見ます)比較器。 例えば、比較器、「i;、八重奏、」 「i; ASCIIでcasemapすること」がただ一つの八重奏になるようにキャラクタを定義するので、それらの比較器の1つが使用中であるときに、“?"はいつもまさにある八重奏に合うでしょう。 対照的に、ユニコードベースの比較器は1人のユニコード文字をコード化するどんなUTF-8八重奏系列にもなるようにキャラクタを定義するでしょう、そして、その結果、“?"は1つ以上の八重奏に合うかもしれません。 自分たちに対して合わせるストリングの「"?"と「*」」 \\として逃げられるかもしれません--」 」 \\*。」 最初のバックスラッシュは2番目のバックスラッシュから逃げます。 彼らは「*」から一緒に、逃げます。 これは無器用ですが、それは塊と正規表現を使用するいくつかのプログラミング言語で平凡です。
In order to specify what type of match is supposed to happen, commands that support matching take optional arguments ":matches", ":is", and ":contains". Commands default to using ":is" matching if no match type argument is supplied. Note that these modifiers interact with comparators; in particular, only comparators that support the "substring match" operation are suitable for matching with ":contains" or ":matches". It is an error to use a comparator with ":contains" or ":matches" that is not compatible with it.
「どんなタイプのマッチが起こると思われて、それを命令するかを指定するには、」 : 合っている撮影任意の議論がマッチであるとサポートしてください」、」、:、」、」、:、含有、」 「コマンドは使用をデフォルトとする」: 」 マッチタイプ議論を全く供給しないなら、合っています。 これらの修飾語が比較器と対話することに注意してください。 「比較器だけ、それは「」 操作が合うのに適当であるサブストリングマッチ」をサポートします: 」 」 : マッチを含んでいる、」 「それは比較器を使用する誤りです」: それと互換性がなかった状態で」 」 : マッチを含んでいます。
Guenther & Showalter Standards Track [Page 14] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[14ページ]: 2008年1月に言語をフィルターにかけるメール
It is an error to give more than one of these arguments to a given command.
それはこれらの議論の1つ以上を与えられたコマンドに与える誤りです。
For convenience, the "MATCH-TYPE" syntax element is defined here as follows:
便利において、「マッチタイプ」構文要素は以下の通りここで定義されます:
Syntax: ":is" / ":contains" / ":matches"
構文: 「「:、」 /である、」、:、」 /を含んでいる、」 : マッチ、」
2.7.2. Comparisons across Character Sets
2.7.2. 文字コードの向こう側の比較
Messages may involve a number of character sets. In order for comparisons to work across character sets, implementations SHOULD implement the following behavior:
メッセージは多くの文字集合にかかわるかもしれません。 比較が文字集合の向こう側に扱うように、実装SHOULDは以下の振舞いを実装します:
Comparisons are performed on octets. Implementations convert text
from header fields in all charsets [MIME3] to Unicode, encoded as
UTF-8, as input to the comparator (see section 2.7.3).
Implementations MUST be capable of converting US-ASCII, ISO-8859-
1, the US-ASCII subset of ISO-8859-* character sets, and UTF-8.
Text that the implementation cannot convert to Unicode for any
reason MAY be treated as plain US-ASCII (including any [MIME3]
syntax) or processed according to local conventions. An encoded
NUL octet (character zero) SHOULD NOT cause early termination of
the header content being compared against.
比較は八重奏に実行されます。 実装は比較器に入力されるようにすべてのcharsets[MIME3]のヘッダーフィールドからUTF-8としてコード化されたユニコードまでテキストを変換します(セクション2.7.3を見てください)。 実装は米国-ASCII、ISO-8859- 1、ISO8859*文字集合、およびUTF-8の米国-ASCII部分集合を変換できなければなりません。 実装がどんな理由でもユニコードに変換できないテキストは、明瞭な米国-ASCII(どんな[MIME3]構文も含んでいる)として扱われるか、または地方のコンベンションによると、処理されるかもしれません。 比較されるヘッダー含有量のコード化されたNUL八重奏(キャラクタゼロ)SHOULD NOT原因期限前契約解除。
If implementations fail to support the above behavior, they MUST conform to the following:
実装が上の振舞いをサポートしないなら、以下に従わなければなりません:
No two strings can be considered equal if one contains octets
greater than 127.
1つが八重奏より多くの127を含んでいるなら、等しいといいえtwo、ストリングを考えることができます。
2.7.3. Comparators
2.7.3. 比較器
In order to allow for language-independent, case-independent matches, the match type may be coupled with a comparator name. The Internet Application Protocol Collation Registry [COLLATION] provides the framework for describing and naming comparators.
言語から独立していて、ケースから独立しているマッチを考慮するために、マッチタイプは比較器名に結びつけられるかもしれません。 インターネットApplicationプロトコルCollation Registry[COLLATION]は比較器を説明して、命名するのにフレームワークを提供します。
All implementations MUST support the "i;octet" comparator (simply compares octets) and the "i;ascii-casemap" comparator (which treats uppercase and lowercase characters in the US-ASCII subset of UTF-8 as the same). If left unspecified, the default is "i;ascii-casemap".
すべての実装がサポートしなければならない、「i;、八重奏、」 比較器(単に、八重奏を比較する)と「i; ASCIIでcasemapする」比較器(どの御馳走が大文字されますか、そして、同じくらいとしてのUTF-8の米国-ASCII部分集合の小文字のキャラクタ)。 不特定のままにされるなら、デフォルトはままにされます。「i; ASCIIでcasemapします」。
Some comparators may not be usable with substring matches; that is, they may only work with ":is". It is an error to try to use a comparator with ":matches" or ":contains" that is not compatible with it.
いくつかの比較器はサブストリングマッチで使用可能でないかもしれません。 「すなわち、彼らは働いているだけであるかもしれない」:、」 または、「それは」 : マッチがある比較器を使用しようとする誤りです」、」、:、含有、」 それはそれと互換性がありません。
Guenther & Showalter Standards Track [Page 15] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[15ページ]: 2008年1月に言語をフィルターにかけるメール
Sieve treats a comparator result of "undefined" the same as a result of "no-match". That is, this base specification does not provide any means to directly detect invalid comparator input.
ふるいは「マッチがありません」の結果、同じように「未定義」の比較器結果を扱います。 すなわち、この基礎仕様は直接無効の比較器入力を検出するどんな手段も提供しません。
A comparator is specified by the ":comparator" option with commands that support matching. This option is followed by a string providing the name of the comparator to be used. For convenience, the syntax of a comparator is abbreviated to "COMPARATOR", and (repeated in several tests) is as follows:
「比較器が指定される、」 : 比較器、」 マッチングをサポートするコマンドによるオプション。 使用されるために比較器の名前を提供するストリングはこのオプションを支えています。 便利において、比較器の構文は、「比較器」に簡略化されていて、以下の通りです(いくつかのテストで、繰り返されます):
Syntax: ":comparator" <comparator-name: string>
構文: 「: 比較器、」 <比較器名: ストリング>。
So in this example,
したがって、この例で
Example: if header :contains :comparator "i;octet" "Subject"
"MAKE MONEY FAST" {
discard;
}
例: ヘッダー:contains:comparatorである、「i;、」 「対象」が「速くお金を稼ぐ」八重奏破棄。
would discard any message with subjects like "You can MAKE MONEY FAST", but not "You can Make Money Fast", since the comparator used is case-sensitive.
「あなたは速くお金を稼ぐことができること」ではなく、「あなたは速くお金を稼ぐことができる」ような対象でどんなメッセージも捨てるでしょう、使用される比較器が大文字と小文字を区別しているので。
Comparators other than "i;octet" and "i;ascii-casemap" must be declared with require, as they are extensions. If a comparator declared with require is not known, it is an error, and execution fails. If the comparator is not declared with require, it is also an error, even if the comparator is supported. (See section 2.10.5.)
」 「i; ASCIIでcasemapすること」で宣言しなければなりません。比較器、「i;、八重奏、それらが拡大であるので、必要です。 比較器が宣言した、必要である、知られないで、それは誤りであり、実行は失敗します。 比較器で宣言されない、必要である、また、比較器が支えられても、それは誤りです。 (セクション2.10.5を見てください。)
Both ":matches" and ":contains" match types are compatible with the "i;octet" and "i;ascii-casemap" comparators and may be used with them.
「両方」: マッチ、」、」、:、」 タイプは互換性があるマッチを含んでいる、「i;、八重奏、」、「i; 」 比較器をASCIIでcasemapして、それらと共に使用されるかもしれません。
It is an error to give more than one of these arguments to a given command.
それはこれらの議論の1つ以上を与えられたコマンドに与える誤りです。
2.7.4. Comparisons against Addresses
2.7.4. アドレスに対する比較
Addresses are one of the most frequent things represented as strings. These are structured, and being able to compare against the local- part or the domain of an address is useful, so some tests that act exclusively on addresses take an additional optional argument that specifies what the test acts on.
アドレスはストリングとして表される中で最も頻繁なことの1つです。 これらが構造化されて、地方の部分かアドレスのドメインに対して比較できるのが役に立つので、排他的にアドレスに影響するいくつかのテストがテストが影響するものを指定する追加任意の議論を取ります。
These optional arguments are ":localpart", ":domain", and ":all", which act on the local-part (left side), the domain-part (right side), and the whole address.
「これらの任意の議論はそうです」: localpart、」、」、: ドメイン、」 」 : すべて」、地方の部分(左側)、ドメイン部分(右側)、および全体のアドレスに影響する。
Guenther & Showalter Standards Track [Page 16] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[16ページ]: 2008年1月に言語をフィルターにかけるメール
If an address is not syntactically valid, then it will not be matched by tests specifying ":localpart" or ":domain".
」 : 「アドレスはシンタクス上有効であることで、次に、それが」 : localpartを指定するテストで合わせられないということでないかどうか」かドメイン、」
The kind of comparison done, such as whether or not the test done is case-insensitive, is specified as a comparator argument to the test.
行われたテストが大文字と小文字を区別しないのなどように行われた比較の種類は比較器議論としてテストに指定されます。
If an optional address-part is omitted, the default is ":all".
「任意のアドレス部が省略されるなら、デフォルトは省略されます」:、すべて」
It is an error to give more than one of these arguments to a given command.
それはこれらの議論の1つ以上を与えられたコマンドに与える誤りです。
For convenience, the "ADDRESS-PART" syntax element is defined here as follows:
便利において、「アドレス部」構文要素は以下の通りここで定義されます:
Syntax: ":localpart" / ":domain" / ":all"
構文: 「「: localpart」/」: ドメイン、」 /、」 : すべて」
2.8. Blocks
2.8. ブロック
Blocks are sets of commands enclosed within curly braces and supplied as the final argument to a command. Such a command is a control structure: when executed it has control over the number of times the commands in the block are executed.
ブロックは巻き毛の支柱の中に同封されて、最終弁論としてコマンドに供給されたコマンドのセットです。 そのようなコマンドは制御構造です: 実行されると、それはブロックのコマンドが実行されるという回の数を管理します。
With the commands supplied in this memo, there are no loops. The control structures supplied--if, elsif, and else--run a block either once or not at all.
このメモでコマンドを供給していて、輪が全くありません。 構造が供給したコントロール--、elsifに、ほかに、ブロックを一度か全く動かさないでください。
2.9. Commands
2.9. コマンド
Sieve scripts are sequences of commands. Commands can take any of the tokens above as arguments, and arguments may be either tagged or positional arguments. Not all commands take all arguments.
ふるいのスクリプトはコマンドの系列です。 コマンドは議論として上でトークンを少しもみなすことができます、そして、議論はタグ付けをされたか位置の議論であるかもしれません。 すべてのコマンドがすべての議論を取るというわけではありません。
There are three kinds of commands: test commands, action commands, and control commands.
3種類のコマンドがあります: コマンド、動作命令、および制御コマンドをテストしてください。
The simplest is an action command. An action command is an identifier followed by zero or more arguments, terminated by a semicolon. Action commands do not take tests or blocks as arguments. The actions referenced in this document are:
最も簡単であるのは、動作命令です。 動作命令はゼロがいうことになった識別子であるか以上がセミコロンによって終えられた議論です。 動作命令は議論としてテストか何ブロックもみなしません。 本書では参照をつけられる動作は以下の通りです。
- keep, to save the message in the default location
- fileinto, to save the message in a specific mailbox
- redirect, to forward the message to another address
- discard, to silently throw away the message
- 保って、デフォルト位置にメッセージを保存してください--特定のメールボックスの中のメッセージ--fileinto、節約するには、別のアドレスへのメッセージをフォワードに向け直してください--捨てて、静かにメッセージを無駄にしてください。
Guenther & Showalter Standards Track [Page 17] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[17ページ]: 2008年1月に言語をフィルターにかけるメール
A control command is a command that affects the parsing or the flow of execution of the Sieve script in some way. A control structure is a control command that ends with a block instead of a semicolon.
制御コマンドは、構文解析に影響するコマンドか何らかの道における、Sieveスクリプトの実行の流れです。 制御構造はブロックがセミコロンの代わりにある状態で終わる制御コマンドです。
A test command is used as part of a control command. It is used to specify whether or not the block of code given to the control command is executed.
テスト命令は制御コマンドの一部として使用されます。 それは、制御コマンドに与えられたコードのブロックが実行されるかどうか指定するのに使用されます。
2.10. Evaluation
2.10. 評価
2.10.1. Action Interaction
2.10.1. 動作相互作用
Some actions cannot be used with other actions because the result would be absurd. These restrictions are noted throughout this memo.
結果はとんでもないでしょう、したがって、他の動作と共にいくつかの動作を使用できません。 これらの制限はこのメモ中に述べられます。
Extension actions MUST state how they interact with actions defined in this specification.
拡大動作はそれらがどうこの仕様に基づき定義された動作と対話するかを述べなければなりません。
2.10.2. Implicit Keep
2.10.2. 暗黙の生活費
Previous experience with filtering systems suggests that cases tend to be missed in scripts. To prevent errors, Sieve has an "implicit keep".
フィルタリング・システムの以前の経験は、ケースが、スクリプトで逃される傾向があるのを示します。 誤りを防ぐために、Sieveには、「暗黙の生活費」があります。
An implicit keep is a keep action (see section 4.3) performed in absence of any action that cancels the implicit keep.
暗黙の生活費は暗黙の生活費を取り消すどんな動作の欠如でも実行された生活費動作(セクション4.3を見る)です。
An implicit keep is performed if a message is not written to a mailbox, redirected to a new address, or explicitly thrown out. That is, if a fileinto, a keep, a redirect, or a discard is performed, an implicit keep is not.
暗黙の生活費は、メッセージがメールボックスに書かれないなら実行されるか、新しい住所に向け直されるか、または明らかに放り出されます。 すなわち、fileinto、aが保たれるなら、再直接かa破棄は実行されて、暗黙の生活費はそうではありません。
Some actions may be defined to not cancel the implicit keep. These actions may not directly affect the delivery of a message, and are used for their side effects. None of the actions specified in this document meet that criteria, but extension actions may.
いくつかの動作は暗黙が保つどんなキャンセルとも定義されないかもしれません。 これらの動作は、直接メッセージの配送に影響しないかもしれなくて、それらの副作用に使用されます。 本書では指定された動作のいずれもその評価基準を満たしませんが、拡大動作は満たすかもしれません。
For instance, with any of the short messages offered above, the following script produces no actions.
例えば、短いメッセージのどれかを上に提供している状態で、以下のスクリプトは動作を全く起こしません。
Example: if size :over 500K { discard; }
例: 500Kのサイズ:overです。破棄。
As a result, the implicit keep is taken.
その結果、暗黙の生活費を取ります。
Guenther & Showalter Standards Track [Page 18] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[18ページ]: 2008年1月に言語をフィルターにかけるメール
2.10.3. Message Uniqueness in a Mailbox
2.10.3. メールボックスの中のメッセージのユニークさ
Implementations SHOULD NOT deliver a message to the same mailbox more than once, even if a script explicitly asks for a message to be written to a mailbox twice.
実装SHOULD NOTは一度より同じメールボックスにメッセージを提供します、スクリプトが明らかに二度メールボックスに書かれるべきメッセージを求めても。
The test for equality of two messages is implementation-defined.
2つのメッセージの平等のためのテストは実装で定義されています。
If a script asks for a message to be written to a mailbox twice, it MUST NOT be treated as an error.
スクリプトが二度メールボックスに書かれるべきメッセージを求めるなら、誤りとしてそれを扱ってはいけません。
2.10.4. Limits on Numbers of Actions
2.10.4. 動作の数における限界
Site policy MAY limit the number of actions taken and MAY impose restrictions on which actions can be used together. In the event that a script hits a policy limit on the number of actions taken for a particular message, an error occurs.
サイト方針は、取られた行動の数を制限して、動作を一緒に使用できる制限を課すかもしれません。 スクリプトが特定のメッセージに取られた行動の数における方針限界を打つ場合、誤りは発生します。
Implementations MUST allow at least one keep or one fileinto. If fileinto is not implemented, implementations MUST allow at least one keep.
実装は少なくともある生活費かあるfileintoを許容しなければなりません。 fileintoが実装されないなら、実装は少なくともある生活費を許容しなければなりません。
2.10.5. Extensions and Optional Features
2.10.5. 拡大とオプション機能
Because of the differing capabilities of many mail systems, several features of this specification are optional. Before any of these extensions can be executed, they must be declared with the "require" action.
多くのメールシステムの異なった能力のために、この仕様のいくつかの特徴が任意です。 これらの拡大のどれかを実行できる前に、「必要」動作でそれらを宣言しなければなりません。
If an extension is not enabled with "require", implementations MUST treat it as if they did not support it at all. This protects scripts from having their behavior altered by extensions that the script author might not have even been aware of.
拡大が「必要」で可能にされないなら、まるでそれを全くサポートしないかのように実装はそれを扱わなければなりません。 これはスクリプト作者が意識してさえいなかったかもしれない拡大で彼らの振舞いを変更させるのからスクリプトを保護します。
Implementations MUST NOT execute any Sieve script test or command subsequent to "require" if one of the required extensions is unavailable.
必要な拡大の1つが入手できないなら、実装は「必要である」ためにはその後の少しのSieveスクリプトテストやコマンドも実行してはいけません。
Note: The reason for this restriction is that prior experiences
with languages such as LISP and Tcl suggest that this is a
workable way of noting that a given script uses an extension.
以下に注意してください。 この制限の理由はLISPやTclなどの言語の先の経験が、これが与えられたスクリプトが拡張子を使用することに注意する実行可能な方法であると示唆するということです。
Extensions that define actions MUST state how they interact with actions discussed in the base specification.
動作を定義する拡大はそれらがどう基礎仕様で議論した動作と対話するかを述べなければなりません。
Guenther & Showalter Standards Track [Page 19] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[19ページ]: 2008年1月に言語をフィルターにかけるメール
2.10.6. Errors
2.10.6. 誤り
In any programming language, there are compile-time and run-time errors.
どんなプログラミング言語にも、コンパイル時とランタイム誤りがあります。
Compile-time errors are ones in syntax that are detectable if a syntax check is done.
構文でコンパイル時の誤りは構文チェックが完了しているなら検出可能なものです。
Run-time errors are not detectable until the script is run. This includes transient failures like disk full conditions, but also includes issues like invalid combinations of actions.
スクリプトが実行されるまで、ランタイム誤りは検出可能ではありません。 これは、ディスク完全条件のような一時障害を含んでいますが、動作の無効の組み合わせのような問題をまた含んでいます。
When an error occurs in a Sieve script, all processing stops.
誤りがSieveスクリプトで発生すると、すべての処理が止まります。
Implementations MAY choose to do a full parse, then evaluate the script, then do all actions. Implementations might even go so far as to ensure that execution is atomic (either all actions are executed or none are executed).
実装は、完全が分析するaをするのを選んで、次に、スクリプトを評価して、次に、すべての動作をするかもしれません。 実装は実行が確実に原子になるようにしさえするかもしれません(すべての動作が実行されるか、またはなにも実行されません)。
Other implementations may choose to parse and run at the same time. Such implementations are simpler, but have issues with partial failure (some actions happen, others don't).
他の実装は、同時に分析して、稼働するのを選ぶかもしれません。 そのような実装は、より簡単ですが、部分的な失敗の問題を持ってください(いくつかの動作が起こって、他のものはそうしません)。
Implementations MUST perform syntactic, semantic, and run-time checks on code that is actually executed. Implementations MAY perform those checks or any part of them on code that is not reached during execution.
実装は構文で働かなければならなくて、コードの意味とランタイムチェックはそれです。実際に実行されます。 実装はそれらのチェックかそれらのどんな部分も実行の間に達していないコードに実行するかもしれません。
When an error happens, implementations MUST notify the user that an error occurred and which actions (if any) were taken, and do an implicit keep.
それの動作(もしあれば)は、誤りが起こって、実装は誤りが発生したことをユーザに通知しなければならなくて、取られて、暗黙の生活費をします。
2.10.7. Limits on Execution
2.10.7. 実行における限界
Implementations may limit certain constructs. However, this specification places a lower bound on some of these limits.
実装はある構造物を制限するかもしれません。 しかしながら、この仕様はこれらの限界のいくつかに下界を置きます。
Implementations MUST support fifteen levels of nested blocks.
実装は15のレベルに関するネスト化されたブロックを支えなければなりません。
Implementations MUST support fifteen levels of nested test lists.
実装は15のレベルの入れ子にされたテストリストをサポートしなければなりません。
Guenther & Showalter Standards Track [Page 20] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[20ページ]: 2008年1月に言語をフィルターにかけるメール
3. Control Commands
3. 制御コマンド
Control structures are needed to allow for multiple and conditional actions.
制御構造が、複数の、そして、条件付きの動きを考慮するのに必要です。
3.1. Control if
3.1. コントロール
There are three pieces to if: "if", "elsif", and "else". Each is actually a separate command in terms of the grammar. However, an elsif or else MUST only follow an if or elsif. An error occurs if these conditions are not met.
スリーピースがある、: "if"、"elsif"、および「ほかに。」 しかしながら、文法でそれぞれが実際に別々のコマンドである、elsifするだけでよいか、または続くだけでよい、または、elsif。 これらの条件が満たされないなら、誤りは発生します。
Usage: if <test1: test> <block1: block>
用法: <test1であるなら: ><block1をテストしてください: ブロック>。
Usage: elsif <test2: test> <block2: block>
用法: elsif<test2: ><block2をテストしてください: ブロック>。
Usage: else <block3: block>
用法: ほかの<block3: ブロック>。
The semantics are similar to those of any of the many other programming languages these control structures appear in. When the interpreter sees an "if", it evaluates the test associated with it. If the test is true, it executes the block associated with it.
意味論はこれらの制御構造が現れる他の多くのプログラミング言語のどれかのものと同様です。 インタプリタが“if"を見るとき、それはそれに関連しているテストを評価します。 テストが本当であるなら、それはそれに関連しているブロックを実行します。
If the test of the "if" is false, it evaluates the test of the first "elsif" (if any). If the test of "elsif" is true, it runs the elsif's block. An elsif may be followed by an elsif, in which case, the interpreter repeats this process until it runs out of elsifs.
“if"のテストが誤っているなら、それは最初の"elsif"(もしあれば)のテストを評価します。 "elsif"のテストが本当であるなら、それはelsifのブロックを動かします。 elsifはelsifによって続かれるかもしれません、その場合、elsifsを使い果たすまで、インタプリタがこのプロセスを繰り返します。
When the interpreter runs out of elsifs, there may be an "else" case. If there is, and none of the if or elsif tests were true, the interpreter runs the else's block.
インタプリタがelsifsを使い果たすとき、」の「ほかケースがあるかもしれません。 elsifテストが本当であった、インタプリタは稼働しています。または、あるか、そして、なにも、ほかによるブロックです。
This provides a way of performing exactly one of the blocks in the chain.
これはちょうどチェーンでのブロックの1つを実行する方法を提供します。
In the following example, both messages A and B are dropped.
以下の例では、メッセージAとBの両方が下げられます。
Example: require "fileinto";
if header :contains "from" "coyote" {
discard;
} elsif header :contains ["subject"] ["$$$"] {
discard;
} else {
fileinto "INBOX";
}
例: "fileinto"を必要としてください。 ヘッダー:contains“from"「コヨーテ」である、破棄;、elsifヘッダー:contains[「対象」][「$$$」]、破棄;、ほかfileinto「受信トレイ」。
Guenther & Showalter Standards Track [Page 21] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[21ページ]: 2008年1月に言語をフィルターにかけるメール
When the script below is run over message A, it redirects the message to acm@example.com; message B, to postmaster@example.com; any other message is redirected to field@example.com.
以下のスクリプトがメッセージAの上に実行されると、それは acm@example.com; にメッセージを向け直します。 postmaster@example.com; へのメッセージB いかなる他のメッセージも field@example.com に向け直されます。
Example: if header :contains ["From"] ["coyote"] {
redirect "acm@example.com";
} elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.com";
} else {
redirect "field@example.com";
}
例: 「ヘッダー:contains[“From"][「コヨーテ」]である、再直接の" acm@example.com ";、elsifヘッダー:contains、「かける」、」、再直接の" postmaster@example.com ";、ほか再直接の" field@example.com "。
Note that this definition prohibits the "... else if ..." sequence used by C. This is intentional, because this construct produces a shift-reduce conflict.
「この定義が禁止する注意、」 … ほかに、」 C.Thisによって使用された系列は…であるなら意図的です、この構造物がシフトして減少している闘争を起こすので。
3.2. Control require
3.2. コントロールが必要です。
Usage: require <capabilities: string-list>
用法: <能力を必要としてください: ストリングリスト>。
The require action notes that a script makes use of a certain extension. Such a declaration is required to use the extension, as discussed in section 2.10.5. Multiple capabilities can be declared with a single require.
スクリプトが、ある拡大を利用するという動作メモを必要としてください。 そのような宣言が、拡張子を使用するのにセクション2.10.5で議論するように必要です。 複数の能力でシングルであると宣言できます。必要です。
The require command, if present, MUST be used before anything other than a require can be used. An error occurs if a require appears after a command other than require.
存在しているなら、以前、必要コマンドを使用しなければなりません。使用できますaを除いた何でも、必要である。 誤りが発生する、コマンドの後に現れる、aが、必要である必要です。
Example: require ["fileinto", "reject"];
例: ["fileinto"、「廃棄物」]を必要としてください。
Example: require "fileinto";
require "vacation";
例: "fileinto"を必要としてください。 「休暇」を必要としてください。
3.3. Control stop
3.3. コントロール停止
Usage: stop
用法: 停止
The "stop" action ends all processing. If the implicit keep has not been cancelled, then it is taken.
「停止」動作はすべての処理を終わらせます。 暗黙の生活費を取り消していないなら、それを取ります。
Guenther & Showalter Standards Track [Page 22] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[22ページ]: 2008年1月に言語をフィルターにかけるメール
4. Action Commands
4. 動作命令
This document supplies four actions that may be taken on a message: keep, fileinto, redirect, and discard.
このドキュメントはメッセージで取られるかもしれない4つの行動を供給します: fileintoで、再直接のままでいてください、そして、捨ててください。
Implementations MUST support the "keep", "discard", and "redirect" actions.
実装は、「保ってください」、「破棄」をサポートして、動作を「向け直さなければなりません」。
Implementations SHOULD support "fileinto".
実装SHOULDは"fileinto"をサポートします。
Implementations MAY limit the number of certain actions taken (see section 2.10.4).
実装は取られたある行動の数を制限するかもしれません(セクション2.10.4を見てください)。
4.1. Action fileinto
4.1. 動作fileinto
Usage: fileinto <mailbox: string>
用法: fileinto<メールボックス: ストリング>。
The "fileinto" action delivers the message into the specified mailbox. Implementations SHOULD support fileinto, but in some environments this may be impossible. Implementations MAY place restrictions on mailbox names; use of an invalid mailbox name MAY be treated as an error or result in delivery to an implementation- defined mailbox. If the specified mailbox doesn't exist, the implementation MAY treat it as an error, create the mailbox, or deliver the message to an implementation-defined mailbox. If the implementation uses a different encoding scheme than UTF-8 for mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its encoding scheme. For example, the Internet Message Access Protocol [IMAP] uses modified UTF-7, such that a mailbox argument of "odds & ends" would appear in IMAP as "odds &- ends".
"fileinto"動作は指定されたメールボックスの中にメッセージを提供します。 実装SHOULDはfileintoをサポートしますが、いくつかの環境で、これは不可能であるかもしれません。 実装はメールボックス名に関して制限を課すかもしれません。 無効のメールボックス名の使用は実装の定義されたメールボックスへの配送における誤りか結果として扱われるかもしれません。 指定されたメールボックスが存在していないなら、実装は、実装で定義されたメールボックスに誤りとしてそれを扱うか、メールボックスを作成するか、またはメッセージを提供するかもしれません。 メールボックス名のためのUTF-8と異なったコード化は実装用途であるなら計画されて、それはSHOULD reencodeです。UTF-8から体系をコード化するまでのメールボックス名。 例えば、インターネットMessage Accessプロトコル[IMAP]は変更されたUTF-7を使用します、「可能性と終わり」のメールボックス議論がIMAPに現れるそのようなもの、「可能性、-、終わり、」
The capability string for use with the require command is "fileinto".
必要コマンドによる使用のための能力ストリングは"fileinto"です。
In the following script, message A is filed into mailbox "INBOX.harassment".
以下のスクリプトで、メッセージAはメールボックス"INBOX.harassment"にファイルされます。
Example: require "fileinto";
if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment";
}
例: "fileinto"を必要としてください。 ヘッダー:contains[“from"]「コヨーテ」です。fileinto"INBOX.harassment"。
4.2. Action redirect
4.2. 動作再直接です。
Usage: redirect <address: string>
用法: <アドレスを転送してください: ストリング>。
The "redirect" action is used to send the message to another user at a supplied address, as a mail forwarding feature does. The "redirect" action makes no changes to the message body or existing
「再直接」の動作は供給されたアドレスの別のユーザにメッセージを送るのに使用されます、推進機能がするメールとして。 「再直接」の動作はメッセージ本体か存在への変更を全く行いません。
Guenther & Showalter Standards Track [Page 23] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[23ページ]: 2008年1月に言語をフィルターにかけるメール
headers, but it may add new headers. In particular, existing Received headers MUST be preserved and the count of Received headers in the outgoing message MUST be larger than the same count on the message as received by the implementation. (An implementation that adds a Received header before processing the message does not need to add another when redirecting.)
ヘッダー、それだけが新しいヘッダーを加えるかもしれません。 特に、既存のReceivedヘッダーを保存しなければならなくて、送信されるメッセージにおける、Receivedヘッダーのカウントは実装で受け取るようにメッセージにおける同じカウントより大きいに違いありません。 (向け直すとき、メッセージを処理する前にReceivedヘッダーを加える実装は別のものを加える必要はありません。)
The message is sent back out with the address from the redirect command as an envelope recipient. Implementations MAY combine separate redirects for a given message into a single submission with multiple envelope recipients. (This is not a Mail User Agent (MUA)- style forward, which creates a new message with a different sender and message ID, wrapping the old message in a new one.)
メッセージは封筒受取人として向け直しコマンドからアドレスによる外に返送されます。 コンバインが切り離す実装5月は与えられたメッセージのために複数の封筒受取人と共にシングルに服従を向け直します。 (これはメール・ユーザー・エージェント(MUA)ではありません--新しいものにおける古いメッセージを包装して、異なった送付者とメッセージIDで新しいメッセージを作成するスタイルフォワード)
The envelope sender address on the outgoing message is chosen by the sieve implementation. It MAY be copied from the message being processed. However, if the message being processed has an empty envelope sender address the outgoing message MUST also have an empty envelope sender address. This last requirement is imposed to prevent loops in the case where a message is redirected to an invalid address when then returns a delivery status notification that also ends up being redirected to the same invalid address.
送信されるメッセージに関する封筒送付者アドレスはふるいの実装によって選ばれています。 それは処理されるメッセージからコピーされるかもしれません。 しかしながら、処理されるメッセージが空の封筒送付者アドレスを持っているなら、また、送信されるメッセージには空の封筒送付者アドレスがなければなりません。 この最後の要件は、また、終わる配送状態通知がその時戻るときメッセージが同じ無効のアドレスに向け直されながら無効のアドレスに向け直される場合で輪を防ぐために課されます。
A simple script can be used for redirecting all mail:
すべてのメールを転送するのに簡単なスクリプトを使用できます:
Example: redirect "bart@example.com";
例: " bart@example.com "を向け直してください。
Implementations MUST take measures to implement loop control, possibly including adding headers to the message or counting Received headers as specified in section 6.2 of [SMTP]. If an implementation detects a loop, it causes an error.
実装はループ制御を実装する対策を実施しなければなりません、ことによるとヘッダーをメッセージに追加するか、または[SMTP]のセクション6.2の指定されるとしてのReceivedヘッダーを数えるのを含んでいて。 実装が輪を検出するなら、それは誤りを引き起こします。
Implementations MUST provide means of limiting the number of redirects a Sieve script can perform. See section 10 for more details.
実装が制限の手段に数を提供しなければならない、スクリプトが実行できるSieveを向け直します。 その他の詳細に関してセクション10を見てください。
Implementations MAY ignore a redirect action silently due to policy reasons. For example, an implementation MAY choose not to redirect to an address that is known to be undeliverable. Any ignored redirect MUST NOT cancel the implicit keep.
実装は方針理由のため静かに再直接の動きを無視するかもしれません。 例えば、実装は、そうしないのを「非-提出物」であることが知られているアドレスに再直接で選ぶかもしれません。 再直接で無視されて、いくらか、NOTは暗黙の生活費を取り消さなければなりませんか?
4.3. Action keep
4.3. 動作は保たれます。
Usage: keep
用法: 保ってください。
The "keep" action is whatever action is taken in lieu of all other actions, if no filtering happens at all; generally, this simply means to file the message into the user's main mailbox. This command
「保ってください」という動作はフィルターにかけないことが少しでも起こるなら他のすべての動作の代わりに取られるどういった行動です。 一般に、これは、ユーザの主なメールボックスの中にメッセージをファイルすることを単に意味します。 このコマンド
Guenther & Showalter Standards Track [Page 24] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[24ページ]: 2008年1月に言語をフィルターにかけるメール
provides a way to execute this action without needing to know the name of the user's main mailbox, providing a way to call it without needing to understand the user's setup or the underlying mail system.
ユーザのセットアップか基本的なメールシステムを理解する必要はなくてそれを呼ぶ方法を提供して、ユーザの主なメールボックスの名前を知る必要はなくてこの動作を実行する方法を提供します。
For instance, in an implementation where the IMAP server is running scripts on behalf of the user at time of delivery, a keep command is equivalent to a fileinto "INBOX".
例えば、実装では、IMAPサーバが納期のユーザを代表してスクリプトを実行しているところでキープコマンドはfileinto「受信トレイ」に同等です。
Example: if size :under 1M { keep; } else { discard; }
例: 1Mのサイズ:underである、生活費;、ほか破棄。
Note that the above script is identical to the one below.
上のスクリプトが以下のものと同じであることに注意してください。
Example: if not size :under 1M { discard; }
例: 1Mのまして、サイズ:under破棄。
4.4. Action discard
4.4. 動作破棄
Usage: discard
用法: 破棄
Discard is used to silently throw away the message. It does so by simply canceling the implicit keep. If discard is used with other actions, the other actions still happen. Discard is compatible with all other actions. (For instance, fileinto+discard is equivalent to fileinto.)
破棄は、静かにメッセージを無駄にするのに使用されます。 したがって、それは、単に暗黙を取り消すことによって、保たれます。 破棄が他の動作と共に使用されるなら、他の動作はまだ起こっています。 破棄は他のすべての動作と互換性があります。 (例えば、fileinto+破棄はfileintoに同等です。)
Discard MUST be silent; that is, it MUST NOT return a non-delivery notification of any kind ([DSN], [MDN], or otherwise).
破棄は静かであるに違いありません。 すなわち、それはどんな種類([MDN]の、または、そうでない[DSN])の非配送通知も返してはいけません。
In the following script, any mail from "idiot@example.com" is thrown out.
以下のスクリプトで、" idiot@example.com "からのどんなメールも放り出されます。
Example: if header :contains ["from"] ["idiot@example.com"] {
discard;
}
例: ヘッダー:contains[“from"][" idiot@example.com "]です。破棄。
While an important part of this language, "discard" has the potential to create serious problems for users: Students who leave themselves logged in to an unattended machine in a public computer lab may find their script changed to just "discard". In order to protect users in this situation (along with similar situations), implementations MAY keep messages destroyed by a script for an indefinite period, and MAY disallow scripts that throw out all mail.
この言語の重要な部分である間、「破棄」には、ユーザのための深刻な問題を作成する可能性があります: 自分たちが公立のコンピュータ室で無人のマシンにログインされる状態で残す学生はまさしく「捨てる」ために変えられた彼らのスクリプトを見つけるかもしれません。 この状況(同様の状況に伴う)でユーザを保護するために、実装は、無期限にスクリプトでメッセージを無効にしておいて、すべてのメールを放り出すスクリプトを禁じるかもしれません。
Guenther & Showalter Standards Track [Page 25] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[25ページ]: 2008年1月に言語をフィルターにかけるメール
5. Test Commands
5. テスト命令
Tests are used in conditionals to decide which part(s) of the conditional to execute.
テストは、条件付きのどの部分を実行したらよいかを決めるのにconditionalsで使用されます。
Implementations MUST support these tests: "address", "allof", "anyof", "exists", "false", "header", "not", "size", and "true".
実装はこれらのテストをサポートしなければなりません: 「アドレス」、"allof"、「存在」の、そして、「誤った」"anyof"「ヘッダー」、「サイズ」の、そして、「本当」の“not"。
Implementations SHOULD support the "envelope" test.
実装SHOULDは「封筒」テストをサポートします。
5.1. Test address
5.1. テストアドレス
Usage: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
用法: [COMPARATOR][ADDRESS-PART][MATCH-TYPE]が<ヘッダーリストであると扱ってください: >の<の主要なリストをストリングでリストアップしてください: ストリングリスト>。
The "address" test matches Internet addresses in structured headers that contain addresses. It returns true if any header contains any key in the specified part of the address, as modified by the comparator and the match keyword. Whether there are other addresses present in the header doesn't affect this test; this test does not provide any way to determine whether an address is the only address in a header.
「アドレス」テストはアドレスを含む構造化されたヘッダーでインターネット・アドレスに合っています。 どれかヘッダーがアドレスの指定された部分に何かキーを含んでいるなら、それは本当に戻ります、比較器とマッチキーワードによって変更されるように。 ヘッダーの現在の他のアドレスがあるかどうかがこのテストに影響しません。 このテストはアドレスがヘッダーの唯一のアドレスであるかどうか決定する少しの方法も提供しません。
Like envelope and header, this test returns true if any combination of the header-list and key-list arguments match and returns false otherwise.
本当に、ヘッダーリストと主要なリスト議論マッチのどんな組み合わせであるならも、戻ります。そうでなければ、封筒とヘッダーのように、このテストは、虚偽で戻ります。
Internet email addresses [IMAIL] have the somewhat awkward characteristic that the local-part to the left of the at-sign is considered case sensitive, and the domain-part to the right of the at-sign is case insensitive. The "address" command does not deal with this itself, but provides the ADDRESS-PART argument for allowing users to deal with it.
インターネットEメールアドレス[IMAIL]には、いくらか不適当な特性があります。サインの左への地方の部分は大文字と小文字を区別していると考えられます、そして、サインの右へのドメイン部分は大文字と小文字を区別しないです。 「アドレス」コマンドは、これ自体に対処しませんが、ユーザがそれに対処するのを許容するためのADDRESS-PART議論を提供します。
The address primitive never acts on the phrase part of an email address or on comments within that address. It also never acts on group names, although it does act on the addresses within the group construct.
アドレス基関数はそのアドレスの中でEメールアドレスの句の部分、または、コメントに決して行動しません。 グループ構造物の中にアドレスに影響しますが、また、それはグループ名に決して影響しません。
Implementations MUST restrict the address test to headers that contain addresses, but MUST include at least From, To, Cc, Bcc, Sender, Resent-From, and Resent-To, and it SHOULD include any other header that utilizes an "address-list" structured header body.
実装は、アドレステストをアドレスを含むヘッダーに制限しなければなりませんが、少なくともFromを含まなければなりません、To、Cc、Bcc、Sender、Resent、-、Resent、-、それ、SHOULDは「住所録」構造化されたヘッダーボディーを利用するいかなる他のヘッダーも含んでいます。
Example: if address :is :all "from" "tim@example.com" {
discard;
}
例: :is:all“from"が" tim@example.com "であると扱ってくださいなら破棄。
Guenther & Showalter Standards Track [Page 26] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[26ページ]: 2008年1月に言語をフィルターにかけるメール
5.2. Test allof
5.2. テストallof
Usage: allof <tests: test-list>
用法: allof<はテストされます: 試しに>を記載してください。
The "allof" test performs a logical AND on the tests supplied to it.
"allof"テストはそれに供給されたテストに論理的なANDを実行します。
Example: allof (false, false) => false
allof (false, true) => false
allof (true, true) => true
例: >の偽の>の偽のallof(誤って、誤った)=allof(誤って、本当の)=allof(本当の、そして、本当の)は本当に>と等しいです。
The allof test takes as its argument a test-list.
allofテストは議論として試リストをみなします。
5.3. Test anyof
5.3. テストanyof
Usage: anyof <tests: test-list>
用法: anyof<はテストされます: 試しに>を記載してください。
The "anyof" test performs a logical OR on the tests supplied to it.
"anyof"テストはそれに供給されたテストに論理的なORを実行します。
Example: anyof (false, false) => false
anyof (false, true) => true
anyof (true, true) => true
例: >の本当の>の偽のanyof(誤って、誤った)=anyof(誤って、本当の)=anyof(本当の、そして、本当の)は本当に>と等しいです。
5.4. Test envelope
5.4. テスト封筒
Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
用法: 封筒[COMPARATOR][ADDRESS-PART][MATCH-TYPE]<封筒部分: >の<の主要なリストをストリングでリストアップしてください: ストリングリスト>。
The "envelope" test is true if the specified part of the [SMTP] (or equivalent) envelope matches the specified key. This specification defines the interpretation of the (case insensitive) "from" and "to" envelope-parts. Additional envelope-parts may be defined by other extensions; implementations SHOULD consider unknown envelope parts an error.
[SMTP](または、同等物)封筒の指定された部分が指定されたキーに合っているなら、「封筒」テストは本当です。 この仕様は(大文字と小文字を区別しない)の“from"と“to"封筒部品の解釈を定義します。 追加封筒部品は他の拡大で定義されるかもしれません。 実装SHOULDは、未知の封筒部分が誤りであると考えます。
If one of the envelope-part strings is (case insensitive) "from", then matching occurs against the FROM address used in the SMTP MAIL command. The null reverse-path is matched against as the empty string, regardless of the ADDRESS-PART argument specified.
封筒部分ストリングの1つが(大文字と小文字を区別しない)の“from"であるなら、マッチングはSMTP MAILコマンドに使用されるFROMアドレスに対して起こります。 議論が指定したADDRESS-PARTにかかわらず空のストリングとしてヌル逆経路に合わせられています。
If one of the envelope-part strings is (case insensitive) "to", then matching occurs against the TO address used in the SMTP RCPT command that resulted in this message getting delivered to this user. Note that only the most recent TO is available, and only the one relevant to this user.
封筒部分ストリングの1つが(大文字と小文字を区別しない)の“to"であるなら、マッチングはこのユーザに提供されるこのメッセージをもたらしたSMTP RCPTコマンドに使用されるTOアドレスに対して起こります。 最新のTOだけが利用可能であり、ものだけがこのユーザに関連していることに注意してください。
The envelope-part is a string list and may contain more than one parameter, in which case all of the strings specified in the key-list are matched against all parts given in the envelope-part list.
封筒部分は、ストリングリストであり、1つ以上のパラメタを含むかもしれません、その場合、主要なリストで指定されたストリングのすべては封筒部分リストで与えられたすべての部品に取り組まされます。
Guenther & Showalter Standards Track [Page 27] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[27ページ]: 2008年1月に言語をフィルターにかけるメール
Like address and header, this test returns true if any combination of the envelope-part list and key-list arguments match and returns false otherwise.
本当に、封筒部分リストと主要なリスト議論マッチのどんな組み合わせであるならも、戻ります。そうでなければ、アドレスとヘッダーのように、このテストは、虚偽で戻ります。
All tests against envelopes MUST drop source routes.
封筒に対するすべてのテストが送信元経路を下げなければなりません。
If the SMTP transaction involved several RCPT commands, only the data from the RCPT command that caused delivery to this user is available in the "to" part of the envelope.
SMTPトランザクションがいくつかのRCPTコマンドにかかわったなら、配送を引き起こしたRCPTコマンドからこのユーザまでのデータだけが封筒の“to"部分で利用可能です。
If a protocol other than SMTP is used for message transport, implementations are expected to adapt this command appropriately.
SMTP以外のプロトコルがメッセージ転送に使用されるなら、実装が適切にこのコマンドを適合させると予想されます。
The envelope command is optional. Implementations SHOULD support it, but the necessary information may not be available in all cases. The capability string for use with the require command is "envelope".
封筒コマンドは任意です。 実装SHOULDはそれをサポートしますが、必要事項はすべての場合では利用可能でないかもしれません。 必要コマンドによる使用のための能力ストリングは「封筒」です。
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
例: 「封筒」を必要としてください。 封筒:all:is“from"" tim@example.com "です。破棄。
5.5. Test exists
5.5. テストは存在しています。
Usage: exists <header-names: string-list>
用法: 存在、<ヘッダー名: ストリングリスト>。
The "exists" test is true if the headers listed in the header-names argument exist within the message. All of the headers must exist or the test is false.
ヘッダー名の引数で記載されたヘッダーがメッセージの中に存在しているなら、「存在」テストは本当です。 ヘッダーが皆、存在しなければならない、さもなければ、テストは誤っています。
The following example throws out mail that doesn't have a From header and a Date header.
以下の例はFromヘッダーとDateヘッダーがないメールを放り出します。
Example: if not exists ["From","Date"] {
discard;
}
例: 存在しています[“From"、「日付」]。破棄。
5.6. Test false
5.6. 虚偽でテストしてください。
Usage: false
用法: 誤る
The "false" test always evaluates to false.
「誤り」テストがいつも誤っているのに評価する。
Guenther & Showalter Standards Track [Page 28] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[28ページ]: 2008年1月に言語をフィルターにかけるメール
5.7. Test header
5.7. テストヘッダー
Usage: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
用法: ヘッダー[COMPARATOR][MATCH-TYPE]<ヘッダー名: >の<の主要なリストをストリングでリストアップしてください: ストリングリスト>。
The "header" test evaluates to true if the value of any of the named headers, ignoring leading and trailing whitespace, matches any key. The type of match is specified by the optional match argument, which defaults to ":is" if not specified, as specified in section 2.6.
「ヘッダー」テストは、主で引きずっている空白を無視して、命名されたヘッダーのどれかの値が何かキーに合っているかどうか本当に評価します。 「マッチのタイプが任意のマッチ議論で指定される、」、:、」 セクション2.6で指定されるように指定されないなら。議論はデフォルトとします。
Like address and envelope, this test returns true if any combination of the header-names list and key-list arguments match and returns false otherwise.
本当に、ヘッダー名のリストと主要なリスト議論マッチのどんな組み合わせであるならも、戻ります。そうでなければ、アドレスと封筒のように、このテストは、虚偽で戻ります。
If a header listed in the header-names argument exists, it contains
the empty key (""). However, if the named header is not present, it
does not match any key, including the empty key. So if a message
contained the header
ヘッダー名の引数で記載されたヘッダーが存在しているなら、空のキーを含んでいる、(「「)、」 しかしながら、命名されたヘッダーが出席していないなら、それは空のキーを含むどんなキーにも合っていません。 そのようにメッセージがヘッダーを含んだなら
X-Caffeine: C8H10N4O2
X-カフェイン: C8H10N4O2
these tests on that header evaluate as follows:
そのヘッダーのこれらのテストは以下の通り以下を評価します。
header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true
ヘッダー:is[「X-カフェイン」]、[「「]、>の偽のヘッダー:contains[「X-カフェイン」]と等しい、[「「]、本当に>と等しい、」
Testing whether a given header is either absent or doesn't contain any non-whitespace characters can be done using a negated "header" test:
与えられたヘッダーが休むか、または少しの非空白キャラクタも含んでいないことにかかわらず否定「ヘッダー」テストを使用するのをテストできます:
not header :matches "Cc" "?*"
「ヘッダー:matches「cc」でない」--、*、」
5.8. Test not
5.8. テスト
Usage: not <test1: test>
用法: <test1でない: テスト>。
The "not" test takes some other test as an argument, and yields the opposite result. "not false" evaluates to "true" and "not true" evaluates to "false".
“not"テストは、議論としてある他のテストをみなして、反対の結果をもたらします。 「誤らない」、「本当で」「本当でないこと」に関する評価、「誤っていること」に評価します。
5.9. Test size
5.9. テストサイズ
Usage: size <":over" / ":under"> <limit: number>
用法: 「サイズ<」: より多くの」、/、」、:、「><は以下を制限します」。 数の>。
The "size" test deals with the size of a message. It takes either a tagged argument of ":over" or ":under", followed by a number representing the size of the message.
「サイズ」テストはメッセージのサイズに対処します。 「タグ付けをされた議論をどちらかに取る」:、」 」 :下、」 メッセージのサイズを表すa番号があとに続きます。
Guenther & Showalter Standards Track [Page 29] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[29ページ]: 2008年1月に言語をフィルターにかけるメール
If the argument is ":over", and the size of the message is greater than the number provided, the test is true; otherwise, it is false.
「議論がそうなら」: 」 メッセージのより多くのサイズが数が提供されたより大きい、テストは本当です。 さもなければ、それは誤っています。
If the argument is ":under", and the size of the message is less than the number provided, the test is true; otherwise, it is false.
「議論がそうなら」: 」 メッセージのサイズが数が提供されたより少ない、テストは本当です。 さもなければ、それは誤っています。
Exactly one of ":over" or ":under" must be specified, and anything else is an error.
「ちょうど1、」、:、終わっている、」 」 : 」 必須の下では、指定されてください。そうすれば、他の何かが誤りです。
The size of a message is defined to be the number of octets in the [IMAIL] representation of the message.
メッセージのサイズは、メッセージの[IMAIL]表現における、八重奏の数になるように定義されます。
Note that for a message that is exactly 4,000 octets, the message is neither ":over" nor ":under" 4000 octets.
「まさに4,000の八重奏であるメッセージによってそれに注意してください、そして、メッセージはどちらもではありません」:、終わっている、」 」 : 」 4000の八重奏で。
5.10. Test true
5.10. 本当にテストしてください。
Usage: true
用法: 本当
The "true" test always evaluates to true.
テストがいつも本当に評価する「本当さ」。
6. Extensibility
6. 伸展性
New control commands, actions, and tests can be added to the language. Sites must make these features known to their users; this document does not define a way to discover the list of extensions supported by the server.
新しい制御コマンド、動作、およびテストを言語に追加できます。 サイトは彼らのユーザにこれらの特徴を明らかにしなければなりません。 このドキュメントはサーバで後押しされている拡大のリストを発見する方法を定義しません。
Any extensions to this language MUST define a capability string that uniquely identifies that extension. Capability string are case- sensitive; for example, "foo" and "FOO" are different capabilities. If a new version of an extension changes the functionality of a previously defined extension, it MUST use a different name. Extensions may register a set of related capabilities by registering just a unique prefix for them. The "comparator-" prefix is an example of this. The prefix MUST end with a "-" and MUST NOT overlap any existing registrations.
この言語へのどんな拡大も唯一その拡大を特定する能力ストリングを定義しなければなりません。 能力ストリングはケース敏感です。 例えば、"foo"と"FOO"は異なった能力です。 拡大の新しいバージョンが以前に定義された拡大の機能性を変えるなら、それは変名を使わなければなりません。 拡大は、それらのためにまさしくユニークな接頭語を登録することによって、1セットの関連する能力を登録するかもしれません。 「比較器」接頭語はこの例です。 接頭語は、「-」で終わらなければならなくて、少しの既存の登録証明書も重ね合わせてはいけません。
In a situation where there is a script submission protocol and an extension advertisement mechanism aware of the details of this language, scripts submitted can be checked against the mail server to prevent use of an extension that the server does not support.
この言語の詳細を意識しているスクリプト服従プロトコルと拡大広告メカニズムがある状況で、メールサーバに対してサーバがサポートしない拡張子の使用を防ぐために提出されたスクリプトはチェックできます。
Extensions MUST state how they interact with constraints defined in section 2.10, e.g., whether they cancel the implicit keep, and which actions they are compatible and incompatible with. Extensions MUST NOT change the behavior of the "require" control command or alter the interpretation of the argument to the "require" control.
拡大はそれらがどの動作とどのようにセクション2.10で定義された規制と対話して、例えば、それらに暗黙を取り消させるかどうかが続くか、そして、互換性があって非互換であるかを述べなければなりません。 拡大は、「必要」制御コマンドの振舞いを変えてはいけませんし、また「必要」コントロールに議論の解釈を変更してはいけません。
Guenther & Showalter Standards Track [Page 30] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[30ページ]: 2008年1月に言語をフィルターにかけるメール
Extensions that can submit new email messages or otherwise generate new protocol requests MUST consider loop suppression, at least to document any security considerations.
新しいメールメッセージを提出するか、またはそうでなければ新しいプロトコル要求を生成することができる拡大は、少なくともどんなセキュリティ問題も記録するために輪の抑圧を考えなければなりません。
6.1. Capability String
6.1. 能力ストリング
Capability strings are typically short strings describing what capabilities are supported by the server.
能力ストリングはどんな能力がサーバによってサポートされるかを説明する通常脆いストリングです。
Capability strings beginning with "vnd." represent vendor-defined extensions. Such extensions are not defined by Internet standards or RFCs, but are still registered with IANA in order to prevent conflicts. Extensions starting with "vnd." SHOULD be followed by the name of the vendor and product, such as "vnd.acme.rocket-sled".
能力は"vnd"を始めに通します。ベンダーによって定義された拡大を表してください。 そのような拡大は、インターネット標準かRFCsによって定義されませんが、闘争を防ぐためにまだIANAに示されています。 "vnd"から始まる拡大。 SHOULD、ベンダーと製品の"vnd.acme.rocket-sled"などの名前はあとに続いてください。
The following capability strings are defined by this document:
以下の能力ストリングはこのドキュメントによって定義されます:
encoded-character The string "encoded-character" indicates that the
implementation supports the interpretation of
"${hex:...}" and "${unicode:...}" in strings.
「ストリング「コード化されたキャラクタ」が示す実装が解釈をサポートするコード化されたキャラクタ」$、十六進法: …、」 」 $、ユニコード: 」 コネが結ぶ…
envelope The string "envelope" indicates that the implementation
supports the "envelope" command.
実装が「封筒」コマンドをサポートするストリング「封筒」が示す封筒。
fileinto The string "fileinto" indicates that the implementation
supports the "fileinto" command.
実装が"fileinto"コマンドをサポートするストリング"fileinto"が示すfileinto。
comparator- The string "comparator-elbonia" is provided if the
implementation supports the "elbonia" comparator.
Therefore, all implementations have at least the
"comparator-i;octet" and "comparator-i;ascii-casemap"
capabilities. However, these comparators may be used
without being declared with require.
比較器実装が"elbonia"比較器を支えるなら、ストリング「比較器-elbonia」を提供します。 したがって、少なくとも実装が持っているすべて、「比較器i;、八重奏、」 「比較器i; ASCIIでcasemapする」能力。 しかしながら、これらの比較器は宣言されると共に使用されるかもしれません。必要です。
6.2. IANA Considerations
6.2. IANA問題
In order to provide a standard set of extensions, a registry is maintained by IANA. This registry contains both vendor-controlled capability names (beginning with "vnd.") and IETF-controlled capability names. Vendor-controlled capability names may be registered on a first-come, first-served basis, by applying to IANA with the form in the following section. Registration of capability prefixes that do not begin with "vnd." REQUIRES a standards track or IESG-approved experimental RFC.
拡大の標準セットを提供するために、登録はIANAによって維持されます。 この登録はベンダーによって制御された能力名("vnd"で、始まります。)とIETFによって制御された能力名の両方を含んでいます。 ベンダーによって制御された能力名は先着順の方式で登録されるかもしれません、以下のセクションでフォームでIANAに適用することによって。 "vnd"で始まらない能力接頭語の登録。 規格が追跡するREQUIRESかIESGによって承認された実験的なRFC。
Extensions designed for interoperable use SHOULD use IETF-controlled capability names.
拡大は共同利用できる使用のためにIETFによって制御された能力が命名するSHOULD使用を設計しました。
Guenther & Showalter Standards Track [Page 31] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[31ページ]: 2008年1月に言語をフィルターにかけるメール
6.2.1. Template for Capability Registrations
6.2.1. 能力登録証明書のためのテンプレート
The following template is to be used for registering new Sieve extensions with IANA.
以下のテンプレートは、新しいSieve拡張子をIANAに登録するのに使用されることになっています。
To: iana@iana.org Subject: Registration of new Sieve extension
To: iana@iana.org Subject: 新しいSieve拡張子の登録
Capability name: [the string for use in the 'require' statement]
Description: [a brief description of what the extension adds
or changes]
RFC number: [for extensions published as RFCs]
Contact address: [email and/or physical address to contact for
additional information]
能力名: ['必要'声明] 記述における使用のためのストリング: [拡大が加えるものか変化の簡単な説明] RFC番号: [RFCsとして発行された拡大のための] アドレスに連絡してください: [追加情報のために連絡するメール、そして/または、物理アドレス]
6.2.2. Handling of Existing Capability Registrations
6.2.2. 既存の能力登録証明書の取り扱い
In order to bring the existing capability registrations in line with the new template, IANA has modified each as follows:
新しいテンプレートに沿って既存の能力登録証明書をもたらすために、IANAは以下の通りそれぞれを変更しました:
1. The "capability name" and "capability arguments" fields have been
eliminated
2. The "capability keyword" field have been renamed to "Capability
name"
3. An empty "Description" field has been added
4. The "Standards Track/IESG-approved experimental RFC number" field
has been renamed to "RFC number"
5. The "Person and email address to contact for further information"
field should be renamed to "Contact address"
1. 「能力名」と分野が排除されたという「能力議論」2。 「能力キーワード」分野は「能力名」3に改名されました。 人影のない「記述」分野は4に加えられます。 「規格は実験RFC番号をTrack/IESG承認した」という分野が「RFC番号」5に改名されました。 「詳細のために連絡する人とEメールアドレス」分野は、「アドレスに連絡する」ために改名されるべきです。
6.2.3. Initial Capability Registrations
6.2.3. 初期の能力登録証明書
This RFC updates the following entries in the IANA registry for Sieve extensions.
このRFCはSieve拡張子のためにIANA登録で以下のエントリーをアップデートします。
Capability name: encoded-character
Description: changes the interpretation of strings to allow
arbitrary octets and Unicode characters to be
represented using US-ASCII
RFC number: RFC 5228 (Sieve base spec)
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名: コード化されたキャラクタ記述: 変化の任意の八重奏を許容するストリングの解釈と米国-ASCII RFC番号を使用することで表されるべきユニコード文字: RFC5228(ふるいのベース仕様)はアドレスに連絡します: Sieve議論 list <ietf-mta-filters@imc.org 、gt。
Capability name: fileinto
Description: adds the 'fileinto' action for delivering to a
mailbox other than the default
RFC number: RFC 5228 (Sieve base spec)
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名: fileinto記述: デフォルトRFC番号以外のメールボックスに配送するための'fileinto'動作を加えます: RFC5228(ふるいのベース仕様)はアドレスに連絡します: Sieve議論 list <ietf-mta-filters@imc.org 、gt。
Guenther & Showalter Standards Track [Page 32] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[32ページ]: 2008年1月に言語をフィルターにかけるメール
Capability name: envelope
Description: adds the 'envelope' test for testing the message
transport sender and recipient address
RFC number: RFC 5228 (Sieve base spec)
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名: 封筒記述: メッセージ転送送付者と受取人アドレスRFC番号をテストするための'封筒'テストを加えます: RFC5228(ふるいのベース仕様)はアドレスに連絡します: Sieve議論 list <ietf-mta-filters@imc.org 、gt。
Capability name: comparator-* (anything starting with "comparator-")
Description: adds the indicated comparator for use with the
:comparator argument
RFC number: RFC 5228 (Sieve base spec) and [COLLATION]
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名: 比較器*(「比較器」から始める何でも)記述: :comparator議論RFC番号で使用のための示された比較器を加えます: RFC5228(ふるいのベース仕様)と[COLLATION]はアドレスに連絡します: Sieve議論 list <ietf-mta-filters@imc.org 、gt。
6.3. Capability Transport
6.3. 能力輸送
A method of advertising which capabilities an implementation supports is difficult due to the wide range of possible implementations. Such a mechanism, however, should have the property that the implementation can advertise the complete set of extensions that it supports.
実装がサポートするどの能力の広告を出すかメソッドは広範囲の可能な実装のために難しいです。 しかしながら、そのようなメカニズムには、特性があるはずです。実装はそれがサポートする完全な拡大の広告を出すことができます。
7. Transmission
7. トランスミッション
The [MIME] type for a Sieve script is "application/sieve".
Sieveスクリプトのための[MIME]タイプは「アプリケーション/ふるい」です。
The registration of this type for RFC 2048 requirements is updated as follows:
以下の通りRFC2048要件のためのこのタイプの登録をアップデートします:
Subject: Registration of MIME media type application/sieve
Subject: MIMEメディアの登録はアプリケーション/ふるいをタイプします。
MIME media type name: application
MIME subtype name: sieve
Required parameters: none
Optional parameters: none
Encoding considerations: Most Sieve scripts will be textual,
written in UTF-8. When non-7bit characters are used,
quoted-printable is appropriate for transport systems
that require 7bit encoding.
Security considerations: Discussed in section 10 of this RFC.
Interoperability considerations: Discussed in section 2.10.5
of this RFC.
Published specification: this RFC.
Applications that use this media type: sieve-enabled mail
servers and clients
Additional information:
Magic number(s):
File extension(s): .siv .sieve
Macintosh File Type Code(s):
MIMEメディア型名: アプリケーションMIME「副-タイプ」は以下を命名します。 ふるいのRequiredパラメタ: なにも、Optionalパラメタ: なにも、Encoding問題: ほとんどのSieveスクリプトが、UTF-8に原文で、書くようになるでしょう。 引用されて印刷可能な状態で使用される非7に噛み付いているキャラクタがいつかが輸送のために7ビットのコード化を必要とするシステムを当てます。 セキュリティ問題: このRFCのセクション10で、議論します。 相互運用性問題: この.5セクション2.10RFCでは、議論します。 広められた仕様: このRFC。 このメディアタイプを使用するアプリケーション: ふるいで可能にされたメールサーバとクライアントAdditional情報: マジックナンバー(s): ファイル拡張子(s): .siv .sieveマッキントッシュファイルタイプは(s)をコード化します:
Guenther & Showalter Standards Track [Page 33] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[33ページ]: 2008年1月に言語をフィルターにかけるメール
Person & email address to contact for further information:
See the discussion list at ietf-mta-filters@imc.org.
Intended usage:
COMMON
Author/Change controller:
The SIEVE WG, delegated by the IESG.
詳細のために連絡する人とEメールアドレス: ietf-mta-filters@imc.org で議論リストを見てください。 意図している用法: COMMON Author/変化コントローラ: IESGによって代表として派遣されたSIEVE WG。
8. Parsing
8. 構文解析
The Sieve grammar is separated into tokens and a separate grammar as most programming languages are. Additional rules are supplied here for common arguments to various language facilities.
言語を最もプログラムするとき、Sieve文法はトークンと別々の文法に切り離されます。 様々な言語施設への一般的な議論のために付則をここに供給します。
8.1. Lexical Tokens
8.1. 字句
Sieve scripts are encoded in UTF-8. The following assumes a valid UTF-8 encoding; special characters in Sieve scripts are all US-ASCII.
ふるいのスクリプトはUTF-8でコード化されます。 以下は、有効なUTF-8がコード化していると仮定します。 Sieveスクリプトによる特殊文字はすべて米国-ASCIIです。
The following are tokens in Sieve:
↓これはSieveのトークンです:
- identifiers
- tags
- numbers
- quoted strings
- multi-line strings
- other separators
- 識別子--タグ--数--引用文字列--マルチ系列ストリング--他の分離符
Identifiers, tags, and numbers are case-insensitive, while quoted strings and multi-line strings are case-sensitive.
識別子、タグ、および数は大文字と小文字を区別しないのですが、引用文字列とマルチ系列ストリングは大文字と小文字を区別しています。
Blanks, horizontal tabs, CRLFs, and comments ("whitespace") are
ignored except as they separate tokens. Some whitespace is required
to separate otherwise adjacent tokens and in specific places in the
multi-line strings. CR and LF can only appear in CRLF pairs.
空白、水平タブ、CRLFs、およびそれらを除いて、(「空白」)が無視されるというコメントは象徴を切り離します。 いくつかの空白が別々のそうでなければ、隣接している象徴とマルチ線ストリングの特定の場所で必要です。 CRとLFはCRLF組で現れることができるだけです。
The other separators are single individual characters and are mentioned explicitly in the grammar.
他の分離符は、ただ一つの個性であり、文法で明らかに言及されます。
The lexical structure of sieve is defined in the following grammar (as described in [ABNF]):
ふるいの語彙構造は以下の文法で定義されます([ABNF]で説明されるように):
bracket-comment = "/*" *not-star 1*STAR
*(not-star-slash *not-star 1*STAR) "/"
; No */ allowed inside a comment.
; (No * is allowed unless it is the last
; character, or unless it is followed by a
; character that isn't a slash.)
「ブラケットコメントは」 /*と等しい」という*スターでない1*星*(スラッシュに主演していない*スターでない1*星)、」 /、」、。 *はコメントで許容/されませんでした。 ; (*は全くそれが最終でないなら許容されていません;、キャラクタ、aはそれのあとに続いています; スラッシュでないキャラクタでない、)
Guenther & Showalter Standards Track [Page 34] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[34ページ]: 2008年1月に言語をフィルターにかけるメール
comment = bracket-comment / hash-comment
コメントは細切れ肉料理ブラケットコメント/コメントと等しいです。
hash-comment = "#" *octet-not-crlf CRLF
細切れ肉料理コメントが「#」と等しい、*八重奏crlf CRLFでない
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
識別子=(アルファー/"_")*(アルファ/ケタ/"_")
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multiline-literal / multiline-dotstart)
"." CRLF
マルチ線=、「テキスト:」 *(SP / HTAB) (細切れ肉料理コメント/CRLF) *(マルチライン文字通りの/マルチライン-dotstart) "." CRLF
multiline-literal = [ octet-not-period *octet-not-crlf ] CRLF
マルチライン文字通りの=、[期間ではなく、八重奏、八重奏がcrlfしない*] CRLF
multiline-dotstart = "." 1*octet-not-crlf CRLF
; A line containing only "." ends the
; multi-line. Remove a leading '.' if
; followed by another '.'.
「マルチライン-dotstart=」、」 1 *八重奏-crlf CRLFでない。 「」.」終わりだけを含む線、。 マルチ線である。 '先導を取り除いてください'、'、。 '後をつけ別のものがであっている'、'
not-star = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-FF
; either a CRLF pair, OR a single octet
; other than NUL, CR, LF, or star
x0B-0C/%の星でない=CRLF/%x01-09/%x0E-29/%x2B-FF。 CRLFは対にして、ORはただ一つの八重奏です。 NUL、CR、LF、または星を除いて
not-star-slash = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-2E /
%x30-FF
; either a CRLF pair, OR a single octet
; other than NUL, CR, LF, star, or slash
x0B-0C/%のスラッシュに主演していない=CRLF/%x01-09/%x0E-29/%x2B-2E/%x30-FF。 CRLFは対にして、ORはただ一つの八重奏です。 NULを除いて、CR(LF)は主演するか、またはなでぎりします。
number = 1*DIGIT [ QUANTIFIER ]
数は1*DIGITと等しいです。[数量詞]
octet-not-crlf = %x01-09 / %x0B-0C / %x0E-FF
; a single octet other than NUL, CR, or LF
八重奏がcrlfされなかった=%のx01-09/%のx0B-0C/%のx0E-FF。 NUL、CR、またはLF以外のただ一つの八重奏
octet-not-period = %x01-09 / %x0B-0C / %x0E-2D / %x2F-FF
; a single octet other than NUL,
; CR, LF, or period
期間ではなく、八重奏、=%x01-09/%x0B-0C/%のx0E2D/%x2F-FF。 NUL以外のただ一つの八重奏。 CR、LF、または期間
octet-not-qspecial = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-FF
; a single octet other than NUL,
; CR, LF, double-quote, or backslash
x0B-0C/%の八重奏がqspecialされなかった=%x01-09/%x0E-21/%x23-5B/%x5D-FF。 NUL以外のただ一つの八重奏。 CR、LF、二重引用文、またはバックスラッシュ
QUANTIFIER = "K" / "M" / "G"
数量詞=「K」/「M」/「G」
quoted-other = "\" octet-not-qspecial
; represents just the octet-no-qspecial
; character. SHOULD NOT be used
八重奏がqspecialされていなかった状態で、引用されたもう一方は「\」と等しいです。 まさしくいいえがqspecialする八重奏を表します。 キャラクタ。 SHOULD NOT、使用されてください。
quoted-safe = CRLF / octet-not-qspecial
; either a CRLF pair, OR a single octet other
; than NUL, CR, LF, double-quote, or backslash
八重奏がqspecialされていなかった状態で、引用された金庫はCRLF/と等しいです。 CRLF組、ORのaただ一つの八重奏もう一方。 NUL、CR、LF、二重引用文、またはバックスラッシュより
Guenther & Showalter Standards Track [Page 35] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[35ページ]: 2008年1月に言語をフィルターにかけるメール
quoted-special = "\" (DQUOTE / "\")
; represents just a double-quote or backslash
引用されて特別な=「\」(DQUOTE/「\」)。 まさしく二重引用文かバックスラッシュを表します。
quoted-string = DQUOTE quoted-text DQUOTE
引用文字列=DQUOTE引用されたテキストDQUOTE
quoted-text = *(quoted-safe / quoted-special / quoted-other)
引用されたテキストは*と等しいです。(引用されて安全であるか引用されて特別であるか引用されて他)です。
STAR = "*"
星=「*」
tag = ":" identifier
「タグ=」:、」 識別子
white-space = 1*(SP / CRLF / HTAB) / comment
余白は1つの*(SP/CRLF/HTAB)/コメントと等しいです。
8.2. Grammar
8.2. 文法
The following is the grammar of Sieve after it has been lexically interpreted. No whitespace or comments appear below. The start symbol is "start".
それが辞書的に解釈された後に↓これはSieveの文法です。 どんな空白もコメントも以下に現れません。 開始記号は「始め」です。
argument = string-list / number / tag
議論=ストリングリスト/数/タグ
arguments = *argument [ test / test-list ]
議論は*議論と等しいです。[試テスト/リスト]
block = "{" commands "}"
ブロック=は「「命令します」。
command = identifier arguments (";" / block)
コマンドは識別子議論と等しいです。(「」、;、/ブロック)
commands = *command
コマンドは*コマンドと等しいです。
start = commands
等しさコマンドを始めてください。
string = quoted-string / multi-line
ストリング=マルチ引用文字列/線
string-list = "[" string *("," string) "]" / string
; if there is only a single string, the brackets
; are optional
ストリングリスト=、「[「*を結んでください、(「」、ストリング)、」、]、」 /ストリング。 一連しかなければ、括弧です。 任意
test = identifier arguments
テストは識別子議論と等しいです。
test-list = "(" test *("," test) ")"
試しに=を記載してください、「(「*をテストしてください、(「」、テスト)、」、)、」
8.3. Statement Elements
8.3. 声明要素
These elements are collected from the "Syntax" sections elsewhere in this document, and are provided here in [ABNF] syntax so that they can be modified by extensions.
これらの要素を「構文」セクションからほかの場所に本書では集めて、拡大でそれらを変更できるようにここ、[ABNF]構文に提供します。
ADDRESS-PART = ":localpart" / ":domain" / ":all"
「」 : アドレス部=localpart」/、」 : ドメイン、」 /、」 : すべて」
Guenther & Showalter Standards Track [Page 36] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[36ページ]: 2008年1月に言語をフィルターにかけるメール
COMPARATOR = ":comparator" string
「COMPARATORは」 : 比較器と等しい」というストリング
MATCH-TYPE = ":is" / ":contains" / ":matches"
「マッチタイプ=」:、」 /である、」、:、」 /を含んでいる、」 : マッチ、」
9. Extended Example
9. 拡張例
The following is an extended example of a Sieve script. Note that it does not make use of the implicit keep.
↓これはSieveスクリプトの拡張例です。 暗黙の使用がそれによって保たれないことに注意してください。
#
# Example Sieve Filter
# Declare any optional features or extension used by the script
#
require ["fileinto"];
# # 例のSieve Filter#Declare、スクリプト#で使用されるどんなオプション機能や拡張子も["fileinto"]を必要とします。
#
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter mailbox
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
fileinto "filter"; # move to "filter" mailbox
}
#
# Keep all messages to or from people in my company
#
elsif address :DOMAIN :is ["From", "To"] "example.com"
{
keep; # keep in "In" mailbox
}
# # ヘッダー:is「送付者」" owner-ietf-mta-filters@imc.org "がメールボックスを「フィルターにかける」ために#「フィルタ」;移動をfileintoするならIETFフィルタ議論からのメッセージがメールボックス#をフィルターにかけるために記載する知られているメーリングリスト#Moveから、##、がすべてを保つというハンドルメッセージは人々か私の会社#elsifアドレス:DOMAIN:is[“From"、“To"]"example.com"の人々から通信します。保ってください; #“In"メールボックスに閉じ込めてください。
#
# Try and 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", "Bcc"] "me@example.com",
header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"])
{
fileinto "spam"; # move to "spam" mailbox
}
else
{
# Move all other (non-company) mail to "personal"
# mailbox.
fileinto "personal";
}
# # 求められていないメールを捕らえてみてください。 メッセージが私に、スパムであることが知られている対象を含んでいるということでないなら、それを記録してください。 # 「elsif anyof、(:all:contains[“To"、「cc」、"Bcc"]" me@example.com "、ヘッダー:matches「対象」を記述しない、[「**お金*を速い*にしてください」、」、*大学*dipl*mas*、」、)、メールボックスを「ばらまく」ためにほかに#「スパム」;移動をfileintoします。すべてのもう一方(非会社の)が「個人的な」#メールボックスfileinto「個人的に」郵送する#移動。
Guenther & Showalter Standards Track [Page 37] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[37ページ]: 2008年1月に言語をフィルターにかけるメール
10. Security Considerations
10. セキュリティ問題
Users must get their mail. It is imperative that whatever implementations use to store the user-defined filtering scripts protect them from unauthorized modification, to preserve the integrity of the mail system. An attacker who can modify a script can cause mail to be discarded, rejected, or forwarded to an unauthorized recipient. In addition, it's possible that Sieve scripts might expose private information, such as mailbox names, or email addresses of favored (or disfavored) correspondents. Because of that, scripts SHOULD also be protected from unauthorized retrieval.
ユーザは彼らのメールを受け取らなければなりません。 実現がユーザによって定義されたフィルタリングスクリプトを格納するのに使用するものなら何でもメールシステムの保全を保持するために権限のない変更からそれらを保護するのは、必須です。 スクリプトを変更できる攻撃者は、メールが権限のない受取人に捨てられるか、拒絶されるか、または転送されることを引き起こす場合があります。 さらに、Sieveスクリプトが個人情報を露出するのは、可能です、メールボックス名、または好評な(または、疎んじられる)通信員のEメールアドレスなどのように。 それ、SHOULDに原稿を書く、また、権限のない検索から、保護されてください。
Several commands, such as "discard", "redirect", and "fileinto", allow for actions to be taken that are potentially very dangerous.
「破棄」などのような「再直接」のいくつかのコマンド、および"fileinto"は潜在的に非常に危険な取られるべき動きを考慮します。
Use of the "redirect" command to generate notifications may easily overwhelm the target address, especially if it was not designed to handle large messages.
通知を発生させる「向け直し」コマンドの使用は容易にあて先アドレスを圧倒するかもしれません、特にそれが大きいメッセージを扱うように設計されなかったなら。
Allowing a single script to redirect to multiple destinations can be used as a means of amplifying the number of messages in an attack. Moreover, if loop detection is not properly implemented, it may be possible to set up exponentially growing message loops. Accordingly, Sieve implementations:
攻撃における、メッセージの数を増幅する手段としてただ一つのスクリプトを複数の目的地に向け直す許容するのを使用できます。 そのうえ、輪の検出が適切に実行されないなら、セットアップするのは、メッセージ輪を指数関数的に育てながら、可能であるかもしれません。 それに従って、Sieve実現:
(1) MUST implement facilities to detect and break message loops. See
section 6.2 of [SMTP] for additional information on basic loop
detection strategies.
(1)は検出する施設と中断メツセージ輪を実行しなければなりません。 基本的な輪の検出戦略の追加情報に関して[SMTP]のセクション6.2を見てください。
(2) MUST provide the means for administrators to limit the ability of
users to abuse redirect. In particular, it MUST be possible to
limit the number of redirects a script can perform.
Additionally, if no use cases exist for using redirect to
multiple destinations, this limit SHOULD be set to 1. Additional
limits, such as the ability to restrict redirect to local users,
MAY also be implemented.
(2)は管理者が再直接で虐待するユーザの能力を制限する手段を提供しなければなりません。 それは数を制限するのにおいて特に、可能でなければなりません。缶が実行するスクリプトを転送します。 無駄ケースが複数の目的地、この限界SHOULDへの再直接の使用のために存在するなら、さらに、1に設定されてください。 制限する能力などの追加限界は、地方にユーザを向け直して、また、実行されるかもしれません。
(3) MUST provide facilities to log use of redirect in order to
facilitate tracking down abuse.
(3)は、乱用を捜し出すのを容易にするために再直接で使用を登録する施設を提供しなければなりません。
(4) MAY use script analysis to determine whether or not a given
script can be executed safely. While the Sieve language is
sufficiently complex that full analysis of all possible scripts
is computationally infeasible, the majority of real-world scripts
are amenable to analysis. For example, an implementation might
(4) 安全に与えられたスクリプトを作成できるかどうか決定するのに脚本分析を使用するかもしれません。 Sieve言語が十分複雑ですが、すべての可能なスクリプトのその完全な分析が計算上実行不可能である、本当の世界スクリプトの大部分が分析に従順です。 例えば、実現はそうするかもしれません。
Guenther & Showalter Standards Track [Page 38] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[38ページ]: 2008年1月に言語をフィルターにかけるメール
allow scripts that it has determined are safe to run unhindered,
block scripts that are potentially problematic, and subject
unclassifiable scripts to additional auditing and logging.
それが安全であることを決定したスクリプトに潜在的に問題の多くて、対象の分類できないスクリプトである妨害されていないブロックスクリプトを追加監査と伐採へ走らせてください。
Allowing redirects at all may not be appropriate in situations where email accounts are freely available and/or not trackable to a human who can be held accountable for creating message bombs or other abuse.
許容は適切なコネがメールアカウントが自由に利用可能である、そして/または、メッセージ爆弾か他の乱用を作成するのについて責任があるように保つことができる人間に「道-可能」されない状況であったかもしれないなら全く向け直します。
As with any filter on a message stream, if the Sieve implementation and the mail agents 'behind' Sieve in the message stream differ in their interpretation of the messages, it may be possible for an attacker to subvert the filter. Of particular note are differences in the interpretation of malformed messages (e.g., missing or extra syntax characters) or those that exhibit corner cases (e.g., NUL octets encoded via [MIME3]).
メッセージストリームのどんなフィルタならも、メッセージストリームにおけるSieve実現とメールエージェント'behind' Sieveが彼らのメッセージの解釈において異なるなら、攻撃者がフィルタを打倒するのは、可能であるかもしれません。 特定の注意において、奇形のメッセージ(例えば、なくなったか余分な構文キャラクタ)か角のケースを示すもの(例えば[MIME3]を通してコード化されたNUL八重奏)の解釈の違いはそうですか?
11. Acknowledgments
11. 承認
This document has been revised in part based on comments and discussions that took place on and off the SIEVE mailing list. Thanks to Sharon Chisholm, Cyrus Daboo, Ned Freed, Arnt Gulbrandsen, Michael Haardt, Kjetil Torgrim Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Eric Rescorla, Rob Siemborski, and Nigel Swinson for reviews and suggestions.
このドキュメントはコメントに基づいて一部改訂されました、そして、取った議論は時々SIEVEメーリングリストを置きます。 レビューと提案をシャロン・チスホルム、サイラスDaboo、ネッド・フリード、Arnt Gulbrandsen、マイケルHaardt、Kjetil Torgrim Homme、バリーLeiba、マーク・E.マレット、Alexeyメリニコフ、エリック・レスコラ、ロブSiemborski、およびナイジェル・スウィンソンをありがとうございます。
12. Normative References
12. 引用規格
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, March
2007.
[照合] ニューマンとC.とDuerst、M.とA.Gulbrandsen、「インターネットアプリケーション・プロトコル照合登録」、RFC4790、2007年3月。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[IMAIL] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[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月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, November 1996.
[MIME3]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
Guenther & Showalter Standards Track [Page 39] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[39ページ]: 2008年1月に言語をフィルターにかけるメール
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[SMTP] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[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日
13. Informative References
13. 有益な参照
[BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in
electrical technology - Part 2: Telecommunications and
electronics", January 1999.
[2進のSI]、「標準のIEC60027-2:」 電気技術--第2部に使用されるべき手紙シンボル: 1999年1月の「テレコミュニケーションとエレクトロニクス」
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January
2003.
[DSN] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and
Cooperative Work in a Practical Multimedia Message
System", Int. J. of Man-Machine Studies, April, 1991.
Reprinted in Computer-Supported Cooperative Work and
Groupware, Saul Greenberg, editor, Harcourt Brace
Jovanovich, 1991. Reprinted in Readings in Groupware and
Computer-Supported Cooperative Work, Ronald Baecker,
editor, Morgan Kaufmann, 1993.
[フレームズ]のBorenstein、N、およびC.Thyberg、「実用的なマルチメディアにおけるパワー、使いやすさ、および共同作業はシステムを通信する」Int。 J. 男性マシン研究、1991年4月について。 コンピューター支援共同作業とGroupware、ソール・グリーンバーグ、エディタ(ハーコートBrace Jovanovich)では、1991に翻刻します。 Groupwareとコンピューター支援共同作業におけるReadings、ロナルドBaecker、エディタ、モーガン・コフマン、1993では、翻刻しました。
[IMAP] Crispin, M., "Internet Message Access Protocol - version
4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットMessage Accessプロトコル--3月。」
[MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message
Disposition Notification", RFC 3798, May 2004.
[MDN]ハンセン、T.、エド、G.ボードルイ、エド、「メッセージ気質通知」、RFC3798、5月2004日
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC
3028, January 2001.
[RFC3028]ショウォーター、T.、「ふるい:」 「言語をフィルターにかけるメール」、RFC3028、2001年1月。
Guenther & Showalter Standards Track [Page 40] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[40ページ]: 2008年1月に言語をフィルターにかけるメール
14. Changes from RFC 3028
14. RFC3028からの変化
This following list is a summary of the changes that have been made in the Sieve language base specification from [RFC3028].
この次のリストはSieve言語基礎仕様で[RFC3028]から行われた変更の概要です。
1. Removed ban on tests having side-effects
2. Removed reject extension (will be specified in a separate RFC)
3. Clarified description of comparators to match [COLLATION], the
new base specification for them
4. Require stripping of leading and trailing whitespace in "header"
test
5. Clarified or tightened handling of many minor items, including:
- invalid [MIME3] encoding
- invalid addresses in headers
- invalid header field names in tests
- 'undefined' comparator result
- unknown envelope parts
- null return-path in "envelope" test
6. Capability strings are case-sensitive
7. Clarified that fileinto should reencode non-ASCII mailbox
names to match the mailstore's conventions
8. Errors in the ABNF were corrected
9. The references were updated and split into normative and
informative
10. Added encoded-character capability and deprecated (but did not
remove) use of arbitrary binary octets in Sieve scripts.
11. Updated IANA registration template, and added IANA
considerations to permit capability prefix registrations.
12. Added .sieve as a valid extension for Sieve scripts.
1. 副作用2を持っているテストへの禁止令を取り除きました。 廃棄物拡大(別々のRFCでは、指定される)3を取り除きました。 4に[COLLATION]、それらのための新しい基礎仕様を合わせる比較器のはっきりさせられた記述 「ヘッダー」テスト5における主で引きずっている空白から奪い取るのを必要であってください。 多くの小さい方の項目のはっきりさせられたか締められた取り扱い、含み: - 無効の[MIME3]コード化--ヘッダーの無効のアドレス--無効のヘッダーフィールドはテスト('未定義'の比較器結果)で未知の封筒部分を命名します--「封筒」テストにおけるヌルリターンパス6。 能力ストリングは大文字と小文字を区別する7です。 はっきりさせられて、そのfileintoは非ASCIIメールボックスがmailstoreのコンベンション8を合わせるために命名する「再-エンコード」がそうするべきです。 ABNFの誤りは直っている9でした。 参照をアップデートして、規範的で有益な10に分けました。 Sieveスクリプトでコード化されたキャラクタ能力を加えて、任意の2進の八重奏の使用を非難しました(しかし、取り外しませんでした)。 11. IANA登録テンプレートをアップデートして、能力接頭語登録証明書を可能にするためにIANA問題を加えました。 12. Sieveスクリプトのための有効な拡大として.sieveを加えました。
Editors' Addresses
エディタのアドレス
Philip Guenther Sendmail, Inc. 6425 Christie St. Ste 400 Emeryville, CA 94608 EMail: guenther@sendmail.com
フィリップグンサーセンドメールInc.6425クリスティ・聖Ste400エマリービル、カリフォルニア 94608はメールされます: guenther@sendmail.com
Tim Showalter EMail: tjs@psaux.com
ティムショウォーターEMail: tjs@psaux.com
Guenther & Showalter Standards Track [Page 41] RFC 5228 Sieve: An Email Filtering Language January 2008
グンサーとショウォーターStandardsはRFC5228ふるいを追跡します[41ページ]: 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に情報を記述してください。
Guenther & Showalter Standards Track [Page 42]
グンサーとショウォーター標準化過程[42ページ]
一覧
スポンサーリンク
