[要約] RFC 5228は、電子メールフィルタリング言語であるSieveについての規格です。このRFCの目的は、メールサーバーでの効果的なメールフィルタリングを可能にするための標準化と指針を提供することです。
Network Working Group P. Guenther, Ed.
Request for Comments: 5228 Sendmail, Inc.
Obsoletes: 3028 T. Showalter, Ed.
Category: Standards Track January 2008
Sieve: An Email Filtering Language
ふるい：電子メールフィルタリング言語
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.
このドキュメントでは、最終配信時に電子メールメッセージをフィルタリングするための言語について説明します。メールクライアントまたはメールサーバーのいずれかで実装できるように設計されています。これは、アクセスプロトコル、メールアーキテクチャ、オペレーティングシステムとは独立していることを意図しています。Base Languageには変数、ループ、またはシェルアウトする能力がないため、ブラックボックスインターネットメッセージアクセスプロトコル（IMAP）サーバーなど、ユーザーが任意のプログラムを実行することが許可されないメールサーバーでの実行に適しています。外部プログラム。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Example Mail Messages ......................................5
2. Design ..........................................................6
2.1. Form of the Language .......................................6
2.2. Whitespace .................................................7
2.3. Comments ...................................................7
2.4. Literal Data ...............................................7
2.4.1. Numbers .............................................7
2.4.2. Strings .............................................8
2.4.2.1. String Lists ...............................9
2.4.2.2. Headers ....................................9
2.4.2.3. Addresses .................................10
2.4.2.4. Encoding Characters Using
"encoded-character" .......................10
2.5. Tests .....................................................11
2.5.1. Test Lists .........................................12
2.6. Arguments .................................................12
2.6.1. Positional Arguments ...............................12
2.6.2. Tagged Arguments ...................................12
2.6.3. Optional Arguments .................................13
2.6.4. Types of Arguments .................................13
2.7. String Comparison .........................................13
2.7.1. Match Type .........................................14
2.7.2. Comparisons across Character Sets ..................15
2.7.3. Comparators ........................................15
2.7.4. Comparisons against Addresses ......................16
2.8. Blocks ....................................................17
2.9. Commands ..................................................17
2.10. Evaluation ...............................................18
2.10.1. Action Interaction ................................18
2.10.2. Implicit Keep .....................................18
2.10.3. Message Uniqueness in a Mailbox ...................19
2.10.4. Limits on Numbers of Actions ......................19
2.10.5. Extensions and Optional Features ..................19
2.10.6. Errors ............................................20
2.10.7. Limits on Execution ...............................20
3. Control Commands ...............................................21
3.1. Control if ................................................21
3.2. Control require ...........................................22
3.3. Control stop ..............................................22
4. Action Commands ................................................23
4.1. Action fileinto ...........................................23
4.2. Action redirect ...........................................23
4.3. Action keep ...............................................24
4.4. Action discard ............................................25
5. Test Commands ..................................................26
5.1. Test address ..............................................26
5.2. Test allof ................................................27
5.3. Test anyof ................................................27
5.4. Test envelope .............................................27
5.5. Test exists ...............................................28
5.6. Test false ................................................28
5.7. Test header ...............................................29
5.8. Test not ..................................................29
5.9. Test size .................................................29
5.10. Test true ................................................30
6. Extensibility ..................................................30
6.1. Capability String .........................................31
6.2. IANA Considerations .......................................31
6.2.1. Template for Capability Registrations ..............32
6.2.2. Handling of Existing Capability Registrations ......32
6.2.3. Initial Capability Registrations ...................32
6.3. Capability Transport ......................................33
7. Transmission ...................................................33
8. Parsing ........................................................34
8.1. Lexical Tokens ............................................34
8.2. Grammar ...................................................36
8.3. Statement Elements ........................................36
9. Extended Example ...............................................37
10. Security Considerations .......................................38
11. Acknowledgments ...............................................39
12. Normative References ..........................................39
13. Informative References ........................................40
14. Changes from RFC 3028 .........................................41
This memo documents a language that can be used to create filters for electronic mail. It is not tied to any particular operating system or mail architecture. It requires the use of [IMAIL]-compliant messages, but should otherwise generalize to many systems.
このメモは、電子メールのフィルターを作成するために使用できる言語を文書化しています。特定のオペレーティングシステムやメールアーキテクチャに関連付けられていません。[IMAIL]に準拠したメッセージを使用する必要がありますが、それ以外の場合は多くのシステムに一般化する必要があります。
The language is powerful enough to be useful but limited in order to allow for a safe server-side filtering system. The intention is to make it impossible for users to do anything more complex (and dangerous) than write simple mail filters, along with facilitating the use of graphical user interfaces (GUIs) for filter creation and manipulation. The base language was not designed to be Turing-complete: it does not have a loop control structure or functions.
言語は有用であるほど強力ですが、安全なサーバー側のフィルタリングシステムを可能にするために制限されています。意図は、フィルターの作成と操作のためにグラフィカルユーザーインターフェイス（GUI）の使用を促進するとともに、単純なメールフィルターを作成するよりも複雑な（そして危険）ことをユーザーが不可能にすることです。基本言語は、チューリングが完全になるように設計されていません。ループ制御構造や関数はありません。
Scripts written in Sieve are executed during final delivery, when the message is moved to the user-accessible mailbox. In systems where the Mail Transfer Agent (MTA) does final delivery, such as traditional Unix mail, it is reasonable to filter when the MTA deposits mail into the user's mailbox.
ふるいに記載されているスクリプトは、メッセージがユーザーアクセス可能なメールボックスに移動される最終配信中に実行されます。メール転送エージェント（MTA）が従来のUNIXメールなどの最終配信を行うシステムでは、MTAがユーザーのメールボックスにメールをデポジットするときにフィルタリングするのが妥当です。
There are a number of reasons to use a filtering system. Mail traffic for most users has been increasing due to increased usage of email, the emergence of unsolicited email as a form of advertising, and increased usage of mailing lists.
フィルタリングシステムを使用する理由はいくつかあります。ほとんどのユーザーのメールトラフィックは、電子メールの使用の増加、広告の形式として未承諾の電子メールの出現、メーリングリストの使用の増加により増加しています。
Experience at Carnegie Mellon has shown that if a filtering system is made available to users, many will make use of it in order to file messages from specific users or mailing lists. However, many others did not make use of the Andrew system's FLAMES filtering language [FLAMES] due to difficulty in setting it up.
Carnegie Mellonでの経験は、ユーザーがフィルタリングシステムを利用できるようにすると、特定のユーザーまたはメーリングリストからメッセージを提出するために多くの人がそれを利用することを示しています。しかし、他の多くの人は、セットアップが困難なため、アンドリューシステムの炎のフィルタリング言語[炎]を利用していませんでした。
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ベースのエディターは、多数のユーザーにフィルターを編集する好ましい方法になると予想されます。
In the sections of this document that discuss the requirements of various keywords and operators, the following conventions have been adopted.
さまざまなキーワードとオペレーターの要件を議論するこのドキュメントのセクションでは、次の規則が採用されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
Each section on a command (test, action, or control) has a line labeled "Usage:". This line describes the usage of the command, including its name and its arguments. Required arguments are listed inside angle brackets ("<" and ">"). Optional arguments are listed inside square brackets ("[" and "]"). Each argument is followed by its type, so "<key: string>" represents an argument called "key" that is a string. Literal strings are represented with double-quoted strings. Alternatives are separated with slashes, and parentheses are used for grouping, similar to [ABNF].
コマンドの各セクション（テスト、アクション、またはコントロール）には、「使用法：」というラベルが付いた行があります。この行は、その名前と議論を含むコマンドの使用について説明しています。必要な引数には、内部角度ブラケット（ "<"および ">"）がリストされています。オプションの引数は、四角い括弧内にリストされています（ "[" and "]"）。各引数の後にそのタイプが続くため、「<key：string>」は、文字列である「キー」と呼ばれる引数を表します。リテラル文字列は、二重引用文字列で表されます。代替はスラッシュで分離され、[ABNF]と同様に、グループ化に括弧が使用されます。
In the "Usage:" line, there are three special pieces of syntax that are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, respectively.
「使用法：」ラインには、頻繁に繰り返される、マッチタイプ、コンパレータ、アドレスパートの3つの特別な構文があります。これらについては、それぞれセクション2.7.1、2.7.3、および2.7.4で説明します。
The formal grammar for these commands is defined in section 8 and is the authoritative reference on how to construct commands, but the formal grammar does not specify the order, semantics, number or types of arguments to commands, or the legal command names. The intent is to allow for extension without changing the grammar.
これらのコマンドの正式な文法はセクション8で定義されており、コマンドを作成する方法に関する権威ある参照ですが、正式な文法では、コマンドに対する順序、セマンティクス、数字、または法律コマンド名を指定しません。意図は、文法を変更せずに拡張を可能にすることです。
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
Look, I'm sorry about the whole anvil thing, and I really
didn't mean to try and drop it on you from the top of the
cliff. I want to try to make it up to you. I've got some
great birdseed over here at my place--top of the line
stuff--and if you come by, I'll have it all wrapped up
for you. I'm really sorry for all the problems I've caused
for you over the years, but I know we can work this out.
--
Wile E. Coyote "Super Genius" coyote@desert.example.org
-----------------------------------------------------------
Message B
-----------------------------------------------------------
From: youcouldberich!@reply-by-postal-mail.invalid
Sender: b1ff@de.res.example.com
To: rube@landru.example.com
Date: Mon, 31 Mar 1997 18:26:10 -0800
Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
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!
-----------------------------------------------------------
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.
言語は一連のコマンドで構成されています。各コマンドは、Whitespaceによって区切られたトークンのセットで構成されています。コマンド識別子は最初のトークンであり、その後にゼロ以上の引数トークンが続きます。引数は、文字通りのデータ、タグ、コマンドのブロック、またはテストコマンドです。
With the exceptions of strings and comments, the language is limited to US-ASCII characters. Strings and comments may contain octets outside the US-ASCII range. Specifically, they will normally be in UTF-8, as specified in [UTF-8]. NUL (US-ASCII 0) is never permitted in scripts, while CR and LF can only appear as the CRLF line ending.
文字列やコメントを除いて、言語はUS-ASCIIキャラクターに限定されています。文字列とコメントには、米国ASCII範囲外のオクテットが含まれる場合があります。具体的には、[UTF-8]で指定されているように、通常はUTF-8になります。NUL（US-ASCII 0）はスクリプトでは許可されていませんが、CRとLFはCRLFラインの終了としてのみ表示されます。
Note: While this specification permits arbitrary octets to appear in Sieve scripts inside strings and comments, this has made it difficult to robustly handle Sieve scripts in programs that are sensitive to the encodings used. The "encoded-character" capability (section 2.4.2.4) provides an alternative means of representing such octets in strings using just US-ASCII characters. As such, the use of non-UTF-8 text in scripts should be considered a deprecated feature that may be abandoned.
注：この仕様により、任意のオクテットは文字列やコメント内のふるいスクリプトに表示されることができますが、これにより、使用されるエンコーディングに敏感なプログラムでふるいスクリプトを堅牢に処理することが困難になりました。「エンコードされたキャラクター」機能（セクション2.4.2.4）は、US-ASCII文字のみを使用して、文字列にそのようなオクテットを表す代替手段を提供します。そのため、スクリプトでの非UTF-8テキストの使用は、放棄される可能性のある非推奨機能と見なされる必要があります。
Tokens other than strings are considered case-insensitive.
文字列以外のトークンは、ケースに依存しないと見なされます。
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.
Whitespaceは、トークンを分離するために使用されます。Whitespaceは、タブ、Newlines（CRLF、CRまたはLFだけ）、およびスペース文字で構成されています。使用される空白の量は重要ではありません。
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種類のコメントが提供されています。コメントは、ホワイトスパースと意味的に同等であり、Whitespaceの任意の場所を使用できます（文法で説明されているように、マルチライン文字列に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;
}
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
*/ ;
}
Literal data means data that is not executed, merely evaluated "as is", to be used as arguments to commands. Literal data is limited to numbers, strings, and string lists.
リテラルデータとは、コマンドの引数として使用される「現状のまま」と評価されただけで実行されないデータを意味します。リテラルデータは、数字、文字列、文字列リストに限定されています。
Numbers are given as ordinary decimal numbers. As a shorthand for expressing larger values, such as message sizes, a suffix of "K", "M", or "G" MAY be appended to indicate a multiple of a power of two. To be comparable with the power-of-two-based versions of SI units that computers frequently use, "K" specifies kibi-, or 1,024 (2^10) times the value of the number; "M" specifies mebi-, or 1,048,576 (2^20) times the value of the number; and "G" specifies gibi-, or 1,073,741,824 (2^30) times the value of the number [BINARY-SI].
数字は通常の10進数として与えられます。メッセージサイズなどのより大きな値を表現するための速記として、「k」、「m」、または「g」の接尾辞は、2の力の倍数を示すように追加される場合があります。コンピューターが頻繁に使用するSIユニットの2つのパワーバージョンに匹敵するために、「k」はKibi-または1,024（2^10）倍の数の値を指定します。「M」は、数値の値を指定します。「g」は、ギブ、または1,073,741,824（2^30）の数[バイナリ-SI]の値を指定します。
Implementations MUST support integer values in the inclusive range zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
実装は、包括的な範囲ゼロから2,147,483,647（2^31-1）の整数値をサポートする必要がありますが、より大きな値をサポートする場合があります。
Only non-negative integers are permitted by this specification.
この仕様により、非陰性整数のみが許可されます。
Scripts involve large numbers of string values as they are used for pattern matching, addresses, textual bodies, etc. Typically, short quoted strings suffice for most uses, but a more convenient form is provided for longer strings such as bodies of messages.
スクリプトには、パターンマッチング、アドレス、テキストボディなどに使用されるため、多数の文字列値が含まれます。通常、ほとんどの用途には短い引用文字列で十分ですが、メッセージのボディなどの長い文字列にはより便利なフォームが提供されます。
A quoted string starts and ends with a single double quote (the <"> character, US-ASCII 34). A backslash ("\", US-ASCII 92) inside of a quoted string is followed by either another backslash or a double quote. These two-character sequences represent a single backslash or double quote within the value, respectively.
引用された文字列は始まり、1つの二重引用符（<">文字、us-ascii 34）で終わります。引用された文字列の内側のバックスラッシュ（ "\"、us-ascii 92）の後に別のバックスラッシュまたはダブルのいずれかが続きます引用。これらの2文字のシーケンスは、それぞれ値内の単一のバックスラッシュまたは二重引用を表しています。
Scripts SHOULD NOT escape other characters with a 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"), though that may be changed by extensions.
未定義のエスケープシーケンス（「a」に特別な意味がないコンテキストでは「\ a」など）は、バックスラッシュがないかのように解釈されます（この場合、 "\ a"は「A」です）。拡張機能によって変更されます。
Non-printing characters such as tabs, CRLF, and control characters are permitted in quoted strings. Quoted strings MAY span multiple lines. An unencoded NUL (US-ASCII 0) is not allowed in strings; see section 2.4.2.4 for how it can be encoded.
タブ、CRLF、コントロール文字などの非印刷文字は、引用された文字列で許可されています。引用された文字列は、複数の行に及ぶ場合があります。エンコードされていないNUL（US-ASCII 0）は、文字列では許可されていません。エンコードの方法については、セクション2.4.2.4を参照してください。
As message header data is converted to [UTF-8] for comparison (see section 2.7.2), most string values will use the UTF-8 encoding. However, implementations MUST accept all strings that match the grammar in section 8. The ability to use non-UTF-8 encoded strings matches existing practice and has proven to be useful both in tests for invalid data and in arguments containing raw MIME parts for extension actions that generate outgoing messages.
メッセージヘッダーデータが[UTF-8]に変換されて比較のために変換されると（セクション2.7.2を参照）、ほとんどの文字列値はUTF-8エンコーディングを使用します。ただし、実装は、セクション8の文法に一致するすべての文字列を受け入れる必要があります。非UTF-8エンコード文字列を使用する機能は、既存の実践と一致し、無効なデータのテストと拡張のための生のマイム部品を含む引数の両方で有用であることが証明されています。発信メッセージを生成するアクション。
For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. The CRLF before the final period is considered part of the value. In order to allow the message to contain lines with a single dot, lines are dot-stuffed. That is, when composing a message body, an extra '.' is added before each line that begins with a '.'. When the server interprets the script, these extra dots are removed. Note that a line that begins with a dot followed by a non-dot character is not interpreted as dot-stuffed;
電子メールメッセージなどの大量のテキストを入力するには、マルチラインフォームが許可されています。キーワード「テキスト：」から始まり、CRLFが続き、CRLFのシーケンス、単一期間、および別のCRLFで終わります。最終期間前のCRLFは、値の一部と見なされます。メッセージに単一のドットのある線を含めることを許可するために、線はドット詰まっています。つまり、メッセージ本文を作成するとき、余分な「」です。「。」で始まる各行の前に追加されます。サーバーがスクリプトを解釈すると、これらの余分なドットが削除されます。ドットで始まる線とドット以外の文字が続く線は、ドットが詰まっていると解釈されないことに注意してください。
that is, ".foo" is interpreted as ".foo". However, because this is potentially ambiguous, scripts SHOULD be properly dot-stuffed so such lines do not appear.
つまり、「.foo」は「.foo」と解釈されます。ただし、これは潜在的に曖昧であるため、スクリプトは適切に点在する必要があるため、そのような行が表示されません。
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の間にハッシュされたコメントまたは空白が発生する可能性があることに注意してください。ここでは、ブラケットのコメントは許可されていません。
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.
パターンを一致させるときは、シングル文字列の代わりに文字列のグループと一致するのが頻繁に便利です。このため、文字列のリストは多くのテストで許可されており、文字列のいずれかを使用してテストが真である場合、テストが真であることを意味します。
For instance, the test 'header :contains ["To", "Cc"] ["me@example.com", "me00@landru.example.com"]' is true if either a To header or Cc header of the input message contains either of the email addresses "me@example.com" or "me00@landru.example.com".
たとえば、テスト「ヘッダー：["to"、 "cc"] ["me@example.com"、 "me00@landru.example.com"] 'がtrueの場合、ヘッダーまたはCCヘッダーのいずれかがtrueがtrueです。入力メッセージには、電子メールアドレス「me@example.com」または「me00@landru.example.com」のいずれかが含まれています。
Conversely, in any case where a list of strings is appropriate, a single string is allowed without being a member of a list: it is equivalent to a list with a single member. This means that the test 'exists "To"' is equivalent to the test 'exists ["To"]'.
逆に、文字列のリストが適切である場合は、リストのメンバーではなく、単一の文字列が許可されます。これは、単一のメンバーのリストに相当します。これは、テストが「存在する」から「」はテストに相当する」ことを意味します[「 "to"] 'が存在します。
Headers are a subset of strings. In the Internet Message Specification [IMAIL], each header line is allowed to have whitespace nearly anywhere in the line, including after the field name and before the subsequent colon. Extra spaces between the header name and the ":" in a header field are ignored.
ヘッダーは文字列のサブセットです。インターネットメッセージの仕様[IMAIL]では、各ヘッダーラインは、フィールド名の後と後続のコロンの前を含む、ラインのほぼどこにでも空白を持つことができます。ヘッダー名とヘッダーフィールドの「：」の間の追加スペースは無視されます。
A header name never contains a colon. The "From" header refers to a line beginning "From:" (or "From :", etc.). No header will match the string "From:" due to the trailing colon.
ヘッダー名にはコロンが含まれません。「From」ヘッダーは、「または「from：」などから始まる行を指します。トレーリングコロンのために、「from：from」と一致するヘッダーはありません。
Similarly, no header will match a syntactically invalid header name. An implementation MUST NOT cause an error for syntactically invalid header names in tests.
同様に、構文的に無効なヘッダー名と一致するヘッダーはありません。実装は、テストで構文的に無効なヘッダー名のエラーを引き起こしてはなりません。
Header lines are unfolded as described in [IMAIL] section 2.2.3. Interpretation of header data SHOULD be done according to [MIME3] section 6.2 (see section 2.7.2 below for details).
ヘッダーラインは、[imail]セクション2.2.3で説明されているように展開されます。ヘッダーデータの解釈は、[MIME3]セクション6.2に従って行う必要があります（詳細については、以下のセクション2.7.2を参照）。
A number of commands call for email addresses, which are also a subset of strings. When these addresses are used in outbound contexts, addresses must be compliant with [IMAIL], but are further constrained within this document. Using the symbols defined in [IMAIL], section 3, the syntax of an address is:
多くのコマンドには、文字列のサブセットでもある電子メールアドレスが必要です。これらのアドレスがアウトバウンドコンテキストで使用される場合、アドレスは[imail]に準拠している必要がありますが、このドキュメント内でさらに制約されています。[imail]、セクション3で定義されているシンボルを使用して、アドレスの構文は次のとおりです。
sieve-address = addr-spec ; simple address
/ phrase "<" addr-spec ">" ; name & addr-spec
That is, routes and group syntax are not permitted. If multiple addresses are required, use a string list. Named groups are not permitted.
つまり、ルートとグループ構文は許可されていません。複数のアドレスが必要な場合は、文字列リストを使用します。名前付きグループは許可されていません。
It is an error for a script to execute an action with a value for use as an outbound address that doesn't match the "sieve-address" syntax.
「Sieve-Address」構文と一致しないアウトバウンドアドレスとして使用する値を使用してアクションを実行するスクリプトのエラーです。
When the "encoded-character" extension is in effect, certain character sequences in strings are replaced by their decoded value. This happens after escape sequences are interpreted and dot-unstuffing has been done. Implementations SHOULD support "encoded-character".
「エンコードされたキャラクター」拡張機能が有効になると、文字列の特定の文字シーケンスはデコードされた値に置き換えられます。これは、エスケープシーケンスが解釈され、ドット不浸透が行われた後に発生します。実装は「エンコードされたキャラクター」をサポートする必要があります。
Arbitrary octets can be embedded in strings by using the syntax encoded-arb-octets. The sequence is replaced by the octets with the hexadecimal values given by each hex-pair.
任意のオクテットは、構文エンコードされたARB-OCTETを使用して、文字列に埋め込むことができます。シーケンスは、各ヘクスペアによって与えられた16進数とともにオクテットに置き換えられます。
blank = WSP / CRLF
encoded-arb-octets = "${hex:" hex-pair-seq "}"
hex-pair-seq = *blank hex-pair *(1*blank hex-pair) *blank
hex-pair = 1*2HEXDIG
Where WSP and HEXDIG non-terminals are defined in Appendix B.1 of [ABNF].
ここで、WSPおよびHEXDIG非ターミナルは[ABNF]の付録B.1で定義されています。
It may be inconvenient or undesirable to enter Unicode characters verbatim, and for these cases the syntax encoded-unicode-char can be used. The sequence is replaced by the UTF-8 encoding of the specified Unicode characters, which are identified by the hexadecimal value of unicode-hex.
Unicode文字verbatimを入力するのは不便または望ましくない場合があり、これらの場合には、構文をエンコードしたUnicode-charを使用できます。シーケンスは、Unicode-hexの16進価値によって識別される、指定されたユニコード文字のUTF-8エンコードに置き換えられます。
encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = *blank unicode-hex
*(1*blank unicode-hex) *blank
unicode-hex = 1*HEXDIG
It is an error for a script to use a hexadecimal value that isn't in
either the range 0 to D7FF or the range E000 to 10FFFF. (The range
D800 to DFFF is excluded as those character numbers are only used as
part of the UTF-16 encoding form and are not applicable to the UTF-8
encoding that the syntax here represents.)
Note: Implementations MUST NOT raise an error for an out-of-range Unicode value unless the sequence containing it is well-formed according to the grammar.
注：実装は、それを含むシーケンスが文法に従ってよく形成されない限り、範囲外のユニコード値のエラーを引き起こしてはなりません。
The capability string for use with the require command is "encoded-character".
要求コマンドで使用する機能文字列は「エンコード文字」です。
In the following script, message B is discarded, since the specified test string is equivalent to "$$$".
次のスクリプトでは、指定されたテスト文字列は「$$$」に相当するため、メッセージBが破棄されます。
Example: require "encoded-character";
if header :contains "Subject" "$${hex:24 24}" {
discard;
}
The following examples demonstrate valid and invalid encodings and
how they are handled:
"$${hex:40}" -> "$@"
"${hex: 40 }" -> "@"
"${HEX: 40}" -> "@"
"${hex:40" -> "${hex:40"
"${hex:400}" -> "${hex:400}"
"${hex:4${hex:30}}" -> "${hex:40}"
"${unicode:40}" -> "@"
"${ unicode:40}" -> "${ unicode:40}"
"${UNICODE:40}" -> "@"
"${UnICoDE:0000040}" -> "@"
"${Unicode:40}" -> "@"
"${Unicode:Cool}" -> "${Unicode:Cool}"
"${unicode:200000}" -> error
"${Unicode:DF01} -> error
Tests are given as arguments to commands in order to control their actions. In this document, tests are given to if/elsif to decide which block of code is run.
テストは、アクションを制御するためにコマンドの引数として与えられます。このドキュメントでは、IF/ELSIFにテストが与えられ、コードのブロックが実行されるかを決定します。
Some tests ("allof" and "anyof", which implement logical "and" and logical "or", respectively) may require more than a single test as an argument. The test-list syntax element provides a way of grouping tests as a comma-separated list in parentheses.
いくつかのテスト（それぞれ論理的」と「論理的」または「「または「anyof」）は、引数として単一のテストを必要とする場合があります。テストリスト構文要素は、括弧内のコンマ分離リストとしてテストをグループ化する方法を提供します。
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.com") {
discard;
}
In order to specify what to do, most commands take arguments. There are three types of arguments: positional, tagged, and optional.
何をすべきかを指定するために、ほとんどのコマンドは議論を取ります。引数には、位置、タグ付き、およびオプションの3つのタイプがあります。
It is an error for a script, on a single command, to use conflicting arguments or to use a tagged or optional argument more than once.
これは、単一のコマンドで、競合する引数を使用したり、タグ付きまたはオプションの引数を複数回使用したりするためのスクリプトのエラーです。
Positional arguments are given to a command that discerns their meaning based on their order. When a command takes positional arguments, all positional arguments must be supplied and must be in the order prescribed.
位置的議論は、命令に基づいてその意味を識別するコマンドに与えられます。コマンドが位置的な引数を取得する場合、すべての位置的引数を提供する必要があり、規定された順序である必要があります。
This document provides for tagged arguments in the style of CommonLISP. These are also similar to flags given to commands in most command-line systems.
このドキュメントは、CommonLispのスタイルでタグ付けされた引数を提供します。これらは、ほとんどのコマンドラインシステムでコマンドに与えられたフラグにも似ています。
A tagged argument is an argument for a command that begins with ":" followed by a tag naming the argument, such as ":contains". This argument means that zero or more of the next tokens have some particular meaning depending on the argument. These next tokens may be literal data, but they are never blocks.
タグ付けされた引数は、「： "："：contains "などの引数に名前を付けるタグが続くコマンドの引数です。この議論は、次のトークンのゼロ以上が議論に応じていくつかの特別な意味を持っていることを意味します。これらの次のトークンは文字通りのデータかもしれませんが、ブロックではありません。
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.
タグ付きの引数は、位置引数の前に表示されなければなりませんが、他のタグ付き引数では任意の順序で表示される場合があります。仕様を簡単にするために、これはコマンドを使用した構文定義では表現されていませんが、位置の引数の前に表示されていれば、任意に並べ替えられる場合があります。タグ付きの引数は、オプションの引数と混合される場合があります。
Tagged arguments SHOULD NOT take tagged arguments as arguments.
タグ付きの引数は、タグ付けされた引数を引数として受け取るべきではありません。
Optional arguments are exactly like tagged arguments except that they may be left out, in which case a default value is implied. Because optional arguments tend to result in shorter scripts, they have been used far more than tagged arguments.
オプションの引数は、それらが除外される可能性があることを除いて、タグ付き引数とまったく同じです。その場合、デフォルト値が暗示されています。オプションの引数はより短いスクリプトをもたらす傾向があるため、タグ付けされた引数よりもはるかに多く使用されています。
One particularly noteworthy case is the ":comparator" argument, which allows the user to specify which comparator [COLLATION] will be used to compare two strings, since different languages may impose different orderings on UTF-8 [UTF-8] strings.
特に注目に値するケースの1つは、「Comparator」引数です。これにより、ユーザーは、UTF-8 [UTF-8]文字列に異なる順序を課す可能性があるため、ユーザーが2つの文字列を比較するために使用されるComparator [Collation]を指定できます。
Abstractly, arguments may be literal data, tests, or blocks of commands. In this way, an "if" control structure is merely a command that happens to take a test and a block as arguments and may execute the block of code.
抽象的には、引数は文字通りのデータ、テスト、またはコマンドのブロックである場合があります。このようにして、「IF」制御構造は、テストとブロックを引用として実行し、コードのブロックを実行する可能性がある単なるコマンドである単なるコマンドです。
However, this abstraction is ambiguous from a parsing standpoint.
ただし、この抽象化は、解析の観点からはあいまいです。
The grammar in section 8.2 presents a parsable version of this: Arguments are string lists (string-lists), numbers, and tags, which may be followed by a test or a test list (test-list), which may be followed by a block of commands. No more than one test or test list, or more than one block of commands, may be used, and commands that end with a block of commands do not end with semicolons.
セクション8.2の文法は、これの解析可能なバージョンを示しています。引数は文字列リスト（文字列リスト）、数字、タグです。コマンドのブロック。テストまたはテストリスト、またはコマンドのブロックを1つ以下に使用できないため、コマンドのブロックで終わるコマンドはセミコロンで終わりません。
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.
ある文字列を別の文字列と一致させるとき、マッチ操作を実行する方法がいくつかあります。これらは、正確な一致、サブストリングマッチ、ワイルドカードグローブスタイルのマッチの3種類のマッチで達成されます。これらを以下に説明します。
In order to provide for matches between character sets and case insensitivity, Sieve uses the comparators defined in the Internet Application Protocol Collation Registry [COLLATION].
キャラクターセットとケースの不感の一致を提供するために、Sieveは、インターネットアプリケーションプロトコル照合レジストリ[照合]で定義されているコンパレータを使用します。
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]で物事が定義される方法であるためです。
Commands that perform string comparisons may have an optional match type argument. The three match types in this specification are ":contains", ":is", and ":matches".
文字列比較を実行するコマンドには、オプションの一致タイプ引数がある場合があります。この仕様の3つの一致タイプは、「：contains」、「is」、および「matches」です。
The ":contains" match type describes a substring match. If the value argument contains the key argument as a substring, the match is true. For instance, the string "frobnitzm" contains "frob" and "nit", but not "fbm". The empty key ("") is contained in all values.
「：contains」マッチタイプは、サブストリングマッチを記述します。値引数にサブストリングとして重要な引数が含まれている場合、一致は真です。たとえば、文字列「Frobnitzm」には「FROB」と「NIT」が含まれていますが、「FBM」ではありません。空のキー（ ""）は、すべての値に含まれています。
The ":is" match type describes an absolute match; if the contents of the first string are absolutely the same as the contents of the second string, they match. Only the string "frobnitzm" is the string "frobnitzm". The empty key ("") only ":is" matches with the empty value.
「：is」マッチタイプは、絶対的な一致を説明しています。最初の文字列の内容が2番目の文字列の内容とまったく同じである場合、それらは一致します。文字列「frobnitzm」のみが文字列「frobnitzm」です。空のキー（ ""）のみ "は「空の値と一致します。
The ":matches" match type specifies a wildcard match using the characters "*" and "?"; the entire value must be matched. "*" matches zero or more characters in the value and "?" matches a single character in the value, where the comparator that is used (see section 2.7.3) defines what a character is. For example, the comparators "i;octet" and "i;ascii-casemap" define a character to be a single octet, so "?" will always match exactly one octet when one of those comparators is in use. In contrast, a Unicode-based comparator would define a character to be any UTF-8 octet sequence encoding one Unicode character and thus "?" may match more than one octet. "?" and "*" may be escaped as "\\?" and "\\*" in strings to match against themselves. The first backslash escapes the second backslash; together, they escape the "*". This is awkward, but it is commonplace in several programming languages that use globs and regular expressions.
「：マッチ」マッチタイプは、文字「*」と「？」を使用してワイルドカードマッチを指定します。値全体を一致させる必要があります。「*」は、値のゼロ以上の文字と「？」と一致します。値の単一の文字を一致させます。ここでは、使用されるコンパレータ（セクション2.7.3を参照）が文字が何であるかを定義します。たとえば、「I; Octet」と「I; ascii-casemap」の比較者は、文字を単一のオクテットと定義します。それらのコンパレータの1つが使用されている場合、常に正確に1つのオクテットと一致します。対照的に、ユニコードベースのコンパレータは、1つのユニコード文字をコードするUTF-8オクテットシーケンスであると定義します。複数のオクテットと一致する可能性があります。「？」そして、「*」は「\\？」として逃げられるかもしれませんそして、自分自身と一致する文字列で「\\*」。最初のバックスラッシュは、2番目のバックスラッシュを逃れます。一緒に、彼らは「*」から逃げます。これは厄介ですが、グローブや正規表現を使用するいくつかのプログラミング言語では一般的です。
In order to specify what type of match is supposed to happen, commands that support matching take optional arguments ":matches", ":is", and ":contains". Commands default to using ":is" matching if no match type argument is supplied. Note that these modifiers interact with comparators; in particular, only comparators that support the "substring match" operation are suitable for matching with ":contains" or ":matches". It is an error to use a comparator with ":contains" or ":matches" that is not compatible with it.
どのタイプの一致が発生するかを指定するために、マッチングをサポートするサポートするコマンドは、オプションの引数を取ります "：matches"、 "：is"、および "：contains"。マッチタイプの引数が提供されていない場合、 "：IS"マッチングを使用するコマンドをデフォルトします。これらの修飾子はコンパレータと相互作用することに注意してください。特に、「サブストリングマッチ」操作をサポートするコンパレータのみが、「contains」または「matches」との一致に適しています。「：contains」または「 "：bise"と互換性のないコンパレータを使用することはエラーです。
It is an error to give more than one of these arguments to a given command.
これらの引数の複数を特定のコマンドに与えることはエラーです。
For convenience, the "MATCH-TYPE" syntax element is defined here as follows:
便宜上、「マッチタイプ」構文要素は次のようにここで定義されています。
Syntax: ":is" / ":contains" / ":matches"
Messages may involve a number of character sets. In order for comparisons to work across character sets, implementations SHOULD implement the following behavior:
メッセージには、多くの文字セットが含まれる場合があります。キャラクターセット間で動作するための比較のために、実装は次の動作を実装する必要があります。
Comparisons are performed on octets. Implementations convert text from header fields in all charsets [MIME3] to Unicode, encoded as UTF-8, as input to the comparator (see section 2.7.3). Implementations MUST be capable of converting US-ASCII, ISO-8859- 1, the US-ASCII subset of ISO-8859-* character sets, and UTF-8. Text that the implementation cannot convert to Unicode for any reason MAY be treated as plain US-ASCII (including any [MIME3] syntax) or processed according to local conventions. An encoded NUL octet (character zero) SHOULD NOT cause early termination of the header content being compared against.
比較はオクテットで実行されます。実装は、すべての充電器[MIME3]のヘッダーフィールドから、Comparatorへの入力としてUTF-8としてエンコードされたUnicodeに変換します（セクション2.7.3を参照）。実装は、US-ASCII、ISO-8859-1、ISO-8859-*文字セットのUS-ASCIIサブセット、およびUTF-8を変換できる必要があります。何らかの理由で実装がUnicodeに変換できないテキストは、単純なUS-ASCII（[MIME3]構文を含む）を含む、またはローカル規則に従って処理される場合があります。エンコードされたNul Octet（文字ゼロ）は、ヘッダーコンテンツの早期終了を引き起こすことはありません。
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.
127を超えるオクテットが含まれている場合、2つの文字列を等しいと見なすことはできません。
In order to allow for language-independent, case-independent matches, the match type may be coupled with a comparator name. The Internet Application Protocol Collation Registry [COLLATION] provides the framework for describing and naming comparators.
言語に依存しない、ケースに依存しない一致を可能にするために、マッチタイプはコンパレータ名と結合することができます。Internet Application Protocol Collation Registry [Collation]は、コンパレータを記述および命名するためのフレームワークを提供します。
All implementations MUST support the "i;octet" comparator (simply compares octets) and the "i;ascii-casemap" comparator (which treats uppercase and lowercase characters in the US-ASCII subset of UTF-8 as the same). If left unspecified, the default is "i;ascii-casemap".
すべての実装は、「i;オクテット」コンパレータ（単純にオクテットを比較）と「i; ascii-casemap」コンパレータ（UTF-8のUS-ASCIIサブセットの大文字と小文字を同じものとして処理する）をサポートする必要があります。不特定のままにしておくと、デフォルトは「i; ascii-casemap」です。
Some comparators may not be usable with substring matches; that is, they may only work with ":is". It is an error to try to use a comparator with ":matches" or ":contains" that is not compatible with it.
一部のコンパレータは、サブストリングマッチで使用できない場合があります。つまり、彼らは「：is」とのみ作業することができます。「：matches」または「：contains」を使用してコンパレータを使用しようとするのはエラーです。
Sieve treats a comparator result of "undefined" the same as a result of "no-match". That is, this base specification does not provide any means to directly detect invalid comparator input.
ふるいは、「非マッチ」の結果と同じ「未定義」の比較結果を扱います。つまり、このベース仕様は、無効なコンパレータ入力を直接検出する手段を提供しません。
A comparator is specified by the ":comparator" option with commands that support matching. This option is followed by a string providing the name of the comparator to be used. For convenience, the syntax of a comparator is abbreviated to "COMPARATOR", and (repeated in several tests) is as follows:
コンパレータは、マッチングをサポートするコマンドを使用した「：コンパレータ」オプションによって指定されます。このオプションの後には、使用するコンパレータの名前を提供する文字列が続きます。便利なため、コンパレータの構文は「コンパレータ」と略され、（いくつかのテストで繰り返される）は次のとおりです。
Syntax: ":comparator" <comparator-name: string>
So in this example,
この例では、
Example: if header :contains :comparator "i;octet" "Subject"
"MAKE MONEY FAST" {
discard;
}
would discard any message with subjects like "You can MAKE MONEY FAST", but not "You can Make Money Fast", since the comparator used is case-sensitive.
「速くお金を稼ぐことができる」などの被験者にメッセージを破棄しますが、「速くお金を稼ぐことができる」ではありません。
Comparators other than "i;octet" and "i;ascii-casemap" must be declared with require, as they are extensions. If a comparator declared with require is not known, it is an error, and execution fails. If the comparator is not declared with require, it is also an error, even if the comparator is supported. (See section 2.10.5.)
「I; Octet」および「I; ASCII-CASEMAP」以外のコンパレータは、拡張機能であるため、必要とともに宣言する必要があります。要件で宣言されたコンパレータが不明な場合、それはエラーであり、実行は失敗します。コンパレータが必要に応じて宣言されていない場合、コンパレータがサポートされていても、エラーでもあります。（セクション2.10.5を参照してください。）
Both ":matches" and ":contains" match types are compatible with the "i;octet" and "i;ascii-casemap" comparators and may be used with them.
"：matches" and "：contas" Match型は、「i; Octet」および「i; ascii-casemap」コンパレータと互換性があり、それらと一緒に使用できます。
It is an error to give more than one of these arguments to a given command.
これらの引数の複数を特定のコマンドに与えることはエラーです。
Addresses are one of the most frequent things represented as strings. These are structured, and being able to compare against the local-part or the domain of an address is useful, so some tests that act exclusively on addresses take an additional optional argument that specifies what the test acts on.
アドレスは、文字列として表される最も頻繁なものの1つです。これらは構造化されており、アドレスのローカルパートまたはドメインと比較できることは有用であるため、アドレスのみで作用するテストでは、テストが機能するものを指定する追加のオプションの引数を採用します。
These optional arguments are ":localpart", ":domain", and ":all", which act on the local-part (left side), the domain-part (right side), and the whole address.
これらのオプションの引数は、「：localpart "、"：domain "、および「すべて」が、ローカルパート（左側）、ドメインパート（右側）、およびアドレス全体に作用します。
If an address is not syntactically valid, then it will not be matched by tests specifying ":localpart" or ":domain".
アドレスが構文的に有効でない場合、「：localpart」または「domain」を指定するテストでは一致しません。
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.
これらの引数の複数を特定のコマンドに与えることはエラーです。
For convenience, the "ADDRESS-PART" syntax element is defined here as follows:
便宜上、「アドレスパート」構文要素は次のように定義されています。
Syntax: ":localpart" / ":domain" / ":all"
Blocks are sets of commands enclosed within curly braces and supplied as the final argument to a command. Such a command is a control structure: when executed it has control over the number of times the commands in the block are executed.
ブロックは、巻き毛の装具内に囲まれ、最終的な引数としてコマンドへの引数として提供されるコマンドのセットです。このようなコマンドは制御構造です。実行すると、ブロック内のコマンドが実行される回数を制御できます。
With the commands supplied in this memo, there are no loops. The control structures supplied--if, elsif, and else--run a block either once or not at all.
このメモにコマンドが提供されているため、ループはありません。供給された制御構造は、elsif、およびその他 - は、ブロックを一度に実行するかどうかにかかっています。
Sieve scripts are sequences of commands. Commands can take any of the tokens above as arguments, and arguments may be either tagged or positional arguments. Not all commands take all arguments.
ふるいスクリプトはコマンドのシーケンスです。コマンドは上記のトークンを引数として取得でき、引数はタグ付けまたは位置的な引数のいずれかです。すべてのコマンドがすべての議論を取るわけではありません。
There are three kinds of commands: test commands, action commands, and control commands.
コマンドには、テストコマンド、アクションコマンド、および制御コマンドの3種類があります。
The simplest is an action command. An action command is an identifier followed by zero or more arguments, terminated by a semicolon. Action commands do not take tests or blocks as arguments. The actions referenced in this document are:
最も簡単なのはアクションコマンドです。アクションコマンドは、ゼロ以上の引数が続く識別子であり、セミコロンによって終了しました。アクションコマンドは、引数としてテストやブロックを取得しません。このドキュメントで参照されているアクションは次のとおりです。
- keep, to save the message in the default location - fileinto, to save the message in a specific mailbox - redirect, to forward the message to another address - discard, to silently throw away the message
- デフォルトの場所にメッセージを保存するために、特定のメールボックスにメッセージを保存するために、リダイレクト、メッセージを別のアドレスに転送するために、廃棄して、メッセージを静かに捨てる
A control command is a command that affects the parsing or the flow of execution of the Sieve script in some way. A control structure is a control command that ends with a block instead of a semicolon.
制御コマンドは、何らかの方法でシーブスクリプトの解析または実行の流れに影響するコマンドです。制御構造は、セミコロンの代わりにブロックで終わるコントロールコマンドです。
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.
テストコマンドは、制御コマンドの一部として使用されます。制御コマンドに与えられたコードのブロックが実行されるかどうかを指定するために使用されます。
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.
拡張アクションは、この仕様で定義されているアクションとの相互作用方法を述べる必要があります。
Previous experience with filtering systems suggests that cases tend to be missed in scripts. To prevent errors, Sieve has an "implicit keep".
フィルタリングシステムの以前の経験は、スクリプトでケースが見逃される傾向があることを示唆しています。エラーを防ぐために、ふるいには「暗黙のキープ」があります。
An implicit keep is a keep action (see section 4.3) performed in absence of any action that cancels the implicit keep.
暗黙のキープは、暗黙のキープをキャンセルするアクションがない場合に実行されるキープアクション（セクション4.3を参照）です。
An implicit keep is performed if a message is not written to a mailbox, redirected to a new address, or explicitly thrown out. That is, if a fileinto, a keep, a redirect, or a discard is performed, an implicit keep is not.
メッセージがメールボックスに書き込まれない、新しいアドレスにリダイレクトされていない、または明示的に廃止された場合、暗黙のキープが実行されます。つまり、fileinto、keep、redirect、またはaddardが実行される場合、暗黙のキープはそうではありません。
Some actions may be defined to not cancel the implicit keep. These actions may not directly affect the delivery of a message, and are used for their side effects. None of the actions specified in this document meet that criteria, but extension actions may.
暗黙のキープをキャンセルしないように定義される場合があります。これらのアクションは、メッセージの配信に直接影響しない可能性があり、副作用に使用されます。このドキュメントで指定されたアクションはいずれも、その基準を満たしていませんが、拡張アクションはそうする場合があります。
For instance, with any of the short messages offered above, the following script produces no actions.
たとえば、上記の短いメッセージのいずれかで、次のスクリプトではアクションが生成されません。
Example: if size :over 500K { discard; }
As a result, the implicit keep is taken.
その結果、暗黙のキープが取られます。
Implementations SHOULD NOT deliver a message to the same mailbox more than once, even if a script explicitly asks for a message to be written to a mailbox twice.
実装は、スクリプトがメールボックスに2回書き込まれるように明示的に要求する場合でも、同じメールボックスにメッセージを複数回配信してはなりません。
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回メールボックスに書き込ませるように要求する場合、エラーとして扱われてはなりません。
Site policy MAY limit the number of actions taken and MAY impose restrictions on which actions can be used together. In the event that a script hits a policy limit on the number of actions taken for a particular message, an error occurs.
サイトポリシーは、取られたアクションの数を制限する場合があり、どのアクションを一緒に使用できるかに制限を課す場合があります。スクリプトが特定のメッセージに対して取られたアクションの数にポリシーの制限に達した場合、エラーが発生します。
Implementations MUST allow at least one keep or one fileinto. If fileinto is not implemented, implementations MUST allow at least one keep.
実装では、少なくとも1つまたは1つのfileintoを許可する必要があります。FileINTOが実装されていない場合、実装は少なくとも1つのKEEPを許可する必要があります。
Because of the differing capabilities of many mail systems, several features of this specification are optional. Before any of these extensions can be executed, they must be declared with the "require" action.
多くのメールシステムの機能が異なるため、この仕様のいくつかの機能はオプションです。これらの拡張機能のいずれかを実行する前に、「要求」アクションで宣言する必要があります。
If an extension is not enabled with "require", implementations MUST treat it as if they did not support it at all. This protects scripts from having their behavior altered by extensions that the script author might not have even been aware of.
拡張機能が「要求」で有効になっていない場合、実装はまったくサポートしていないかのように扱う必要があります。これにより、スクリプトの著者が認識していなかった拡張機能によって動作を変更することからスクリプトが保護されます。
Implementations MUST NOT execute any Sieve script test or command subsequent to "require" if one of the required extensions is unavailable.
必要な拡張機能のいずれかが利用できない場合、実装は「要求」に続くシーブスクリプトテストまたはコマンドを実行してはなりません。
Note: The reason for this restriction is that prior experiences with languages such as LISP and Tcl suggest that this is a workable way of noting that a given script uses an extension.
注：この制限の理由は、LISPやTCLなどの言語での以前の経験が、これが特定のスクリプトが拡張機能を使用していることに注意する実行可能な方法であることを示唆しているためです。
Extensions that define actions MUST state how they interact with actions discussed in the base specification.
アクションを定義する拡張機能は、基本仕様で議論されたアクションとの相互作用方法を述べる必要があります。
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.
ふるいスクリプトでエラーが発生すると、すべての処理が停止します。
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).
実装は、完全な解析を行い、スクリプトを評価し、すべてのアクションを実行することを選択できます。実装は、実行がアトミックであることを確認するためにさえ進むことさえあります（すべてのアクションが実行されるか、実行されないものもありません）。
Other implementations may choose to parse and run at the same time. Such implementations are simpler, but have issues with partial failure (some actions happen, others don't).
他の実装は、同時に解析して実行することを選択できます。このような実装はより簡単ですが、部分的な障害に問題があります（一部のアクションは発生し、他のアクションは発生しません）。
Implementations MUST perform syntactic, semantic, and run-time checks on code that is actually executed. Implementations MAY perform those checks or any part of them on code that is not reached during execution.
実装は、実際に実行されるコードで構文、セマンティック、およびランタイムチェックを実行する必要があります。実装は、実行中に到達しないコードでそれらのチェックまたはそれらの一部を実行する場合があります。
When an error happens, implementations MUST notify the user that an error occurred and which actions (if any) were taken, and do an implicit keep.
エラーが発生した場合、実装はユーザーにエラーが発生し、どのアクション（もしあれば）が実行されたことを通知し、暗黙のキープを実行する必要があります。
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レベルをサポートする必要があります。
Control structures are needed to allow for multiple and conditional actions.
複数の条件付きアクションを可能にするには、制御構造が必要です。
There are three pieces to if: "if", "elsif", and "else". Each is actually a separate command in terms of the grammar. However, an elsif or else MUST only follow an if or elsif. An error occurs if these conditions are not met.
ifには3つのピースがあります：「if」、「elsif」、および「else」。それぞれは、実際には文法の観点から個別のコマンドです。ただし、elsifまたはその他は、ifまたはelsifのみに従う必要があります。これらの条件が満たされない場合、エラーが発生します。
Usage: if <test1: test> <block1: block>
Usage: elsif <test2: test> <block2: block>
Usage: else <block3: block>
The semantics are similar to those of any of the many other programming languages these control structures appear in. When the interpreter sees an "if", it evaluates the test associated with it. If the test is true, it executes the block associated with it.
セマンティクスは、これらの制御構造が表示される他の多くのプログラミング言語のセマンティクスと類似しています。インタープリターが「if」を見ると、それに関連するテストを評価します。テストが真の場合、それに関連付けられたブロックを実行します。
If the test of the "if" is false, it evaluates the test of the first "elsif" (if any). If the test of "elsif" is true, it runs the elsif's block. An elsif may be followed by an elsif, in which case, the interpreter repeats this process until it runs out of elsifs.
「if」のテストがfalseの場合、最初の「elsif」のテスト（存在する場合）を評価します。「elsif」のテストが本当なら、それはelsifのブロックを実行します。Elsifの後にElsifが続く場合があります。その場合、通訳者はELSIFがなくなるまでこのプロセスを繰り返します。
When the interpreter runs out of elsifs, there may be an "else" case. If there is, and none of the if or elsif tests were true, the interpreter runs the else's block.
インタープリターがElsifsを使い果たすと、「他の」ケースがある可能性があります。IFまたはELSIFテストがある場合、およびELSIFテストがない場合、インタープリターは他のブロックを実行します。
This provides a way of performing exactly one of the blocks in the chain.
これは、チェーン内のブロックの1つを正確に実行する方法を提供します。
In the following example, both messages A and B are dropped.
次の例では、メッセージAとBの両方がドロップされます。
Example: require "fileinto";
if header :contains "from" "coyote" {
discard;
} elsif header :contains ["subject"] ["$$$"] {
discard;
} else {
fileinto "INBOX";
}
When the script below is run over message A, it redirects the message to acm@example.com; message B, to postmaster@example.com; any other message is redirected to field@example.com.
以下のスクリプトがメッセージaで実行されると、メッセージをacm@example.comにリダイレクトします。メッセージB、postmaster@example.comへ。その他のメッセージは、field@example.comにリダイレクトされます。
Example: if header :contains ["From"] ["coyote"] {
redirect "acm@example.com";
} elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.com";
} else {
redirect "field@example.com";
}
Note that this definition prohibits the "... else if ..." sequence used by C. This is intentional, because this construct produces a shift-reduce conflict.
この定義は、Cで使用される「... else ...」シーケンスを禁止することに注意してください。
Usage: require <capabilities: string-list>
The require action notes that a script makes use of a certain extension. Such a declaration is required to use the extension, as discussed in section 2.10.5. Multiple capabilities can be declared with a single require.
要求アクションは、スクリプトが特定の拡張機能を使用していることに注意してください。このような宣言は、セクション2.10.5で説明したように、拡張機能を使用する必要があります。複数の機能は、単一の要求で宣言できます。
The require command, if present, MUST be used before anything other than a require can be used. An error occurs if a require appears after a command other than require.
要件以外のものを使用する前に、存在する場合は、要求コマンドを使用する必要があります。要求以外のコマンドの後に要件が表示された場合、エラーが発生します。
Example: require ["fileinto", "reject"];
例：["fileinto"、 "rexect"]を要求します。
Example: require "fileinto"; require "vacation";
例：「fileinto」が必要です。「休暇」が必要です。
Usage: stop
使用法：停止
The "stop" action ends all processing. If the implicit keep has not been cancelled, then it is taken.
「停止」アクションはすべての処理を終了します。暗黙のキープがキャンセルされていない場合、それは取られます。
This document supplies four actions that may be taken on a message: keep, fileinto, redirect, and discard.
このドキュメントは、メッセージに掲載される可能性のある4つのアクションを提供します。
Implementations MUST support the "keep", "discard", and "redirect" actions.
実装は、「Keep」、「廃棄」、および「リダイレクト」アクションをサポートする必要があります。
Implementations SHOULD support "fileinto".
実装は「fileinto」をサポートする必要があります。
Implementations MAY limit the number of certain actions taken (see section 2.10.4).
実装では、実行される特定のアクションの数が制限される場合があります（セクション2.10.4を参照）。
Usage: fileinto <mailbox: string>
The "fileinto" action delivers the message into the specified mailbox. Implementations SHOULD support fileinto, but in some environments this may be impossible. Implementations MAY place restrictions on mailbox names; use of an invalid mailbox name MAY be treated as an error or result in delivery to an implementation-defined mailbox. If the specified mailbox doesn't exist, the implementation MAY treat it as an error, create the mailbox, or deliver the message to an implementation-defined mailbox. If the implementation uses a different encoding scheme than UTF-8 for mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its encoding scheme. For example, the Internet Message Access Protocol [IMAP] uses modified UTF-7, such that a mailbox argument of "odds & ends" would appear in IMAP as "odds &- ends".
「fileinto」アクションは、指定されたメールボックスにメッセージを配信します。実装はfileintoをサポートする必要がありますが、一部の環境ではこれは不可能かもしれません。実装は、メールボックス名に制限を設ける場合があります。無効なメールボックス名の使用は、エラーとして扱われたり、実装定義のメールボックスに配信されたりする場合があります。指定されたメールボックスが存在しない場合、実装はそれをエラーとして扱うか、メールボックスを作成するか、実装定義のメールボックスにメッセージを配信する場合があります。実装がメールボックス名でUTF-8とは異なるエンコードスキームを使用する場合、UTF-8からエンコードスキームにメールボックス名を再エンコードする必要があります。たとえば、インターネットメッセージアクセスプロトコル[IMAP]は変更されたUTF-7を使用して、「オッズとエンド」のメールボックス引数がIMAPで「オッズ＆ - エンド」として表示されます。
The capability string for use with the require command is "fileinto".
要求コマンドで使用する機能文字列は「fileinto」です。
In the following script, message A is filed into mailbox "INBOX.harassment".
次のスクリプトでは、メッセージAがメールボックス「Inbox.Harassment」に提出されます。
Example: require "fileinto";
if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment";
}
Usage: redirect <address: string>
The "redirect" action is used to send the message to another user at a supplied address, as a mail forwarding feature does. The "redirect" action makes no changes to the message body or existing headers, but it may add new headers. In particular, existing Received headers MUST be preserved and the count of Received headers in the outgoing message MUST be larger than the same count on the message as received by the implementation. (An implementation that adds a Received header before processing the message does not need to add another when redirecting.)
「リダイレクト」アクションは、メール転送機能がそうであるように、提供されたアドレスで別のユーザーにメッセージを送信するために使用されます。「リダイレクト」アクションは、メッセージ本文または既存のヘッダーに変更を加えませんが、新しいヘッダーを追加する可能性があります。特に、既存の受信ヘッダーを保存する必要があり、発信メッセージ内の受信ヘッダーのカウントは、実装で受信したメッセージと同じ数よりも大きくなければなりません。（メッセージを処理する前に受信したヘッダーを追加する実装では、リダイレクト時に別のヘッダーを追加する必要はありません。）
The message is sent back out with the address from the redirect command as an envelope recipient. Implementations MAY combine separate redirects for a given message into a single submission with multiple envelope recipients. (This is not a Mail User Agent (MUA)- style forward, which creates a new message with a different sender and message ID, wrapping the old message in a new one.)
メッセージは、封筒の受信者としてRedirectコマンドのアドレスを使用して送信されます。実装は、特定のメッセージの個別のリダイレクトを、複数のエンベロープレシピエントを含む単一の提出物に結合する場合があります。（これはメールユーザーエージェント（MUA） - スタイルフォワードではありません。これにより、異なる送信者とメッセージIDを使用して新しいメッセージが作成され、古いメッセージを新しいメッセージに巻き付けます。）
The envelope sender address on the outgoing message is chosen by the sieve implementation. It MAY be copied from the message being processed. However, if the message being processed has an empty envelope sender address the outgoing message MUST also have an empty envelope sender address. This last requirement is imposed to prevent loops in the case where a message is redirected to an invalid address when then returns a delivery status notification that also ends up being redirected to the same invalid address.
発信メッセージのエンベロープ送信者アドレスは、ふるいの実装によって選択されます。処理されているメッセージからコピーされる場合があります。ただし、処理されるメッセージに空の封筒送信者アドレスがある場合、発信メッセージには空のエンベロープ送信者アドレスも必要です。この最後の要件は、メッセージが無効なアドレスにリダイレクトされた場合にループを防ぐために課されます。
A simple script can be used for redirecting all mail:
すべてのメールをリダイレクトするために、簡単なスクリプトを使用できます。
Example: redirect "bart@example.com";
Implementations MUST take measures to implement loop control, possibly including adding headers to the message or counting Received headers as specified in section 6.2 of [SMTP]. If an implementation detects a loop, it causes an error.
実装は、[SMTP]のセクション6.2で指定されているように、メッセージにヘッダーを追加したり、受信したヘッダーをカウントするなど、ループ制御を実装するための措置を講じる必要があります。実装がループを検出すると、エラーが発生します。
Implementations MUST provide means of limiting the number of redirects a Sieve script can perform. See section 10 for more details.
実装は、パフォーマンスを発揮できるシーブスクリプトのリダイレクトの数を制限する手段を提供する必要があります。詳細については、セクション10を参照してください。
Implementations MAY ignore a redirect action silently due to policy reasons. For example, an implementation MAY choose not to redirect to an address that is known to be undeliverable. Any ignored redirect MUST NOT cancel the implicit keep.
実装は、政策上の理由により、リダイレクトアクションを静かに無視する場合があります。たとえば、実装では、配信不可能であることが知られている住所にリダイレクトしないことを選択する場合があります。無視されたリダイレクトは、暗黙のキープをキャンセルしてはなりません。
Usage: keep
使用法：保管します
The "keep" action is whatever action is taken in lieu of all other actions, if no filtering happens at all; generally, this simply means to file the message into the user's main mailbox. This command provides a way to execute this action without needing to know the name of the user's main mailbox, providing a way to call it without needing to understand the user's setup or the underlying mail system.
「キープ」アクションは、フィルタリングがまったく発生しない場合、他のすべてのアクションの代わりにアクションが実行されるものです。一般的に、これは単にユーザーのメインメールボックスにメッセージを提出することを意味します。このコマンドは、ユーザーのメインメールボックスの名前を知らずにこのアクションを実行する方法を提供し、ユーザーのセットアップや基礎となるメールシステムを理解する必要なく呼び出す方法を提供します。
For instance, in an implementation where the IMAP server is running scripts on behalf of the user at time of delivery, a keep command is equivalent to a fileinto "INBOX".
たとえば、IMAPサーバーが配信時にユーザーに代わってスクリプトを実行している実装では、KeepコマンドはFileInto "Inbox"に相当します。
Example: if size :under 1M { keep; } else { discard; }
Note that the above script is identical to the one below.
上記のスクリプトは以下のスクリプトと同じであることに注意してください。
Example: if not size :under 1M { discard; }
Usage: discard
使用法：破棄
Discard is used to silently throw away the message. It does so by simply canceling the implicit keep. If discard is used with other actions, the other actions still happen. Discard is compatible with all other actions. (For instance, fileinto+discard is equivalent to fileinto.)
廃棄は、メッセージを静かに捨てるために使用されます。暗黙のキープをキャンセルするだけでそうします。他のアクションで破棄が使用されている場合、他のアクションがまだ発生します。破棄は、他のすべてのアクションと互換性があります。（たとえば、FileIntoの破棄はFileIntoと同等です。）
Discard MUST be silent; that is, it MUST NOT return a non-delivery notification of any kind ([DSN], [MDN], or otherwise).
廃棄は沈黙している必要があります。つまり、いかなる種類の非配信通知（[DSN]、[MDN]、またはその他）を返してはなりません。
In the following script, any mail from "idiot@example.com" is thrown out.
次のスクリプトでは、「yidiot@example.com」からのメールが廃止されます。
Example: if header :contains ["from"] ["idiot@example.com"] {
discard;
}
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.
この言語の重要な部分である「廃棄」は、ユーザーに深刻な問題を引き起こす可能性があります。公共のコンピューターラボで無人のマシンにログインしたままにしておく学生は、スクリプトが「廃棄」に変更されることがあります。（同様の状況とともに）この状況でユーザーを保護するために、実装は、スクリプトによって無期限にメッセージを破壊し続ける可能性があり、すべてのメールを削除するスクリプトを禁止する場合があります。
Tests are used in conditionals to decide which part(s) of the conditional to execute.
テストは、実行する条件のどの部分を決定するために条件付きで使用されます。
Implementations MUST support these tests: "address", "allof", "anyof", "exists", "false", "header", "not", "size", and "true".
実装は、これらのテストをサポートする必要があります：「アドレス」、「Allof」、「Anyof」、「Exists」、「false」、「Header」、「not」、「size」、および「true」。
Implementations SHOULD support the "envelope" test.
実装は「エンベロープ」テストをサポートする必要があります。
Usage: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
The "address" test matches Internet addresses in structured headers that contain addresses. It returns true if any header contains any key in the specified part of the address, as modified by the comparator and the match keyword. Whether there are other addresses present in the header doesn't affect this test; this test does not provide any way to determine whether an address is the only address in a header.
「アドレス」テストは、アドレスを含む構造化ヘッダーのインターネットアドレスと一致します。ComparatorとMatchキーワードによって変更されたように、アドレスの指定された部分にヘッダーが任意のキーを含む場合、TRUEが返されます。ヘッダーに他のアドレスが存在するかどうかは、このテストに影響しません。このテストでは、アドレスがヘッダーの唯一のアドレスであるかどうかを判断する方法は提供されません。
Like envelope and header, this test returns true if any combination of the header-list and key-list arguments match and returns false otherwise.
EnvelopeやHeaderのように、このテストは、ヘッダーリストとキーリストの引数の任意の組み合わせが一致し、それ以外の場合はFalseを返します。
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.
インターネットの電子メールアドレス[IMAIL]は、AT-SIGNの左側のローカルパートがケースに敏感であると見なされ、AT-SIGNの右側のドメインパートは症例が鈍感であるというやや厄介な特性を持っています。「アドレス」コマンドはこれ自体を扱うのではなく、ユーザーがそれに対処できるようにするためのアドレスパートの引数を提供します。
The address primitive never acts on the phrase part of an email address or on comments within that address. It also never acts on group names, although it does act on the addresses within the group construct.
アドレスプリミティブは、電子メールアドレスのフレーズ部分やそのアドレス内のコメントには決して機能しません。また、グループコンストラクト内のアドレスに作用しますが、グループ名にも作用することはありません。
Implementations MUST restrict the address test to headers that contain addresses, but MUST include at least From, To, Cc, Bcc, Sender, Resent-From, and Resent-To, and it SHOULD include any other header that utilizes an "address-list" structured header body.
実装は、アドレステストをアドレスを含むが、少なくとも、、CC、BCC、送信者、resティ、resティへのヘッダーに制限する必要があり、「アドレスリスト」を使用する他のヘッダーを含める必要があります「構造化されたヘッダーボディ。
Example: if address :is :all "from" "tim@example.com" {
discard;
}
Usage: allof <tests: test-list>
The "allof" test performs a logical AND on the tests supplied to it.
「Allof」テストは、論理的に、およびそれに提供されたテストで実行されます。
Example: allof (false, false) => false
allof (false, true) => false
allof (true, true) => true
The allof test takes as its argument a test-list.
Allofテストは、その議論としてテストリストを取得します。
Usage: anyof <tests: test-list>
The "anyof" test performs a logical OR on the tests supplied to it.
「Anyof」テストは、論理またはそれに提供されたテストで実行されます。
Example: anyof (false, false) => false
anyof (false, true) => true
anyof (true, true) => true
Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
The "envelope" test is true if the specified part of the [SMTP] (or equivalent) envelope matches the specified key. This specification defines the interpretation of the (case insensitive) "from" and "to" envelope-parts. Additional envelope-parts may be defined by other extensions; implementations SHOULD consider unknown envelope parts an error.
[Envelope]テストは、[SMTP]（または同等の）エンベロープの指定された部分が指定されたキーと一致する場合に真です。この仕様では、「ケースの鈍感な）「 "and" to "Envelope-Partsの解釈が定義されています。追加のエンベロープパートは、他の拡張機能によって定義できます。実装は、不明なエンベロープパーツをエラーと見なす必要があります。
If one of the envelope-part strings is (case insensitive) "from", then matching occurs against the FROM address used in the SMTP MAIL command. The null reverse-path is matched against as the empty string, regardless of the ADDRESS-PART argument specified.
エンベロープパートの文字列の1つが（ケースの非感受性）「from」である場合、SMTPメールコマンドで使用されるアドレスから一致することが発生します。null逆パスは、指定されたアドレスパート引数に関係なく、空の文字列として一致します。
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コマンドで使用されるアドレスに対して一致することが発生します。最新のもののみが利用可能であり、このユーザーに関連するもののみが利用可能であることに注意してください。
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.
エンベロープパートは文字列リストであり、複数のパラメーターを含む場合があります。この場合、キーリストで指定されたすべての文字列は、エンベロープパートリストに与えられたすべての部品と一致します。
Like address and header, this test returns true if any combination of the envelope-part list and key-list arguments match and returns false otherwise.
アドレスやヘッダーと同様に、このテストは、エンベロープパートリストとキーリスト引数の組み合わせが一致し、それ以外の場合はfalseを返す場合、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コマンドのデータのみが、エンベロープの「から」の「」で利用可能です。
If a protocol other than SMTP is used for message transport, implementations are expected to adapt this command appropriately.
SMTP以外のプロトコルがメッセージトランスポートに使用される場合、実装はこのコマンドを適切に適合させることが期待されます。
The envelope command is optional. Implementations SHOULD support it, but the necessary information may not be available in all cases. The capability string for use with the require command is "envelope".
Envelopeコマンドはオプションです。実装はそれをサポートする必要がありますが、必要な情報はすべての場合に利用できない場合があります。要求コマンドで使用する機能文字列は「エンベロープ」です。
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
Usage: exists <header-names: string-list>
The "exists" test is true if the headers listed in the header-names argument exist within the message. All of the headers must exist or the test is false.
「存在する」テストは、ヘッダー名の引数にリストされているヘッダーがメッセージ内に存在する場合に当てはまります。すべてのヘッダーが存在する必要があります。そうしないと、テストが間違っています。
The following example throws out mail that doesn't have a From header and a Date header.
次の例は、ヘッダーと日付ヘッダーのないメールを削除します。
Example: if not exists ["From","Date"] {
discard;
}
Usage: false
使用法：false
The "false" test always evaluates to false.
「false」テストは常にfalseに評価されます。
Usage: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
The "header" test evaluates to true if the value of any of the named headers, ignoring leading and trailing whitespace, matches any key. The type of match is specified by the optional match argument, which defaults to ":is" if not specified, as specified in section 2.6.
「ヘッダー」テストは、指定されたヘッダーの値が、先頭および後続の白い空間を無視して、任意のキーと一致する場合、trueに評価されます。一致のタイプは、セクション2.6で指定されているように、デフォルトで「：指定されていない場合」にデフォルトであるオプションの一致引数によって指定されます。
Like address and envelope, this test returns true if any combination of the header-names list and key-list arguments match and returns false otherwise.
アドレスやエンベロープのように、このテストは、ヘッダー名リストとキーリスト引数の任意の組み合わせが一致し、それ以外の場合はfalseを返す場合、trueを返します。
If a header listed in the header-names argument exists, it contains the empty key (""). However, if the named header is not present, it does not match any key, including the empty key. So if a message contained the header
ヘッダー名引数にリストされているヘッダーが存在する場合、空のキー（ ""）が含まれます。ただし、名前付きヘッダーが存在しない場合、空のキーを含むキーと一致しません。したがって、メッセージにヘッダーが含まれている場合
X-Caffeine: C8H10N4O2
X-カフェイン：C8H10N4O2
these tests on that header evaluate as follows:
そのヘッダーに関するこれらのテストは、次のように評価します。
header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true
Testing whether a given header is either absent or doesn't contain any non-whitespace characters can be done using a negated "header" test:
特定のヘッダーが存在しないか、非自転車文字を含めていないかどうかをテストすることは、否定された「ヘッダー」テストを使用して実行できます。
not header :matches "Cc" "?*"
ヘッダーではありません：「cc」 "？*"に一致します
Usage: not <test1: 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」テストは、他のテストを引数として取り、反対の結果をもたらします。「虚偽ではない」は、「真」と「真の」と評価され、「false」と評価されます。
Usage: size <":over" / ":under"> <limit: number>
The "size" test deals with the size of a message. It takes either a tagged argument of ":over" or ":under", followed by a number representing the size of the message.
「サイズ」テストは、メッセージのサイズを扱います。「：over」または「：under」というタグ付けされた引数が続き、その後にメッセージのサイズを表す数字が続きます。
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.
引数が「：under」であり、メッセージのサイズが提供された数値よりも小さい場合、テストは真です。そうでなければ、それは誤りです。
Exactly one of ":over" or ":under" must be specified, and anything else is an error.
正確には「：over」または「：under」を指定する必要があり、他のものはエラーです。
The size of a message is defined to be the number of octets in the [IMAIL] representation of the message.
メッセージのサイズは、メッセージの[imail]表現のオクテットの数であると定義されます。
Note that for a message that is exactly 4,000 octets, the message is neither ":over" nor ":under" 4000 octets.
ちょうど4,000オクテットであるメッセージの場合、メッセージは「4000オクテット」の下ではありません。
Usage: true
使用法：true
The "true" test always evaluates to true.
「真の」テストは常にTrueに評価されます。
New control commands, actions, and tests can be added to the language. Sites must make these features known to their users; this document does not define a way to discover the list of extensions supported by the server.
新しい制御コマンド、アクション、およびテストを言語に追加できます。サイトは、これらの機能をユーザーに知っている必要があります。このドキュメントは、サーバーがサポートする拡張機能のリストを発見する方法を定義していません。
Any extensions to this language MUST define a capability string that uniquely identifies that extension. Capability string are case-sensitive; for example, "foo" and "FOO" are different capabilities. If a new version of an extension changes the functionality of a previously defined extension, it MUST use a different name. Extensions may register a set of related capabilities by registering just a unique prefix for them. The "comparator-" prefix is an example of this. The prefix MUST end with a "-" and MUST NOT overlap any existing registrations.
この言語の拡張機能は、その拡張子を一意に識別する機能文字列を定義する必要があります。機能文字列はケースに敏感です。たとえば、「foo」と「foo」は異なる機能です。拡張機能の新しいバージョンが以前に定義された拡張機能の機能を変更する場合、別の名前を使用する必要があります。拡張機能は、それらの一意のプレフィックスのみを登録することにより、関連する一連の機能を登録する場合があります。「Comparator-」プレフィックスは、この例です。接頭辞は「 - 」で終了する必要があり、既存の登録を重ねてはなりません。
In a situation where there is a script submission protocol and an extension advertisement mechanism aware of the details of this language, scripts submitted can be checked against the mail server to prevent use of an extension that the server does not support.
スクリプト送信プロトコルとこの言語の詳細を認識している拡張広告広告メカニズムがある状況では、送信されたスクリプトをメールサーバーに対してチェックして、サーバーがサポートしていない拡張機能の使用を防ぐことができます。
Extensions MUST state how they interact with constraints defined in section 2.10, e.g., whether they cancel the implicit keep, and which actions they are compatible and incompatible with. Extensions MUST NOT change the behavior of the "require" control command or alter the interpretation of the argument to the "require" control.
拡張機能は、セクション2.10で定義されている制約との相互作用方法、たとえば、暗黙のキープをキャンセルするかどうか、どのアクションが互換性があり、互換性がないかを述べる必要があります。拡張機能は、「必要」制御コマンドの動作を変更したり、引数の解釈を「要求」コントロールに変更してはなりません。
Extensions that can submit new email messages or otherwise generate new protocol requests MUST consider loop suppression, at least to document any security considerations.
少なくともセキュリティに関する考慮事項を文書化するには、新しい電子メールメッセージを送信したり、新しいプロトコル要求を生成したりすることができる拡張機能は、ループ抑制を検討する必要があります。
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」で始まる機能文字列。ベンダー定義の拡張機能を表します。このような拡張機能は、インターネット標準やRFCで定義されていませんが、競合を防ぐためにIANAに登録されています。「VND」から始まる拡張機能。「vnd.acme.rocket-sled」などのベンダーと製品の名前に続いて続く必要があります。
The following capability strings are defined by this document:
次の機能文字列は、このドキュメントで定義されています。
encoded-character The string "encoded-character" indicates that the implementation supports the interpretation of "${hex:...}" and "${unicode:...}" in strings.
エンコードされた文字列「エンコード文字」は、実装が文字列の「$ {hex：...}」および「$ {unicode：...}」の解釈をサポートしていることを示します。
envelope The string "envelope" indicates that the implementation supports the "envelope" command.
エンベロープ文字列「エンベロープ」は、実装が「エンベロープ」コマンドをサポートしていることを示します。
fileinto The string "fileinto" indicates that the implementation supports the "fileinto" command.
fileinto文字列「fileinto」は、実装が「fileinto」コマンドをサポートしていることを示します。
comparator- The string "comparator-elbonia" is provided if the implementation supports the "elbonia" comparator. Therefore, all implementations have at least the "comparator-i;octet" and "comparator-i;ascii-casemap" capabilities. However, these comparators may be used without being declared with require.
比較 - 実装が「エルボニア」コンパレータをサポートする場合、文字列「コンパレータエルボニア」が提供されます。したがって、すべての実装には、少なくとも「Comparator-I; Octet」および「Comparator-I; ASCII-CASEMAP」機能があります。ただし、これらのコンパレータは、要求とともに宣言されることなく使用できます。
In order to provide a standard set of extensions, a registry is maintained by IANA. This registry contains both vendor-controlled capability names (beginning with "vnd.") and IETF-controlled capability names. Vendor-controlled capability names may be registered on a first-come, first-served basis, by applying to IANA with the form in the following section. Registration of capability prefixes that do not begin with "vnd." REQUIRES a standards track or IESG-approved experimental RFC.
標準の拡張セットを提供するために、IANAによってレジストリが維持されます。このレジストリには、ベンダー制御の機能名（「VND」から始まる）とIETF制御の機能名の両方が含まれています。ベンダー制御の機能名は、次のセクションにフォームを使用してIANAに申請することにより、先着順で登録できます。「VND」で始まらない機能のプレフィックスの登録。標準トラックまたはIESGが承認した実験RFCが必要です。
Extensions designed for interoperable use SHOULD use IETF-controlled capability names.
相互運用可能な使用用に設計された拡張機能は、IETF制御機能名を使用する必要があります。
The following template is to be used for registering new Sieve extensions with IANA.
次のテンプレートは、IANAに新しいふるい拡張機能を登録するために使用されます。
To: iana@iana.org Subject: Registration of new Sieve extension
宛先：iana@iana.org件名：新しいふるい延長の登録
Capability name: [the string for use in the 'require' statement]
Description: [a brief description of what the extension adds
or changes]
RFC number: [for extensions published as RFCs]
Contact address: [email and/or physical address to contact for
additional information]
In order to bring the existing capability registrations in line with the new template, IANA has modified each as follows:
既存の機能登録を新しいテンプレートに沿って提供するために、IANAは次のようにそれぞれを変更しました。
1. The "capability name" and "capability arguments" fields have been eliminated 2. The "capability keyword" field have been renamed to "Capability name" 3. An empty "Description" field has been added 4. The "Standards Track/IESG-approved experimental RFC number" field has been renamed to "RFC number" 5. The "Person and email address to contact for further information" field should be renamed to "Contact address"
1. 「機能名」と「機能引数」フィールドが排除されました。2。「機能キーワード」フィールドは「機能名」に変更されました。3。空の説明 "フィールドが追加されました。承認された実験RFC番号「フィールドは「RFC番号」に名前が変更されました。
This RFC updates the following entries in the IANA registry for Sieve extensions.
このRFCは、Sieve ExtensionsのIANAレジストリで次のエントリを更新します。
Capability name: encoded-character Description: changes the interpretation of strings to allow arbitrary octets and Unicode characters to be represented using US-ASCII RFC number: RFC 5228 (Sieve base spec) Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名：エンコードされたキャラクターの説明：文字列の解釈を変更して、任意のオクテットとユニコード文字をUS-ASCII RFC番号を使用して表現できるようにします。@imc.org>
Capability name: fileinto
Description: adds the 'fileinto' action for delivering to a
mailbox other than the default
RFC number: RFC 5228 (Sieve base spec)
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
Capability name: envelope
Description: adds the 'envelope' test for testing the message
transport sender and recipient address
RFC number: RFC 5228 (Sieve base spec)
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
Capability name: comparator-* (anything starting with "comparator-")
Description: adds the indicated comparator for use with the
:comparator argument
RFC number: RFC 5228 (Sieve base spec) and [COLLATION]
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
A method of advertising which capabilities an implementation supports is difficult due to the wide range of possible implementations. Such a mechanism, however, should have the property that the implementation can advertise the complete set of extensions that it supports.
実装のサポートをサポートする能力の広告方法は、可能な実装の可能性が広いために困難です。ただし、このようなメカニズムには、実装がサポートする拡張機能の完全なセットを宣伝できるプロパティを持つ必要があります。
The [MIME] type for a Sieve script is "application/sieve".
ふるいスクリプトの[mime]タイプは「アプリケーション/ふるい」です。
The registration of this type for RFC 2048 requirements is updated as follows:
RFC 2048要件のこのタイプの登録は、次のように更新されます。
Subject: Registration of MIME media type application/sieve
件名：MIMEメディアタイプアプリケーション/ふるいの登録
MIME media type name: application MIME subtype name: sieve Required parameters: none Optional parameters: none Encoding considerations: Most Sieve scripts will be textual, written in UTF-8. When non-7bit characters are used, quoted-printable is appropriate for transport systems that require 7bit encoding. Security considerations: Discussed in section 10 of this RFC. Interoperability considerations: Discussed in section 2.10.5 of this RFC. Published specification: this RFC. Applications that use this media type: sieve-enabled mail servers and clients Additional information: Magic number(s): File extension(s): .siv .sieve Macintosh File Type Code(s):
MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：SIVE必要なパラメーター：なしオプションのパラメーター：なしエンコーディング考慮事項：ほとんどのシーブスクリプトは、UTF-8で記述されます。7ビット文字以外の文字が使用される場合、引用された印刷可能なものは、7ビットエンコーディングを必要とする輸送システムに適しています。セキュリティ上の考慮事項：このRFCのセクション10で説明します。相互運用性の考慮事項：このRFCのセクション2.10.5で説明します。公開された仕様：このRFC。このメディアタイプを使用するアプリケーション：Sieve対応のメールサーバーとクライアントの追加情報：マジック番号：ファイル拡張機能：.siv .Sive Macintoshファイルタイプコード：
Person & email address to contact for further information: See the discussion list at ietf-mta-filters@imc.org. Intended usage: COMMON Author/Change controller: The SIEVE WG, delegated by the IESG.
詳細については、個人とメールアドレスをお問い合わせください。IETF-MTA-filters@imc.orgのディスカッションリストを参照してください。意図された使用法：共通の著者/変更コントローラー：SIEVE WG、IESGによって委任されました。
The Sieve grammar is separated into tokens and a separate grammar as most programming languages are. Additional rules are supplied here for common arguments to various language facilities.
シーブ文法は、ほとんどのプログラミング言語と同様に、トークンと別の文法に分けられます。ここでは、さまざまな言語施設への一般的な議論のために追加のルールが提供されています。
Sieve scripts are encoded in UTF-8. The following assumes a valid UTF-8 encoding; special characters in Sieve scripts are all US-ASCII.
ふるいスクリプトはUTF-8でエンコードされています。以下は、有効なUTF-8エンコーディングを想定しています。Sive Scriptsの特殊文字はすべてUS-ASCIIです。
The following are tokens in Sieve:
以下はふるいのトークンです：
- identifiers - tags - numbers - quoted strings - multi-line strings - other separators
- 識別子 - タグ - 数字 - 引用文字列 - マルチライン文字列 - 他のセパレーター
Identifiers, tags, and numbers are case-insensitive, while quoted strings and multi-line strings are case-sensitive.
識別子、タグ、および数値はケースに依存しませんが、引用された文字列とマルチライン文字列はケースに敏感です。
Blanks, horizontal tabs, CRLFs, and comments ("whitespace") are ignored except as they separate tokens. Some whitespace is required to separate otherwise adjacent tokens and in specific places in the multi-line strings. CR and LF can only appear in CRLF pairs.
ブランク、水平タブ、CRLF、およびコメント（「Whitespace」）は、トークンを分離する場合を除き、無視されます。一部の白文学は、隣接するトークンを分離し、マルチライン文字列の特定の場所で分離する必要があります。CRとLFはCRLFペアでのみ表示できます。
The other separators are single individual characters and are mentioned explicitly in the grammar.
他のセパレーターは単一の個別の文字であり、文法で明示的に言及されています。
The lexical structure of sieve is defined in the following grammar (as described in [ABNF]):
ふるいの語彙構造は、次の文法で定義されています（[ABNF]で説明されているように）：
bracket-comment = "/*" *not-star 1*STAR
*(not-star-slash *not-star 1*STAR) "/"
; No */ allowed inside a comment.
; (No * is allowed unless it is the last
; character, or unless it is followed by a
; character that isn't a slash.)
comment = bracket-comment / hash-comment
hash-comment = "#" *octet-not-crlf CRLF
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multiline-literal / multiline-dotstart)
"." CRLF
multiline-literal = [ octet-not-period *octet-not-crlf ] CRLF
multiline-dotstart = "." 1*octet-not-crlf CRLF
; A line containing only "." ends the
; multi-line. Remove a leading '.' if
; followed by another '.'.
not-star = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-FF
; either a CRLF pair, OR a single octet
; other than NUL, CR, LF, or star
not-star-slash = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-2E /
%x30-FF
; either a CRLF pair, OR a single octet
; other than NUL, CR, LF, star, or slash
number = 1*DIGIT [ QUANTIFIER ]
octet-not-crlf = %x01-09 / %x0B-0C / %x0E-FF
; a single octet other than NUL, CR, or LF
octet-not-period = %x01-09 / %x0B-0C / %x0E-2D / %x2F-FF
; a single octet other than NUL,
; CR, LF, or period
octet-not-qspecial = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / %x5D-FF
; a single octet other than NUL,
; CR, LF, double-quote, or backslash
QUANTIFIER = "K" / "M" / "G"
quoted-other = "\" octet-not-qspecial ; represents just the octet-no-qspecial ; character. SHOULD NOT be used
quoted-other = "\" Octet-not-qspecial;Octet-no-qspecialだけを表します。キャラクター。使用しないでください
quoted-safe = CRLF / octet-not-qspecial ; either a CRLF pair, OR a single octet other ; than NUL, CR, LF, double-quote, or backslash
QUOTED-SAFE = CRLF / OCTET-NOT-QSPECIAL;CRLFペア、またはその他の単一のオクテットのいずれか。nul、cr、lf、double-quote、またはbackslashより
quoted-special = "\" (DQUOTE / "\") ; represents just a double-quote or backslash
quoted special = "\"（dquote / "\"）;単なるダブルクォートまたはバックスラッシュを表します
quoted-string = DQUOTE quoted-text DQUOTE
quoted-text = *(quoted-safe / quoted-special / quoted-other)
STAR = "*"
star = "*"
tag = ":" identifier
tag = "："識別子
white-space = 1*(SP / CRLF / HTAB) / comment
The following is the grammar of Sieve after it has been lexically interpreted. No whitespace or comments appear below. The start symbol is "start".
以下は、逆に解釈された後のふるいの文法です。以下に白文学やコメントは表示されません。開始シンボルは「start」です。
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) ")"
These elements are collected from the "Syntax" sections elsewhere in this document, and are provided here in [ABNF] syntax so that they can be modified by extensions.
これらの要素は、このドキュメントの他の場所にある「構文」セクションから収集され、[ABNF]構文でここで提供されるため、拡張機能によって変更できます。
ADDRESS-PART = ":localpart" / ":domain" / ":all"
COMPARATOR = ":comparator" string
MATCH-TYPE = ":is" / ":contains" / ":matches"
The following is an extended example of a Sieve script. Note that it does not make use of the implicit keep.
以下は、ふるいスクリプトの拡張例です。暗黙のキープを使用していないことに注意してください。
# # Example Sieve Filter # Declare any optional features or extension used by the script # require ["fileinto"];
＃＃例のシーブフィルター＃スクリプトで使用されるオプションの機能または拡張機能を宣言します＃["fileinto"];
#
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter mailbox
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
fileinto "filter"; # move to "filter" mailbox
}
#
# Keep all messages to or from people in my company
#
elsif address :DOMAIN :is ["From", "To"] "example.com"
{
keep; # keep in "In" mailbox
}
#
# Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away.
#
elsif anyof (NOT address :all :contains
["To", "Cc", "Bcc"] "me@example.com",
header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"])
{
fileinto "spam"; # move to "spam" mailbox
}
else
{
# Move all other (non-company) mail to "personal"
# mailbox.
fileinto "personal";
}
Users must get their mail. It is imperative that whatever implementations use to store the user-defined filtering scripts protect them from unauthorized modification, to preserve the integrity of the mail system. An attacker who can modify a script can cause mail to be discarded, rejected, or forwarded to an unauthorized recipient. In addition, it's possible that Sieve scripts might expose private information, such as mailbox names, or email addresses of favored (or disfavored) correspondents. Because of that, scripts SHOULD also be protected from unauthorized retrieval.
ユーザーはメールを取得する必要があります。ユーザー定義のフィルタリングスクリプトを保存するために使用する実装を使用して、メールシステムの整合性を維持するために、不正な変更から保護することが不可欠です。スクリプトを変更できる攻撃者は、許可されていない受信者にメールを破棄、拒否、または転送することができます。さらに、Sieveスクリプトは、メールボックス名などの個人情報や、好まれた（または不利な）特派員の電子メールアドレスを公開する可能性があります。そのため、スクリプトも許可されていない検索から保護する必要があります。
Several commands, such as "discard", "redirect", and "fileinto", allow for actions to be taken that are potentially very dangerous.
「破棄」、「リダイレクト」、「fileinto」などのいくつかのコマンドは、潜在的に非常に危険なアクションを実行することを可能にします。
Use of the "redirect" command to generate notifications may easily overwhelm the target address, especially if it was not designed to handle large messages.
「リダイレクト」コマンドを使用して通知を生成すると、特に大きなメッセージを処理するように設計されていない場合は、ターゲットアドレスを簡単に圧倒する場合があります。
Allowing a single script to redirect to multiple destinations can be used as a means of amplifying the number of messages in an attack. Moreover, if loop detection is not properly implemented, it may be possible to set up exponentially growing message loops. Accordingly, Sieve implementations:
単一のスクリプトが複数の宛先にリダイレクトできるようにすることは、攻撃のメッセージの数を増幅する手段として使用できます。さらに、ループ検出が適切に実装されていない場合、指数関数的に成長するメッセージループを設定することが可能かもしれません。したがって、sieveの実装：
(1) MUST implement facilities to detect and break message loops. See section 6.2 of [SMTP] for additional information on basic loop detection strategies.
(1) メッセージループを検出して壊すための機能を実装する必要があります。基本ループ検出戦略の追加情報については、[SMTP]のセクション6.2を参照してください。
(2) MUST provide the means for administrators to limit the ability of users to abuse redirect. In particular, it MUST be possible to limit the number of redirects a script can perform. Additionally, if no use cases exist for using redirect to multiple destinations, this limit SHOULD be set to 1. Additional limits, such as the ability to restrict redirect to local users, MAY also be implemented.
(2) 管理者がリダイレクトを悪用する能力を制限する手段を提供する必要があります。特に、実行できるリダイレクトのリダイレクトの数を制限することが可能である必要があります。さらに、複数の宛先にリダイレクトを使用するためのユースケースが存在しない場合、この制限は1に設定する必要があります。ローカルユーザーへのリダイレクトを制限する機能など、追加の制限も実装できます。
(3) MUST provide facilities to log use of redirect in order to facilitate tracking down abuse.
(3) 虐待の追跡を容易にするために、リダイレクトの使用を記録する施設を提供する必要があります。
(4) MAY use script analysis to determine whether or not a given script can be executed safely. While the Sieve language is sufficiently complex that full analysis of all possible scripts is computationally infeasible, the majority of real-world scripts are amenable to analysis. For example, an implementation might allow scripts that it has determined are safe to run unhindered, block scripts that are potentially problematic, and subject unclassifiable scripts to additional auditing and logging.
(4) スクリプト分析を使用して、特定のスクリプトを安全に実行できるかどうかを判断できます。ふるい言語は十分に複雑であるため、可能なすべてのスクリプトの完全な分析は計算的に実行不可能ですが、実際のスクリプトの大部分は分析に適しています。たとえば、実装では、妨げられないスクリプト、潜在的に問題があるブロックスクリプトを実行することができると判断したスクリプトが、追加の監査とロギングを非分類できないスクリプトを実行できるようにする場合があります。
Allowing redirects at all may not be appropriate in situations where email accounts are freely available and/or not trackable to a human who can be held accountable for creating message bombs or other abuse.
電子メールアカウントが自由に利用可能である、および/またはメッセージ爆弾やその他の虐待の作成に責任を負うことができる人間が追跡できない状況では、リダイレクトをまったく許可することは適切ではないかもしれません。
As with any filter on a message stream, if the Sieve implementation and the mail agents 'behind' Sieve in the message stream differ in their interpretation of the messages, it may be possible for an attacker to subvert the filter. Of particular note are differences in the interpretation of malformed messages (e.g., missing or extra syntax characters) or those that exhibit corner cases (e.g., NUL octets encoded via [MIME3]).
メッセージストリーム上の任意のフィルターと同様に、メッセージストリームの「ふるいの背後にあるふるい」がメッセージの解釈が異なる場合、攻撃者がフィルターを覆す可能性があります。特に注目すべきは、奇形のメッセージ（例：欠落または追加の構文文字）またはコーナーケースを示すもの（[MIME3]を介してエンコードされたNULオクテット）の解釈の違いです。
This document has been revised in part based on comments and discussions that took place on and off the SIEVE mailing list. Thanks to Sharon Chisholm, Cyrus Daboo, Ned Freed, Arnt Gulbrandsen, Michael Haardt, Kjetil Torgrim Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Eric Rescorla, Rob Siemborski, and Nigel Swinson for reviews and suggestions.
このドキュメントは、ふるいメーリングリストの内外で行われたコメントと議論に基づいて部分的に改訂されています。シャロン・チショルム、サイラス・ダブー、ネッド・フリード、アルント・ガルブランドセン、マイケル・ハード、キティル・トーグリム・ホム、バリー・レイバ、マーク・E・マレット、アレクセイ・メルニコフ、エリック・レスカフ、ロブ・シエンボルスキー、ニゲル・スウィンソンのレビューと提案のおかげで。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[照合] Newman、C.、Duerst、M。、およびA. Gulbrandsen、「Internet Application Protocol Collation Registry」、RFC 4790、2007年3月。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[imail] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[Mime3] Moore、K。、「Mime（多目的インターネットメールエクステンション）パート3：非ASCIIテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in electrical technology - Part 2: Telecommunications and electronics", January 1999.
[binary-si] "標準IEC 60027-2：電気技術で使用される文字記号 - パート2：電気通信と電子機器」、1999年1月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and Cooperative Work in a Practical Multimedia Message System", Int. J. of Man-Machine Studies, April, 1991. Reprinted in Computer-Supported Cooperative Work and Groupware, Saul Greenberg, editor, Harcourt Brace Jovanovich, 1991. Reprinted in Readings in Groupware and Computer-Supported Cooperative Work, Ronald Baecker, editor, Morgan Kaufmann, 1993.
[Flames] Borenstein、N、およびC. Thyberg、「Power、使いやすさ、実用的なマルチメディアメッセージシステムにおける協同組合」、Int。J. of Man-Machine Studies、1991年4月。コンピューターが支援する協同組合とグループウェア、Saul Greenberg、編集者、Harcourt Brace Jovanovich、1991。モーガン・カウフマン、1993年。
[IMAP] Crispin, M., "Internet Message Access Protocol - version 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN] Hansen、T.、ed。、およびG. Vaudreuil、ed。、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[RFC3028] Showalter、T。、「Sieve：A Mail Filtering Language」、RFC 3028、2001年1月。
This following list is a summary of the changes that have been made in the Sieve language base specification from [RFC3028].
この次のリストは、[RFC3028]からのふるい言語ベース仕様で行われた変更の要約です。
1. Removed ban on tests having side-effects 2. Removed reject extension (will be specified in a separate RFC) 3. Clarified description of comparators to match [COLLATION], the new base specification for them 4. Require stripping of leading and trailing whitespace in "header" test 5. Clarified or tightened handling of many minor items, including: - invalid [MIME3] encoding - invalid addresses in headers - invalid header field names in tests - 'undefined' comparator result - unknown envelope parts - null return-path in "envelope" test 6. Capability strings are case-sensitive 7. Clarified that fileinto should reencode non-ASCII mailbox names to match the mailstore's conventions 8. Errors in the ABNF were corrected 9. The references were updated and split into normative and informative 10. Added encoded-character capability and deprecated (but did not remove) use of arbitrary binary octets in Sieve scripts. 11. Updated IANA registration template, and added IANA considerations to permit capability prefix registrations. 12. Added .sieve as a valid extension for Sieve scripts.
1.副作用を有するテストの禁止を削除2.拒否された拒否拡張（個別のRFCで指定されます）3。一致する[照合]、それらの新しいベース仕様を一致させるためのコンパレータの明確な説明4.リーディングとトレーリングの剥奪が必要「ヘッダー」テストのホワイトスペース5.以下を含む多くのマイナーアイテムの明確化または締め付け処理： - 無効な[MIME3]エンコード - ヘッダーの無効なアドレス - テストでの無効なヘッダーフィールド名 - '未定義の比較結果 - 未知のエンベロープパーツ - ヌルリターン - 「エンベロープ」テストのパス6.機能文字列はケースに敏感です7. fileIntoがメールストアの規則に一致するように非ASCIIメールボックス名を再エンコードする必要があることを明確にしました8. ABNFのエラーが修正されました。および有益な10.エンコードされたキャラクター機能を追加し、シーブスクリプトで任意のバイナリオクテットの使用を非推奨（ただし除去しませんでした）。11. IANA登録テンプレートを更新し、IANAの考慮事項を追加して、機能のプレフィックス登録を許可しました。12. Sive Sive Scriptsの有効な拡張機能としてSiveを追加しました。
Editors' Addresses
編集者のアドレス
Philip Guenther Sendmail, Inc. 6425 Christie St. Ste 400 Emeryville, CA 94608 EMail: guenther@sendmail.com
Philip Guenther Sendmail、Inc。6425 Christie St. Ste 400 Emeryville、CA 94608メール：guenther@sendmail.com
Tim Showalter EMail: tjs@psaux.com
Tim Showalterメール：tjs@psaux.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。