RFC3028 日本語訳
3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. (Format: TXT=73582 bytes) (Obsoleted by RFC5228) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Showalter Request for Comments: 3028 Mirapoint, Inc. Category: Standards Track January 2001
コメントを求めるワーキンググループT.ショウォーター要求をネットワークでつないでください: 3028年のMirapoint Inc.カテゴリ: 標準化過程2001年1月
Sieve: A Mail Filtering Language
ふるい: 言語をフィルターにかけるメール
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes a language for filtering e-mail 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 it has no variables, loops, or ability to shell out to external programs.
このドキュメントは、最終的な配送の時にメールメッセージをフィルターにかけるために言語を説明します。 それは、メールクライアントかメールサーバのどちらかで実行可能になるように設計されています。広げることができて、簡単で、アクセス・プロトコル、メール構造、およびオペレーティングシステムから独立していることが意味されます。 それはそれにどんな変数、輪も、または能力もないときユーザが外部プログラムへの外でブラックボックスインターネットMessage Accessプロトコル(IMAP)サーバなどの任意のプログラムをシェルに実行できないかもしれないメールサーバで動くのに適当です。
Table of Contents
目次
1. Introduction ........................................... 3 1.1. Conventions Used in This Document ..................... 4 1.2. Example mail messages ................................. 4 2. Design ................................................. 5 2.1. Form of the Language .................................. 5 2.2. Whitespace ............................................ 5 2.3. Comments .............................................. 6 2.4. Literal Data .......................................... 6 2.4.1. Numbers ............................................... 6 2.4.2. Strings ............................................... 7 2.4.2.1. String Lists .......................................... 7 2.4.2.2. Headers ............................................... 8 2.4.2.3. Addresses ............................................. 8 2.4.2.4. MIME Parts ............................................ 9 2.5. Tests ................................................. 9 2.5.1. Test Lists ............................................ 9
1. 序論… 3 1.1. このドキュメントで中古のコンベンション… 4 1.2. 例のメール・メッセージ… 4 2. デザイン… 5 2.1. 言語のフォーム… 5 2.2. 空白… 5 2.3. コメント… 6 2.4. 文字通りのデータ… 6 2.4.1. 数… 6 2.4.2. ストリング… 7 2.4.2.1. リストを結んでください… 7 2.4.2.2. ヘッダー… 8 2.4.2.3. 記述します。 8 2.4.2.4. 部品をまねてください… 9 2.5. テスト… 9 2.5.1. テストは記載します… 9
Showalter Standards Track [Page 1] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[1ページ]: 2001年1月に言語をフィルターにかけるメール
2.6. Arguments ............................................. 9 2.6.1. Positional Arguments .................................. 9 2.6.2. Tagged Arguments ...................................... 10 2.6.3. Optional Arguments .................................... 10 2.6.4. Types of Arguments .................................... 10 2.7. String Comparison ..................................... 11 2.7.1. Match Type ............................................ 11 2.7.2. Comparisons Across Character Sets ..................... 12 2.7.3. Comparators ........................................... 12 2.7.4. Comparisons Against Addresses ......................... 13 2.8. Blocks ................................................ 14 2.9. Commands .............................................. 14 2.10. Evaluation ............................................ 15 2.10.1. Action Interaction .................................... 15 2.10.2. Implicit Keep ......................................... 15 2.10.3. Message Uniqueness in a Mailbox ....................... 15 2.10.4. Limits on Numbers of Actions .......................... 16 2.10.5. Extensions and Optional Features ...................... 16 2.10.6. Errors ................................................ 17 2.10.7. Limits on Execution ................................... 17 3. Control Commands ....................................... 17 3.1. Control Structure If .................................. 18 3.2. Control Structure Require ............................. 19 3.3. Control Structure Stop ................................ 19 4. Action Commands ........................................ 19 4.1. Action reject ......................................... 20 4.2. Action fileinto ....................................... 20 4.3. Action redirect ....................................... 21 4.4. Action keep ........................................... 21 4.5. Action discard ........................................ 22 5. Test Commands .......................................... 22 5.1. Test address .......................................... 23 5.2. Test allof ............................................ 23 5.3. Test anyof ............................................ 24 5.4. Test envelope ......................................... 24 5.5. Test exists ........................................... 25 5.6. Test false ............................................ 25 5.7. Test header ........................................... 25 5.8. Test not .............................................. 26 5.9. Test size ............................................. 26 5.10. Test true ............................................. 26 6. Extensibility .......................................... 26 6.1. Capability String ..................................... 27 6.2. IANA Considerations ................................... 28 6.2.1. Template for Capability Registrations ................. 28 6.2.2. Initial Capability Registrations ...................... 28 6.3. Capability Transport .................................. 29 7. Transmission ........................................... 29
2.6. 議論… 9 2.6.1. 位置の議論… 9 2.6.2. 議論にタグ付けをします… 10 2.6.3. 任意の議論… 10 2.6.4. 議論のタイプ… 10 2.7. 比較を結んでください… 11 2.7.1. タイプを合わせてください… 11 2.7.2. 文字コードの向こう側の比較… 12 2.7.3. 比較器… 12 2.7.4. アドレスに対する比較… 13 2.8. ブロック… 14 2.9. コマンド… 14 2.10. 評価… 15 2.10.1. 動作相互作用… 15 2.10.2. 暗黙の生活費… 15 2.10.3. メールボックスの中のメッセージのユニークさ… 15 2.10.4. 動作の数における限界… 16 2.10.5. 拡大と任意の特徴… 16 2.10.6. 誤り… 17 2.10.7. 実行における限界… 17 3. コントロールは命令します… 17 3.1. 制御構造、… 18 3.2. 構造が必要とするコントロール… 19 3.3. 構造停止を制御してください… 19 4. 動作は命令します… 19 4.1. 動作廃棄物… 20 4.2. 動作fileinto… 20 4.3. 動作再直接… 21 4.4. 動作は保たれます… 21 4.5. 動作破棄… 22 5. テストは命令します… 22 5.1. アドレスをテストしてください… 23 5.2. allofをテストしてください… 23 5.3. anyofをテストしてください… 24 5.4. 封筒を検査してください… 24 5.5. テストは存在しています… 25 5.6. 虚偽でテストしてください… 25 5.7. ヘッダーをテストしてください… 25 5.8. テスト、… 26 5.9. サイズをテストしてください… 26 5.10. 本当にテストしてください… 26 6. 伸展性… 26 6.1. 能力ストリング… 27 6.2. IANA問題… 28 6.2.1. 能力登録証明書のためのテンプレート… 28 6.2.2. 能力登録証明書に頭文字をつけてください… 28 6.3. 能力輸送… 29 7. トランスミッション… 29
Showalter Standards Track [Page 2] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[2ページ]: 2001年1月に言語をフィルターにかけるメール
8. Parsing ................................................ 30 8.1. Lexical Tokens ........................................ 30 8.2. Grammar ............................................... 31 9. Extended Example ....................................... 32 10. Security Considerations ................................ 34 11. Acknowledgments ........................................ 34 12. Author's Address ....................................... 34 13. References ............................................. 34 14. Full Copyright Statement ............................... 36
8. 構文解析… 30 8.1. 字句… 30 8.2. 文法… 31 9. 例を広げています… 32 10. セキュリティ問題… 34 11. 承認… 34 12. 作者のアドレス… 34 13. 参照… 34 14. 完全な著作権宣言文… 36
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 GUIs for filter creation and manipulation. The language is not Turing-complete: it provides no way to write a loop or a function and variables are not provided.
言語は安全なサーバサイドフィルタリング・システムを考慮するために役に立つ、しかし、制限されているほど強力です。 意志は簡単なメールフィルタを書くよりユーザが、より複雑で何でも(危険)であることをするのを不可能にすることです、GUIsのフィルタ創造と操作の使用を容易にすると共に。 言語はチューリング完全ではありません: それは輪か機能を書く方法を全く提供しません、そして、変数は提供されません。
Scripts written in Sieve are executed during final delivery, when the message is moved to the user-accessible mailbox. In systems where the MTA does final delivery, such as traditional Unix mail, it is reasonable to sort 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 e-mail, 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ベースのエディタが多くのユーザのためにフィルタを編集する都合のよい方法になると予想されます。
Showalter Standards Track [Page 3] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[3ページ]: 2001年1月に言語をフィルターにかけるメール
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", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[キーワード]で定義されるように本書では解釈されることになっているべきです。
Each section on a command (test, action, or control structure) has a
line labeled "Syntax:". This line describes the syntax 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
parenthesis are used for grouping, similar to [ABNF].
コマンド(テスト、動作、または制御構造)の各セクションが線をラベルさせる、「構文:」 この線は名前とその議論を含むコマンドの構文について説明します。 必要な議論は角ブラケット("<"と">")の中に記載されています。 そして、任意の議論が角括弧で記載されている、(「[「」、]、」、) 各議論はタイプによって後をつけられていて、そうは「<は以下を合わせます」です。 「ストリング>」は「主要である」と呼ばれるストリングである議論を表します。 文字通りのストリングは二重引用文字列で表されます。 挿入句は、代替手段がスラッシュで切り離されて、組分けに中古であって、[ABNF]と同様です。
In the "Syntax" 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 in section 10 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, nor the legal command names. The intent is to allow for extension without changing the grammar.
これらのための形式文法は、セクション10で命令して、どうコマンドを構成するかに関する正式の参照ですが、形式文法はコマンド、および法的なコマンド名への議論のオーダー、意味論、数またはタイプを指定しません。 意図は文法を変えないで拡大を考慮することです。
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
ほら、全体の金床ものをお詫びします、私はあなたでがけの頂上からそれを落としてみるのを本当に意図しませんでした。 それをあなたまで作ろうとしたいと思います。 私はここ、場所でいくらかのすばらしい粒餌を乗り切りました--、線の先端
Showalter Standards Track [Page 4] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[4ページ]: 2001年1月に言語をフィルターにかけるメール
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 -----------------------------------------------------------
Message B ----------------------------------------------------------- From: youcouldberich!@reply-by-postal-mail.invalid Sender: b1ff@de.res.example.com To: rube@landru.example.edu 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.edu 日付: 月曜日、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セットの象徴から成ります。 コマンド識別子は最初の象徴です、そして、ゼロか、より多くの議論象徴がそれを支えています。 議論は、文字通りのデータ、タグ、ブロックのコマンド、またはテスト命令であるかもしれません。
The language is represented in UTF-8, as specified in [UTF-8].
言語は[UTF-8]で指定されるようにUTF-8に表されます。
Tokens in the ASCII range are considered case-insensitive.
ASCII範囲での象徴は大文字と小文字を区別しないと考えられます。
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であるだけではない)、および間隔文字で作られます。 使用される空白の量はかなりではありません。
Showalter Standards Track [Page 5] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[5ページ]: 2001年1月に言語をフィルターにかけるメール
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;
}
例: 100Kのサイズ:overです。#これはコメント破棄です。
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 and strings.
文字通りのデータは、実行されない単に「そのままで」評価のデータが議論としてコマンドに使用されることを意味します。 文字通りのデータは数とストリングに制限されます。
2.4.1. Numbers
2.4.1. 数
Numbers are given as ordinary decimal numbers. However, those numbers that have a tendency to be fairly large, such as message sizes, MAY have a "K", "M", or "G" 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 tebi-, 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は数[BINARY-SI]の値のtebi倍か10億7374万1824(2^30)倍を指定します。
Implementations MUST provide 31 bits of magnitude in numbers, but MAY provide more.
実現は、31ビットの大きさを数に提供しなければなりませんが、さらに提供されるかもしれません。
Only positive integers are permitted by this specification.
正の整数だけがこの仕様で受入れられます。
Showalter Standards Track [Page 6] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[6ページ]: 2001年1月に言語をフィルターにかけるメール
2.4.2. Strings
2.4.2. ストリング
Scripts involve large numbers of strings 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, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted
string is followed by either another backslash or a double quote.
This two-character sequence represents a single backslash or double-
quote within the string, respectively.
引用文字列は、ただ一つの二重引用文で始まって、終わります。(<「>キャラクタ、ASCII34)。」 別のバックスラッシュか二重引用文のどちらかが引用文字列のバックスラッシュ(「\」、ASCII92)内部のあとに続いています。 この2キャラクタシーケンスがストリングの中にそれぞれただ一つのバックスラッシュか二重引用文を表します。
No other characters should be escaped with a single backslash.
ただ一つのバックスラッシュで他のキャラクタから全く逃げるべきではありません。
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").
「まるでバックスラッシュが全くないかのように未定義のエスケープシーケンス(」 “a"がどんな特別な意味も持っていない文脈の\a」などの)が解釈される、(この場合」、\a」がただ“a"である、)
Non-printing characters such as tabs, CR and LF, and control characters are permitted in quoted strings. Quoted strings MAY span multiple lines. NUL (ASCII 0) is not allowed in strings.
タブや、CRや、LFや、制御文字などの非表示文字は引用文字列で受入れられます。 引用文字列は複数の線にかかるかもしれません。 NUL(ASCII0)はストリングに許容されていません。
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. 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 which 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 dot-stuffed; 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.
メールメッセージなどの多く以上の量のテキストに入るのにおいて、マルチ線フォームは許容されています。 それはキーワードから「テキスト:」 ただ一つの期間、および別のCRLFをCRLFの系列でCRLF、および終わりで続かれて、始動します。 ただ一つのドットがある線を含むメッセージを許容するために、線はドットによって詰められます。 'いつがメッセージ本体、エキストラを構成して、それはいます'。. 'aで始まる各線の前で加えられる'、' サーバがスクリプトを解釈すると、これらの余分なドットを取り除きます。 ドットが非ドットキャラクタによって従われている状態で始まる線がドットによって詰められた状態で解釈されないことに注意してください。 すなわち、".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. Implementations are encouraged to use short-circuit evaluation in these cases.
パターンを合わせるとき、一連の代わりにストリングのグループに対して合っているのは頻繁に便利です。 この理由で、ストリングのリストは多くのテストで許容されています、テストがストリングに関していくらか1つを使用することで本当であるならテストが本当であることを含意して。 実現がこれらの場合に短絡評価を使用するよう奨励されます。
Showalter Standards Track [Page 7] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[7ページ]: 2001年1月に言語をフィルターにかけるメール
For instance, the test `header :contains ["To", "Cc"] ["me@example.com", "me00@landru.example.edu"]' is true if either the To header or Cc header of the input message contains either of the e-mail addresses "me@example.com" or "me00@landru.example.edu".
例えば、テスト'ヘッダー:contains[“To"、「cc」][" me@example.com "、" me00@landru.example.edu "]'がどちらかなら本当である、ヘッダーかccに、入力メッセージのヘッダーはEメールアドレス" me@example.com "か" me00@landru.example.edu "のどちらかを含んでいます。
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] [RFC1123], 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][RFC1123]では、それぞれのヘッダー線は線、フィールド名の後とその後のコロンの前の包含でどこでも空白をほとんど持つことができます。 そして、「ヘッダーの間の余分な空間が命名する、」、:、」 ヘッダーフィールドでは、無視されます。
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:」に合わないでしょう。 引きずっているコロンのため。
Folding of long header lines (as described in [IMAIL] 3.4.8) is removed prior to interpretation of the data. The folding syntax (the CRLF that ends a line plus any leading whitespace at the beginning of the next line that indicates folding) are interpreted as if they were a single space.
長いヘッダー線の折り重なり、([IMAIL]で説明される、3.4、.8、)、データの解釈の前に取り除きます。 折りたたみの構文(折り重なりを示す次の線の始めに線とどんな主な空白も終わらせるCRLF)はまるでそれらがシングルスペースであるかのように解釈されます。
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. Using the symbols defined in [IMAIL], section 6.1, the syntax of an address is:
多くのコマンドがEメールアドレスを求めます。(また、Eメールアドレスはストリングの部分集合です)。 これらのアドレスが外国行きの文脈で使用されるとき、アドレスは、[IMAIL]と共に言いなりにならなければなりませんが、さらに抑制されます。 [IMAIL]、セクション6.1で定義されたシンボルを使用して、アドレスの構文は以下の通りです。
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 used here.
すなわち、ルートとグループ構文は受入れられません。 複数のアドレスが必要であるなら、ストリングリストを使用してください。 命名されたグループはここで使用されません。
Implementations MUST ensure that the addresses are syntactically valid, but need not ensure that they actually identify an email recipient.
アドレスが確実にシンタクス上有効になるようにしなければなりませんが、実現は、実際にメール受取人を特定するのを確実にする必要はありません。
Showalter Standards Track [Page 8] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[8ページ]: 2001年1月に言語をフィルターにかけるメール
2.4.2.4. MIME Parts
2.4.2.4. MIMEの部品
In a few places, [MIME] body parts are represented as strings. These parts include MIME headers and the body. This provides a way of embedding typed data within a Sieve script so that, among other things, character sets other than UTF-8 can be used for output messages.
いくつかの場所では、[MIME]身体の部分がストリングとして表されます。 これらの部品はMIMEヘッダーとボディーを含んでいます。 これは出力メッセージにUTF-8以外の文字の組を特に使用できるようにSieveスクリプトの中でタイプされたデータを埋め込む方法を提供します。
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/else to decide which block of code is run.
彼らの動作を制御するために議論としてテストをコマンドに与えます。 本書では、コードのどのブロックについて決めるかためにはelsifであるかほかの/を走らせるなら、テストを与えます。
Tests MUST NOT have side effects. That is, a test cannot affect the state of the filter or message. No tests in this specification have side effects, and side effects are forbidden in extension tests as well.
テストには、副作用があってはいけません。 すなわち、テストはフィルタかメッセージの状態に影響できません。 この仕様に基づくどんなテストも、副作用、および副作用はまた、拡大テストで禁じられていません。
The rationale for this is that tests with side effects impair readability and maintainability and are difficult to represent in a graphic interface for generating scripts. Side effects are confined to actions where they are clearer.
これのための原理は副作用に伴うテストは読み易さと保守性を損なって、スクリプトを作るためにグラフィックインタフェースに表すのが難しいということです。 それらが、より明確であるところに副作用は動作に閉じ込められます。
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.
いくつかのテスト(それぞれ論理的な“and"と論理的な“or"を実行する"allof"と"anyof")が議論としてただ一つのテスト以上を必要とするかもしれません。 試リスト構文要素はテストを分類する方法を提供します。
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.edu") {
discard;
}
例: anyofである、(存在していない、[“From"、「日付」]ヘッダー:contains“from"" fool@example.edu ")破棄。
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つのタイプの議論があります: 位置であって、タグ付けされて、任意です。
2.6.1. Positional Arguments
2.6.1. 位置の議論
Positional arguments are given to a command which 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.
彼らのオーダーに基づくそれらの意味について明察するコマンドに位置の議論を与えます。 コマンドが位置の議論を取るとき、すべての位置の議論は、供給しなければならなくて、定められた順序に従って供給するに違いありません。
Showalter Standards Track [Page 9] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[9ページ]: 2001年1月に言語をフィルターにかけるメール
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 numbers or strings 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 with commands, but they still may be reordered arbitrarily provided they appear before positional arguments. Tagged arguments may be mixed with optional arguments.
タグ付けをされた議論は位置の議論の前に現れなければなりませんが、それらは他のタグ付けをされた議論と共に順不同に現れるかもしれません。 仕様の簡単さにおいて、これはコマンドで構文定義では表現されませんが、位置の議論の前に現れるなら、それらはまだ任意に再命令されているかもしれません。 タグ付けをされた議論は任意の議論に混ぜられるかもしれません。
To simplify this specification, 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 [ACAP] comparator will be used to compare two strings, since different languages may impose different orderings on UTF-8 [UTF-8] characters.
「1つの特に注目に値するケースがそう、」 : 異なった言語が課すかもしれないので、」 ユーザがその[ACAP]比較器を指定できる議論がそうする比較器が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 9.2 presents a parsable version of this: Arguments are string-lists, numbers, and tags, which may be followed
しかしながら、この抽象化は構文解析見地からあいまいです。 セクション9.2の文法はこの「パー-可能」バージョンを提示します: 議論は、いうことになられるかもしれないストリングリストと、数と、タグです。
Showalter Standards Track [Page 10] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[10ページ]: 2001年1月に言語をフィルターにかけるメール
by a test or a test-list, which may be followed by a block of commands. No more than one test or test list, nor more than one block of commands, may be used, and commands that end with blocks of commands do not end with semicolons.
テストか試リストで。(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 borrows ACAP's comparator registry.
文字集合と大文字小文字の同一視とのマッチに備えるために、SieveはACAPの比較器登録を借ります。
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. タイプを合わせてください。
There are three match types describing the matching used in this specification: ":is", ":contains", and ":matches". Match type arguments are supplied to those commands which allow them to specify what kind of match is to be performed.
この仕様で使用されるマッチングについて説明する3つのマッチタイプがあります: 「「:、」、」、:、」 」 : マッチを含んでいる、」 それらが、どういうマッチが実行されることになっていたらよいかを指定できるそれらのコマンドにマッチタイプ議論を供給します。
These are used as tagged arguments to tests that perform string comparison.
働くテストへのタグ付けをされた議論が比較を結ぶとき、これらは使用されています。
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 null 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 null key ":is" and only ":is" the null value.
「」 : 」 マッチタイプが絶対マッチについて説明するということです。 最初のストリングの内容が2番目のストリングのコンテンツと絶対に同じであるなら、それらは合っています。 ストリングだけ"frobnitzm"はストリング"frobnitzm"です。 「ヌルキー」:、」、唯一、」 : 」 ヌルは値ですか?
The ":matches" version specifies a wildcard match using the characters "*" and "?". "*" matches zero or more characters, and "?" matches a single character. "?" 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番目のバックスラッシュから逃げます。 彼らは「*」から一緒に、逃げます。 これは無器用ですが、それは塊と正規表現を使用するいくつかのプログラミング言語で平凡です。
Showalter Standards Track [Page 11] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[11ページ]: 2001年1月に言語をフィルターにかけるメール
In order to specify what type of match is supposed to happen, commands that support matching take optional tagged arguments ":matches", ":is", and ":contains". Commands default to using ":is" matching if no match type argument is supplied. Note that these modifiers may interact with comparators; in particular, some comparators are not 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.
「どんなタイプのマッチが起こると思われて、それを命令するかを指定するには、」 : 合っている撮影任意のタグ付けをされた議論がマッチであるとサポートしてください」、」、:、」、」、:、含有、」 「コマンドは使用をデフォルトとする」: 」 マッチタイプ議論を全く供給しないなら、合っています。 これらの修飾語が比較器と対話するかもしれないことに注意してください。 「特に、合いくつかの比較器が適当でないである」:、」 」 : マッチを含んでいる、」 「それは比較器を使用する誤りです」: それと互換性がなかった状態で」 」 : マッチを含んでいます。
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. 文字コードの向こう側の比較
All Sieve scripts are represented in UTF-8, but messages may involve a number of character sets. In order for comparisons to work across character sets, implementations SHOULD implement the following behavior:
すべてのSieveスクリプトがUTF-8に表されますが、メッセージは多くの文字集合にかかわるかもしれません。 比較が文字集合の向こう側に扱うように、実装SHOULDは以下の振舞いを実装します:
Implementations decode header charsets to UTF-8. Two strings are
considered equal if their UTF-8 representations are identical.
Implementations should decode charsets represented in the forms
specified by [MIME] for both message headers and bodies.
Implementations must be capable of decoding US-ASCII, ISO-8859-1,
the ASCII subset of ISO-8859-* character sets, and UTF-8.
実装はヘッダーcharsetsをUTF-8に解読します。 彼らのUTF-8表現が同じであるなら、2個のストリングが等しいと考えられます。 実装は[MIME]によってメッセージヘッダーとボディーの両方に指定されたフォームに表されたcharsetsを解読するべきです。 実装は米国-ASCII、ISO-8859-1、ISO8859*文字集合、およびUTF-8のASCII部分集合を解読できなければなりません。
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. Comparators are described for [ACAP]; a registry is defined for ACAP, and this specification uses that registry.
言語から独立していて、ケースから独立しているマッチを考慮するために、マッチタイプは比較器名に結びつけられるかもしれません。 比較器は[ACAP]のために説明されます。 登録はACAPのために定義されます、そして、この仕様はその登録を使用します。
ACAP defines multiple comparator types. Only equality types are used in this specification.
ACAPは複数の比較器タイプを定義します。 平等タイプだけがこの仕様で使用されます。
Showalter Standards Track [Page 12] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[12ページ]: 2001年1月に言語をフィルターにかけるメール
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 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 and use a comparator with ":matches" or ":contains" that is not compatible with it.
いくつかの比較器はサブストリングマッチで使用可能でないかもしれません。 「すなわち、彼らは働いているだけであるかもしれない」:、」 または、「それは」 : マッチで比較器を使用してみる誤りです」、」、:、含有、」 それはそれと互換性がありません。
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 2.10.5.)
iを除いたASCII-casemapを申告しなければならない比較器(八重奏とi)が、それらが拡大であるので、必要です。 比較器が宣言した、必要である、知られないで、それは誤りであり、実行は失敗します。 比較器で宣言されない、必要である、また、比較器が支えられても、それは誤りです。 (.5に2.10を見ます)
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
アドレスはストリングとして表される中で最も頻繁なことの1つです。 これらが構造化されて、地方の部分かアドレスのドメインに対して比較できるのが役に立つので、或るものはその行為をテストします。
Showalter Standards Track [Page 13] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[13ページ]: 2001年1月に言語をフィルターにかけるメール
exclusively on addresses take an additional optional argument that specifies what the test acts on.
排他的にアドレスでは、テストが影響するものを指定する追加任意の議論を取ってください。
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、」、」、: ドメイン、」 」 : すべて」、地方の部分(左側)、ドメイン部分(正しい側)、および全体のアドレスに影響する。
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. Blocks are supplied to commands so that the commands can implement control commands.
ブロックは巻き毛の支柱の中に同封されたコマンドのセットです。 コマンドが、コントロールがコマンドであると実装することができるように、ブロックをコマンドに提供します。
A control structure is a command that happens to take a test and a block as one of its arguments; depending on the result of the test supplied as another argument, it runs the code in the block some number of times.
制御構造は議論の1つとしてたまたまテストとブロック取るコマンドです。 別の議論として供給されたテストの結果によって、それは或るものが付番する回のブロックでコードを実行します。
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. So there are two arguments, the test and the block.
このメモでコマンドを供給していて、輪が全くありません。 構造が供給したコントロール--、elsifに、ほかに、ブロックを一度か全く動かさないでください。 それで、2つの議論、テスト、およびブロックがあります。
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.
最も簡単であるのは、動作命令です。 動作命令はゼロがいうことになった識別子であるか以上がセミコロンによって終えられた議論です。 動作命令は議論としてテストか何ブロックもみなしません。
Showalter Standards Track [Page 14] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[14ページ]: 2001年1月に言語をフィルターにかけるメール
A control command is similar, but it takes a test as an argument, and ends with a block instead of a semicolon.
制御コマンドが同様ですが、それは、議論としてテストをみなして、ブロックがセミコロンの代わりにある状態で、終わります。
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 4.4) performed in absence of any action that cancels the implicit keep.
暗黙の生活費は暗黙の生活費を取り消すどんな動作の欠如でも実行された生活費動作(4.4を見る)です。
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 will.
いくつかの動作は暗黙が保つどんなキャンセルとも定義されないかもしれません。 これらの動作は、直接メッセージの配送に影響しないかもしれなくて、それらの副作用に使用されます。 本書では指定された動作のいずれもその評価基準を満たしませんが、拡大動作は満たすでしょう。
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.
その結果、暗黙の生活費を取ります。
2.10.3. Message Uniqueness in a Mailbox
2.10.3. メールボックスの中のメッセージのユニークさ
Implementations SHOULD NOT deliver a message to the same folder more than once, even if a script explicitly asks for a message to be written to a mailbox twice.
実装SHOULD NOTは一度より同じフォルダーにメッセージを提供します、スクリプトが明らかに二度メールボックスに書かれるべきメッセージを求めても。
Showalter Standards Track [Page 15] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[15ページ]: 2001年1月に言語をフィルターにかけるメール
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 numbers 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.
動作のサイト方針5月の限界番号は、取って、動作を一緒に使用できる制限を課すかもしれません。 スクリプトが特定のメッセージに取られた行動の数における方針限界を打つ場合、誤りは発生します。
Implementations MUST prohibit more than one reject.
実装は1個以上の廃棄物を禁止しなければなりません。
Implementations MUST allow at least one keep or one fileinto. If fileinto is not implemented, implementations MUST allow at least one keep.
実装は少なくともある生活費かあるfileintoを許容しなければなりません。 fileintoが実装されないなら、実装は少なくともある生活費を許容しなければなりません。
Implementations SHOULD prohibit reject when used with other actions.
他の動作と共に使用されると、実装SHOULDは廃棄物を禁止します。
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.
拡大が「必要」で可能にされないなら、まるでそれを全くサポートしないかのように実装はそれを扱わなければなりません。
If a script does not understand an extension declared with require, the script must not be used at all. Implementations MUST NOT execute scripts which require unknown capability names.
スクリプトが、拡大が宣言したのを理解していない、必要である、スクリプトを全く使用してはいけません。 実装は未知の能力名を必要とするスクリプトを作成してはいけません。
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などの言語の先の経験が、これが与えられたスクリプトが拡張子を使用することに注意する実行可能な方法であると示唆するということです。
Experience with PostScript suggests that mechanisms that allow
a script to work around missing extensions are not used in
practice.
ポストスクリプトの経験は、スクリプトが問題に取りかかる拡大を逃すメカニズムが実際には使用されないのを示します。
Extensions which define actions MUST state how they interact with actions discussed in the base specification.
動作を定義する拡大はそれらがどう基礎仕様で議論した動作と対話するかを述べなければなりません。
Showalter Standards Track [Page 16] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[16ページ]: 2001年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 might even go so far as to ensure that scripts can never execute an invalid set of actions (e.g., reject + fileinto) before execution, although this could involve solving the Halting Problem.
実装は、スクリプトが実行の前に無効のセットの機能(例えば、廃棄物+fileinto)を決して、実行できないのを保証さえするかもしれません、これが、Halting Problemを解決することを伴うかもしれませんが。
This specification allows any of these approaches. Solving the Halting Problem is considered extra credit.
この仕様はこれらのアプローチのいずれも許容します。 Halting Problemを解決するのは付加的なクレジットであると考えられます。
When an error happens, implementations MUST notify the user that an error occurred, 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のレベルの入れ子にされたテストリストをサポートしなければなりません。
3. Control Commands
3. 制御コマンド
Control structures are needed to allow for multiple and conditional actions.
制御構造が、複数の、そして、条件付きの動きを考慮するのに必要です。
Showalter Standards Track [Page 17] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[17ページ]: 2001年1月に言語をフィルターにかけるメール
3.1. Control Structure 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 MUST only follow an if, and an else MUST follow only either an if or an elsif. An error occurs if these conditions are not met.
スリーピースがある、: "if"、"elsif"、および「ほかに。」 文法でそれぞれが実際に別々のコマンドです。しかしながら、elsifが続くだけでよい、ほか、続かなければならない、または、elsif。 これらの条件が満たされないなら、誤りは発生します。
Syntax: if <test1: test> <block1: block>
構文: <test1であるなら: ><block1をテストしてください: ブロック>。
Syntax: elsif <test2: test> <block2: block>
構文: elsif<test2: ><block2をテストしてください: ブロック>。
Syntax: else <block>
構文: ほかの<ブロック>。
The semantics are similar to those of any of the many other programming languages these control commands 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 case.
インタプリタがelsifsを使い果たすとき、」の「ほかケースがあるかもしれません。 または、あるか、そして、なにも、elsifテストは本当に、インタプリタがほかのケースを動かすということでした。
This provides a way of performing exactly one of the blocks in the chain.
これはちょうどチェーンでのブロックの1つを実行する方法を提供します。
In the following example, both Message A and B are dropped.
以下の例では、Message 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「受信トレイ」。
When the script below is run over message A, it redirects the message to acm@example.edu; message B, to postmaster@example.edu; any other message is redirected to field@example.edu.
以下のスクリプトがメッセージAの上に実行されると、それは acm@example.edu; にメッセージを向け直します。 postmaster@example.edu; へのメッセージB いかなる他のメッセージも field@example.edu に向け直されます。
Showalter Standards Track [Page 18] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[18ページ]: 2001年1月に言語をフィルターにかけるメール
Example: if header :contains ["From"] ["coyote"] {
redirect "acm@example.edu";
} elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.edu";
} else {
redirect "field@example.edu";
}
例: 「ヘッダー:contains[“From"][「コヨーテ」]である、再直接の" acm@example.edu ";、elsifヘッダー:contains、「かける」、」、再直接の" postmaster@example.edu ";、ほか再直接の" field@example.edu "。
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 Structure Require
3.2. 構造が必要とするコントロール
Syntax: 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 Structure Stop
3.3. 制御構造停止
Syntax: stop
構文: 停止
The "stop" action ends all processing. If no actions have been executed, then the keep action is taken.
「停止」動作はすべての処理を終わらせます。 動作を全く実行していないなら、生活費行動を取ります。
4. Action Commands
4. 動作命令
This document supplies five actions that may be taken on a message: keep, fileinto, redirect, reject, and discard.
このドキュメントはメッセージで取られるかもしれない5つの行動を供給します: 保って、fileintoして、向け直して、拒絶して、捨てます。
Implementations MUST support the "keep", "discard", and "redirect" actions.
実装は、「保ってください」、「破棄」をサポートして、動作を「向け直さなければなりません」。
Implementations SHOULD support "reject" and "fileinto".
実装SHOULDは「廃棄物」と"fileinto"をサポートします。
Showalter Standards Track [Page 19] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[19ページ]: 2001年1月に言語をフィルターにかけるメール
Implementations MAY limit the number of certain actions taken (see section 2.10.4).
実装は取られたある行動の数を制限するかもしれません(セクション2.10.4を見てください)。
4.1. Action reject
4.1. 動作廃棄物
Syntax: reject <reason: string>
構文: <理由を拒絶してください: ストリング>。
The optional "reject" action refuses delivery of a message by sending back an [MDN] to the sender. It resends the message to the sender, wrapping it in a "reject" form, noting that it was rejected by the recipient. In the following script, message A is rejected and returned to the sender.
任意の「廃棄物」動作は、[MDN]を送付者に返送することによって、メッセージの配送を拒否します。 それは送付者にメッセージを再送します、「廃棄物」フォームでそれを包装して、それが受取人によって拒絶されたことに注意して。 以下のスクリプトで、メッセージAを送付者に拒絶して、返します。
Example: if header :contains "from" "coyote@desert.example.org" {
reject "I am not taking mail from you, and I don't want
your birdseed, either!";
}
例: ヘッダー:contains“from"" coyote@desert.example.org "です。廃棄物、「私はあなたからメールを取っていません、そして、あなたの粒餌が欲しいと思いません!」。
A reject message MUST take the form of a failure MDN as specified by [MDN]. The human-readable portion of the message, the first component of the MDN, contains the human readable message describing the error, and it SHOULD contain additional text alerting the original sender that mail was refused by a filter. This part of the MDN might appear as follows:
廃棄物メッセージは指定されるとしての[MDN]による失敗MDNの形を取らなければなりません。 メッセージの人間読み込み可能な部分(MDNの最初の部品)は、誤り、およびそれについて説明しながら、人間の読み込み可能なメッセージを含んでいます。メールがフィルタによって拒否されたと元の送り主に警告しながら、SHOULDは追加テキストを含んでいます。 MDNのこの部分は以下の通りに見えるかもしれません:
------------------------------------------------------------ Message was refused by recipient's mail filtering program. Reason given was as follows:
------------------------------------------------------------ メッセージは受取人のメールフィルタリングプログラムで拒否されました。 あげられた理由は以下の通りでした:
I am not taking mail from you, and I don't want your birdseed, either! ------------------------------------------------------------
私はあなたからメールを取っていません、そして、あなたの粒餌が欲しいと思いません! ------------------------------------------------------------
The MDN action-value field as defined in the MDN specification MUST be "deleted" and MUST have the MDN-sent-automatically and automatic- action modes set.
MDN仕様に基づき定義されるMDN動作価値の分野で、「削除されなければならなく」て、MDNが自動的に発信していて自動である動作モードを設定しなければなりません。
Because some implementations can not or will not implement the reject command, it is optional. The capability string to be used with the require command is "reject".
いくつかの実装が実装しないか、または拒絶コマンドを実装することができないので、それは任意です。 必要コマンドと共に使用されるべき能力ストリングは「廃棄物」です。
4.2. Action fileinto
4.2. 動作fileinto
Syntax: fileinto <folder: string>
構文: fileinto<フォルダー: ストリング>。
The "fileinto" action delivers the message into the specified folder. Implementations SHOULD support fileinto, but in some environments this may be impossible.
"fileinto"動作は指定されたフォルダーにメッセージを提供します。 実装SHOULDはfileintoをサポートしますが、いくつかの環境で、これは不可能であるかもしれません。
Showalter Standards Track [Page 20] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[20ページ]: 2001年1月に言語をフィルターにかけるメール
The capability string for use with the require command is "fileinto".
必要コマンドによる使用のための能力ストリングは"fileinto"です。
In the following script, message A is filed into folder "INBOX.harassment".
以下のスクリプトで、メッセージAはフォルダー"INBOX.harassment"にファイルされます。
Example: require "fileinto";
if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment";
}
例: "fileinto"を必要としてください。 ヘッダー:contains[“from"]「コヨーテ」です。fileinto"INBOX.harassment"。
4.3. Action redirect
4.3. 動作再直接です。
Syntax: 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 headers, but it may add new headers. The "redirect" modifies the envelope recipient.
「再直接」の動作は供給されたアドレスの別のユーザにメッセージを送るのに使用されます、推進機能がするメールとして。 「再直接」の動作はメッセージ本体か既存のヘッダーへの変更を全く行いませんが、それは新しいヘッダーを加えるかもしれません。 「再直接」は封筒受取人を変更します。
The redirect command performs an MTA-style "forward"--that is, what you get from a .forward file using sendmail under UNIX. The address on the SMTP envelope is replaced with the one on the redirect command and the message is sent back out. (This is not an MUA-style forward, which creates a new message with a different sender and message ID, wrapping the old message in a new one.)
向け直しコマンドは「前方に」MTA-スタイルを実行します--すなわち、あなたがUNIXの下にsendmailを使用する.forwardファイルから得るもの。 SMTP封筒の上のアドレスを向け直しコマンドでのものに取り替えます、そして、メッセージを出して戻します。 (これはMUA-スタイルフォワードではありません、新しいものにおける古いメッセージを包装して。)(フォワードは異なった送付者とメッセージIDで新しいメッセージを作成します)。
A simple script can be used for redirecting all mail:
すべてのメールを転送するのに簡単なスクリプトを使用できます:
Example: redirect "bart@example.edu";
例: " bart@example.edu "を向け直してください。
Implementations SHOULD take measures to implement loop control, possibly including adding headers to the message or counting received headers. If an implementation detects a loop, it causes an error.
ことによるとヘッダーをメッセージに追加するのを含んでいるか、または容認されたヘッダーを数えて、実装SHOULDはループ制御を実装する対策を実施します。 実装が輪を検出するなら、それは誤りを引き起こします。
4.4. Action keep
4.4. 動作は保たれます。
Syntax: 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 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.
「保ってください」という動作はフィルターにかけないことが少しでも起こるなら他のすべての動作の代わりに取られるどういった行動です。 一般に、これは、ユーザの主なメールボックスの中にメッセージをファイルすることを単に意味します。 このコマンドはユーザの主なメールボックスの名前を知る必要はなくてこの動作を実行する方法を提供します、ユーザのセットアップ、または基本的なメールシステムを理解する必要はなくてそれを呼ぶ方法を提供して。
Showalter Standards Track [Page 21] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[21ページ]: 2001年1月に言語をフィルターにかけるメール
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.5. Action discard
4.5. 動作破棄
Syntax: 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.edu" is thrown out.
以下のスクリプトで、" idiot@example.edu "からのどんなメールも放り出されます。
Example: if header :contains ["from"] ["idiot@example.edu"] {
discard;
}
例: ヘッダー:contains[“from"][" idiot@example.edu "]です。破棄。
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.
この言語の重要な部分である間、「破棄」には、ユーザのための深刻な問題を作成する可能性があります: 自分たちが公立のコンピュータ室で無人のマシンにログインされる状態で残す学生はまさしく「捨てる」ために変えられた彼らのスクリプトを見つけるかもしれません。 この状況(同様の状況に伴う)でユーザを保護するために、実現は、無期限にスクリプトでメッセージを無効にしておいて、すべてのメールを放り出すスクリプトを禁じるかもしれません。
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は「封筒」テストを支持します。
Showalter Standards Track [Page 22] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[22ページ]: 2001年1月に言語をフィルターにかけるメール
5.1. Test address
5.1. テストアドレス
Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
構文: [ADDRESS-PART][COMPARATOR][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.
アドレステストはアドレスを含む構造化されたヘッダーでインターネット・アドレスに合っています。 どれかヘッダーがアドレスの指定された部分に何かキーを含んでいるなら、それは本当に戻ります、比較器とマッチキーワードによって変更されるように。
Like envelope and header, this test returns true if any combination of the header-list and key-list arguments match.
封筒とヘッダーのように、このテストはヘッダーリストのどんな組み合わせであるならも本当に戻ります、そして、主要なリスト議論は合っています。
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, nor 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, Resent-To, and 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 "である、捨ててください。
5.2. Test allof
5.2. テストallof
Syntax: 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テストは議論として試リストをみなします。
Showalter Standards Track [Page 23] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[23ページ]: 2001年1月に言語をフィルターにかけるメール
5.3. Test anyof
5.3. テストanyof
Syntax: 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. テスト封筒
Syntax: 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.
SMTP(または、同等物)封筒の指定された部分が指定されたキーに合っているなら、「封筒」テストは本当です。
If one of the envelope-part strings is (case insensitive) "from", then matching occurs against the FROM address used in the SMTP MAIL command.
封筒部分ストリングの1つが(大文字と小文字を区別しない)の“from"であるなら、マッチングはSMTP MAILコマンドに使用されるFROMアドレスに対して起こります。
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つ以上のパラメタを含むかもしれません、その場合、主要なリストで指定されたストリングのすべては封筒部分リストで与えられたすべての部品に取り組まされます。
Like address and header, this test returns true if any combination of the envelope-part and key-list arguments is true.
アドレスとヘッダーのように、封筒部分と主要なリスト議論の何か組み合わせが正しいなら、このテストは本当に戻ります。
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.
封筒コマンドは任意です。 実現SHOULDはそれを支持しますが、必要事項はすべての場合では利用可能でないかもしれません。
Showalter Standards Track [Page 24] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[24ページ]: 2001年1月に言語をフィルターにかけるメール
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
例: 「封筒」を必要としてください。 封筒:all:is“from"" tim@example.com "です。破棄。
5.5. Test exists
5.5. テストは存在しています。
Syntax: 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. 虚偽でテストしてください。
Syntax: false
構文: 誤る
The "false" test always evaluates to false.
「誤り」テストがいつも誤っているのに評価する。
5.7. Test header
5.7. テストヘッダー
Syntax: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
構文: ヘッダー[COMPARATOR][MATCH-TYPE]<ヘッダー名: >の<の主要なリストをストリングでリストアップしてください: ストリングリスト>。
The "header" test evaluates to true if any header name 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 string-list and key-list arguments match.
アドレスと封筒のように、このテストはストリングリストのどんな組み合わせであるならも本当に戻ります、そして、主要なリスト議論は合っています。
If a header listed in the header-names argument exists, it contains
the null key (""). However, if the named header is not present, it
does not contain the null key. So if a message contained the header
ヘッダー名の引数で記載されたヘッダーが存在しているなら、ヌルキーを含んでいる、(「「)、」 しかしながら、命名されたヘッダーが出席していないなら、それはヌルキーを含んでいません。 そのようにメッセージがヘッダーを含んだなら
X-Caffeine: C8H10N4O2
X-カフェイン: C8H10N4O2
Showalter Standards Track [Page 25] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[25ページ]: 2001年1月に言語をフィルターにかけるメール
these tests on that header evaluate as follows:
そのヘッダーのこれらのテストは以下の通り以下を評価します。
header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true
ヘッダー:is[「X-カフェイン」]、[「「]、>の偽のヘッダー:contains[「X-カフェイン」]と等しい、[「「]、本当に>と等しい、」
5.8. Test not
5.8. テスト
Syntax: not <test>
構文: <テスト>でない
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. テストサイズ
Syntax: 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番号があとに続きます。
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 from the initial header until the last character in the message body.
メッセージのサイズは、初期のメッセージ本体における最後のキャラクタまでのヘッダーからの八重奏の数になるように定義されます。
Note that for a message that is exactly 4,000 octets, the message is neither ":over" 4000 octets or ":under" 4000 octets.
「まさに4,000の八重奏であるメッセージに関してメッセージがどちらもでないメモ」:、」 : 」 4000の八重奏か下、」 4000の八重奏。
5.10. Test true
5.10. 本当にテストしてください。
Syntax: true
構文: 本当
The "true" test always evaluates to true.
テストがいつも本当に評価する「本当さ」。
6. Extensibility
6. 伸展性
New control structures, 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.
新しい制御構造、動作、およびテストを言語に追加できます。 サイトは彼らのユーザにこれらの特徴を明らかにしなければなりません。 このドキュメントはサーバで後押しされている拡大のリストを発見する方法を定義しません。
Showalter Standards Track [Page 26] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[26ページ]: 2001年1月に言語をフィルターにかけるメール
Any extensions to this language MUST define a capability string that uniquely identifies that extension. If a new version of an extension changes the functionality of a previously defined extension, it MUST use a different name.
この言語へのどんな拡大も唯一その拡大を特定する能力ストリングを定義しなければなりません。 拡大の新しいバージョンが以前に定義された拡大の機能性を変えるなら、それは変名を使わなければなりません。
In a situation where there is a 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.
拡大はそれらがどの動作とどのようにセクション2.10で定義された規制と対話して、例えば、それらに暗黙を取り消させるかどうかが続くか、そして、互換性があって非互換であるかを述べなければなりません。
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:
以下の能力ストリングはこのドキュメントによって定義されます:
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"コマンドをサポートするのを示します。
reject The string "reject" indicates that the implementation
supports the "reject" command.
ストリングが「拒絶する」廃棄物は、実現が「拒絶」コマンドをサポートするのを示します。
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する」能力。 しかしながら、これらの比較器は宣言されると共に使用されるかもしれません。必要です。
Showalter Standards Track [Page 27] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[27ページ]: 2001年1月に言語をフィルターにかけるメール
6.2. IANA Considerations
6.2. IANA問題
In order to provide a standard set of extensions, a registry is provided by IANA. Capability names may be registered on a first- come, first-served basis. Extensions designed for interoperable use SHOULD be defined as standards track or IESG approved experimental RFCs.
拡大の標準セットを提供するために、登録はIANAによって提供されます。 登録されていて、名前がそうするかもしれない能力は、第1で来て、最初に、基礎に役立ちました。 拡大は共同利用できる使用のためにSHOULDを設計しました。標準化過程かIESGの承認された実験的なRFCsと定義されます。
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: Capability keyword: Capability arguments: Standards Track/IESG-approved experimental RFC number: Person and email address to contact for further information:
能力名: 能力キーワード: 能力議論: 規格は実験RFC番号をTrack/IESG承認しました: 詳細のために連絡する人とEメールアドレス:
6.2.2. Initial Capability Registrations
6.2.2. 初期の能力登録証明書
The following are to be added to the IANA registry for Sieve extensions as the initial contents of the capability registry.
以下はSieve拡張子のために能力登録の初期のコンテンツとしてIANA登録に加えられることになっています。
Capability name: fileinto
Capability keyword: fileinto
Capability arguments: fileinto <folder: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
能力名: fileinto Capabilityキーワード: fileinto Capability議論: fileinto<フォルダー: ストリング>は実験RFC番号をStandards Track/IESG承認しました: RFC3028(ふるいのベース仕様)人と詳細のために連絡するEメールアドレス: ティムショウォーター tjs@mirapoint.com
Capability name: reject
Capability keyword: reject
Capability arguments: reject <reason: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
能力名: Capabilityキーワードを拒絶してください: Capability議論を拒絶してください: <理由を拒絶してください: ストリング>は実験RFC番号をStandards Track/IESG承認しました: RFC3028(ふるいのベース仕様)人と詳細のために連絡するEメールアドレス: ティムショウォーター tjs@mirapoint.com
Showalter Standards Track [Page 28] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[28ページ]: 2001年1月に言語をフィルターにかけるメール
Capability name: envelope
Capability keyword: envelope
Capability arguments:
envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
能力名: 封筒Capabilityキーワード: 封筒Capability議論: 封筒[COMPARATOR][ADDRESS-PART][MATCH-TYPE]<封筒部分: >の<の主要なリストをストリングでリストアップしてください: ストリングリスト>は実験RFC番号をStandards Track/IESG承認しました: RFC3028(ふるいのベース仕様)人と詳細のために連絡するEメールアドレス: ティムショウォーター tjs@mirapoint.com
Capability name: comparator-*
Capability keyword:
comparator-* (anything starting with "comparator-")
Capability arguments: (none)
Standards Track/IESG-approved experimental RFC number:
RFC 3028, Sieve, by reference of
RFC 2244, Application Configuration Access Protocol
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
能力名: 比較器*能力キーワード: 比較器*(「比較器」から始める何でも)能力議論: (なにも) 規格は実験RFC番号をTrack/IESG承認しました: RFC3028、RFC2244、Application Configuration AccessプロトコルPerson、および詳細のために連絡するEメールアドレスの参照によるSieve: ティムショウォーター tjs@mirapoint.com
6.3. Capability Transport
6.3. 能力輸送
As the range of mail systems that this document is intended to apply to is quite varied, 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 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 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.
MIMEメディア型名: アプリケーションMIME「副-タイプ」は以下を命名します。 ふるいのRequiredパラメタ: なにも、Optionalパラメタ: なにも、Encoding問題: ほとんどのふるいのスクリプトが、UTF-8に原文で、書くようになるでしょう。 引用されて印刷可能な状態で使用される非7に噛み付いているキャラクタがいつかが輸送のために7ビットのコード化を必要とするシステムを当てます。
Showalter Standards Track [Page 29] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[29ページ]: 2001年1月に言語をフィルターにかけるメール
Security considerations: Discussed in section 10 of RFC 3028.
Interoperability considerations: Discussed in section 2.10.5
of RFC 3028.
Published specification: RFC 3028.
Applications which use this media type: sieve-enabled mail servers
Additional information:
Magic number(s):
File extension(s): .siv
Macintosh File Type Code(s):
Person & email address to contact for further information:
See the discussion list at ietf-mta-filters@imc.org.
Intended usage:
COMMON
Author/Change controller:
See Author information in RFC 3028.
セキュリティ問題: RFC3028のセクション10で、議論します。 相互運用性問題: .5セクション2.10RFC3028では、議論します。 広められた仕様: RFC3028。 このメディアタイプを使用するアプリケーション: ふるいで可能にされたメールサーバAdditional情報: マジックナンバー(s): ファイル拡張子(s): .sivマッキントッシュファイルタイプは(s)をコード化します: 詳細のために連絡する人とEメールアドレス: ietf-mta-filters@imc.org で議論リストを見てください。 意図している用法: COMMON Author/変化コントローラ: RFC3028のAuthor情報を見てください。
8. Parsing
8. 構文解析
The Sieve grammar is separated into tokens and a separate grammar as most programming languages are.
言語を最もプログラムするとき、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 ASCII.
ふるいのスクリプトはUTF-8でコード化されます。 以下は、有効なUTF-8がコード化していると仮定します。 Sieveスクリプトによる特殊文字はすべてASCIIです。
The following are tokens in Sieve:
↓これはSieveでの象徴です:
- identifiers
- tags
- numbers
- quoted strings
- multi-line strings
- other separators
- 識別子--タグ--数--引用文字列--マルチ線ストリング--他の分離符
Blanks, horizontal tabs, CRLFs, and comments ("white space") are
ignored except as they separate tokens. Some white space is required
to separate otherwise adjacent tokens and in specific places in the
multi-line strings.
空白、水平タブ、CRLFs、およびそれらを除いて、(「余白」)が無視されるというコメントは象徴を切り離します。 いくらかの余白が別々のそうでなければ、隣接している象徴とマルチ線ストリングの特定の場所で必要です。
The other separators are single individual characters, and are mentioned explicitly in the grammar.
他の分離符は、ただ一つの個性であり、文法で明らかに言及されます。
The lexical structure of sieve is defined in the following BNF (as described in [ABNF]):
ふるいの語彙構造は以下のBNFで定義されます([ABNF]で説明されるように):
Showalter Standards Track [Page 30] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[30ページ]: 2001年1月に言語をフィルターにかけるメール
bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
;; 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.)
「ブラケットコメントは」 /*と等しい」という*(炭のNOT星の/(「*」炭のNOTスラッシュ))、」 */、」、。 *はコメントで許容/されませんでした。 ;; (*が全くそれが最後のキャラクタでないなら許容されていない、それはaではありません; スラッシュがキャラクタによって後をつけられていない、)
CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
;; no dots, no CRLFs
どんなドットも焦げていない=(%x01-09/%x0b-0c/%x0e-2d/%x2f-ff)。 ドットがない、CRLFsがありません。
CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
どんなCRLFも焦げていない=(%x01-09/%x0b-0c/%x0e-ff)
CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
炭がなでぎりされなかった=(%x00-57/%x58-ff)
CHAR-NOT-STAR = (%x00-51 / %x53-ff)
炭に主演していない=(%x00-51/%x53-ff)
comment = bracket-comment / hash-comment
コメントは細切れ肉料理ブラケットコメント/コメントと等しいです。
hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
細切れ肉料理コメント=(「#」*炭NOT CRLF CRLF)
identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
識別子=(アルファー/"_")*(アルファケタ"_")
tag = ":" identifier
「タグ=」:、」 識別子
number = 1*DIGIT [QUANTIFIER]
数は1*DIGITと等しいです。[数量詞]
QUANTIFIER = "K" / "M" / "G"
数量詞=「K」/「M」/「G」
quoted-string = DQUOTE *CHAR DQUOTE
;; in general, \ CHAR inside a string maps to CHAR
;; so \" maps to " and \\ maps to \
;; note that newlines and other characters are all allowed
;; strings
引用文字列はDQUOTE*CHAR DQUOTEと等しいです。 一般に、\CHARはaで地図をCHARに結びます。 そして、「そのように、\、」 地図、「\が写像する\から\;、」、。 ニューラインと他のキャラクタが皆、許容されていることに注意してください。 ストリング
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multi-line-literal / multi-line-dotstuff)
"." CRLF
multi-line-literal = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
;; A line containing only "." ends the multi-line.
;; Remove a leading '.' if followed by another '.'.
マルチ線=、「テキスト:」 *(SP / HTAB) (細切れ肉料理コメント/CRLF) *(マルチ線文字通り、/マルチ線のdotstuff) "." 「CRLF、マルチ線文字通り、=[CHAR NOT DOT*CHAR-CRLFでない]CRLFマルチ線のdotstuffが等しい、」、」 1 *炭-CRLF CRLFでない。 「Aは含有だけを裏打ちします」。. 」 マルチ線を終わらせます。 ;; '先導を取り除いてください'。'別のものによって後をつけられているなら''
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 white space or comments appear below. The start symbol is "start".
それが辞書的に解釈された後に↓これはSieveの文法です。 どんな余白もコメントも以下に現れません。 開始記号は「始め」です。
Showalter Standards Track [Page 31] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[31ページ]: 2001年1月に言語をフィルターにかけるメール
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) ")"
試しに=を記載してください、「(「*をテストしてください、(「」、テスト)、」、)、」
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", "reject"];
# # 例のSieve Filter#Declare、スクリプト#で使用されるどんなオプション機能や拡張子も["fileinto"、「廃棄物」]を必要とします。
#
# Reject any large messages (note that the four leading dots get
# "stuffed" to three)
#
if size :over 1M
{
reject text:
Please do not send me large attachments.
Put your file on a server and send me the URL.
Thank you.
.... Fred
.
;
stop;
}
#
# # #1Mのサイズ:overであるならあらゆる大きいメッセージ(4つの主なドットが、#、が3まで「詰められること」を得ることに注意する)を拒絶してください。{ テキストを拒絶してください: 大きい付属を私に送らないでください。 ファイルをサーバに置いてください、そして、URLを私に送ってください。 ありがとうございます。 .... フレッド。 止まってください。 } #
Showalter Standards Track [Page 32] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[32ページ]: 2001年1月に言語をフィルターにかけるメール
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
fileinto "filter"; # move to "filter" folder
}
#
# Keep all messages to or from people in my company
#
elsif address :domain :is ["From", "To"] "example.com"
{
keep; # keep in "In" folder
}
# ヘッダー: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*"])
{
# If message header does not contain my address,
# it's from a list.
fileinto "spam"; # move to "spam" folder
}
else
{
# Move all other (non-company) mail to "personal"
# folder.
fileinto "personal";
}
# # 求められていないメールを捕らえてみてください。 メッセージが私に、スパムであることが知られている対象を含んでいるということでないなら、それを記録してください。 # ##メッセージヘッダーが私のアドレスを含んでいないなら、それはリストから来ています。「elsif anyof、(:all:contains[“To"、「cc」、"Bcc"]" me@example.com "、ヘッダー:matches「対象」を記述しない、[「**お金*を速い*にしてください」、」、*大学*のdipl*マス*、」、)、fileinto「スパム」; #動いて、フォルダーを「ばらまいてください」、ほかすべてのもう一方(非会社の)が「個人的な」#フォルダーfileinto「個人的に」郵送する#移動。
Showalter Standards Track [Page 33] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[33ページ]: 2001年1月に言語をフィルターにかけるメール
10. Security Considerations
10. セキュリティ問題
Users must get their mail. It is imperative that whatever method implementations use to store the user-defined filtering scripts be secure.
ユーザは彼らのメールを受け取らなければなりません。 実現がユーザによって定義されたフィルタリングスクリプトを格納するのに使用するどんな方法も安全であることは、必須です。
It is equally important that implementations sanity-check the user's scripts, and not allow users to create on-demand mailbombs. For instance, an implementation that allows a user to reject or redirect multiple times to a single message might also allow a user to create a mailbomb triggered by mail from a specific user. Site- or implementation-defined limits on actions are useful for this.
ユーザのものが原稿を書いて、ユーザを許容しない実現健全度チェックが要求次第のメールボムを作成するのは、等しく重要です。 例えば、また、ユーザがただ一つのメッセージに複数の回を拒絶するか、または向け直す実現で、ユーザはメールによって特定のユーザから引き起こされたメールボムを作成できるかもしれません。 動作におけるサイトか実現で定義された限界がこれの役に立ちます。
Several commands, such as "discard", "redirect", and "fileinto" allow for actions to be taken that are potentially very dangerous.
「破棄」などのような「再直接」のいくつかのコマンド、および"fileinto"は潜在的に非常に危険な取られるべき動きを考慮します。
Implementations SHOULD take measures to prevent languages from looping.
実現SHOULDは言語が輪にされるのを防ぐ対策を実施します。
11. Acknowledgments
11. 承認
I am very thankful to Chris Newman for his support and his ABNF syntax checker, to John Myers and Steve Hole for outlining the requirements for the original drafts, to Larry Greenfield for nagging me about the grammar and finally fixing it, to Greg Sereda for repeatedly fixing and providing examples, to Ned Freed for fixing everything else, to Rob Earhart for an early implementation and a great deal of help, and to Randall Gellens for endless amounts of proofreading. I am grateful to Carnegie Mellon University where most of the work on this document was done. I am also indebted to all of the readers of the ietf-mta-filters@imc.org mailing list.
クリス・ニューマンに、私は彼のサポートと彼のABNFシンタクスチェッカのために非常に感謝しています、オリジナルの草稿のための要件について概説するためのジョン・マイアーズとスティーブHoleに、文法に関して私に口喧しく言って、最終的にそれを修理するためのラリー・グリーンフィールドに、繰り返して例を修理して、提供するためのグレッグSeredaに、他の何もかもを修理するためのネッド・フリードに、早めの実現と大きな助けと、無限の量の校正のためのランドルGellensへのロブ・エアハートに。 私はこのドキュメントへの作業の大部分が行われたカーネギーメロン大学に感謝しています。 また、私も ietf-mta-filters@imc.org メーリングリストの読者のすべての世話になっています。
12. Author's Address
12. 作者のアドレス
Tim Showalter Mirapoint, Inc. 909 Hermosa Court Sunnyvale, CA 94085
ティムショウォーターMirapoint Inc.909Hermosa法廷サニーベル、カリフォルニア 94085
EMail: tjs@mirapoint.com
メール: tjs@mirapoint.com
13. References
13. 参照
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Showalter Standards Track [Page 34] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[34ページ]: 2001年1月に言語をフィルターにかけるメール
[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] ニューマン、C.、およびJ.G.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[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 1894, January
1996.
[DSN] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年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では、翻刻しました。
[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月。
[IMAP] Crispin, M., "Internet Message Access Protocol - version
4rev1", RFC 2060, December 1996.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットMessage Accessプロトコル--12月。」
[IMAIL] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[IMAIL] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[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月。
[MDN] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[MDN] Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[RFC1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, November 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、11月1989日
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode
and ISO 10646", RFC 2044, October 1996.
[UTF-8]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変化形式」RFC2044。
Showalter Standards Track [Page 35] RFC 3028 Sieve: A Mail Filtering Language January 2001
ショウォーターStandardsはRFC3028ふるいを追跡します[35ページ]: 2001年1月に言語をフィルターにかけるメール
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Showalter Standards Track [Page 36]
ショウォーター標準化過程[36ページ]
一覧
スポンサーリンク
