Network Working Group P. Guenther, Ed.
Request for Comments: 5228 Sendmail, Inc.
Obsoletes: 3028 T. Showalter, Ed.
Category: Standards Track January 2008
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
Sieve：一种电子邮件过滤语言
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.
本文档描述了在最终发送时过滤电子邮件的语言。它被设计为可以在邮件客户端或邮件服务器上实现。它是可扩展的、简单的，并且独立于访问协议、邮件体系结构和操作系统。它适合在不允许用户执行任意程序的邮件服务器上运行，例如在黑盒Internet消息访问协议（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
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
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.
当邮件移动到用户可访问的邮箱时，在最终传递期间将执行在Sieve中编写的脚本。在邮件传输代理（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.
卡内基梅隆大学的经验表明，如果向用户提供过滤系统，许多人会利用它来归档来自特定用户或邮件列表的邮件。然而，由于设置困难，许多其他人并没有使用Andrew系统的FLAMES过滤语言[FLAMES]。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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].
命令（测试、操作或控件）的每个部分都有一行标记为“用法：”。此行描述命令的用法，包括其名称和参数。必需的参数列在尖括号（“<”和“>”）内。可选参数列在方括号（“[”和“]”）内。每个参数后面跟着它的类型，因此“<key:string>”表示一个名为“key”的参数，该参数是一个字符串。文字字符串用双引号字符串表示。备选方案用斜线分隔，括号用于分组，类似于[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.
在“用法：”行中，有三个经常重复的特殊语法：匹配类型、比较器和地址部分。第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
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
-----------------------------------------------------------
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! $$$
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!
-----------------------------------------------------------
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.
该语言由一组命令组成。每个命令都由一组由空格分隔的标记组成。命令标识符是第一个标记，后跟零个或多个参数标记。参数可以是文字数据、标记、命令块或测试命令。
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字符。字符串和注释可能包含US-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.
空格用于分隔标记。空格由制表符、换行符（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).
提供了两种类型的评论。注释在语义上等同于空白，可以在空白所在的任何地方使用（多行字符串中的一个例外，如语法中所述）。
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;
}
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
*/ ;
}
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].
数字以普通十进制数字的形式给出。作为表示较大值（例如消息大小）的简写，可附加后缀“K”、“M”或“G”以指示二的幂的倍数。为了与计算机经常使用的两种基于国际单位制的版本的功率相比较，“K”指定kibi-，或1024（2^10）倍的数值；“M”指定mebi-，或数字值的1048576（2^20）倍；“G”指定gibi-，或1073741824（2^30）乘以数字[BINARY-SI]的值。
Implementations MUST support integer values in the inclusive range zero to 2,147,483,647 (2^31 - 1), but MAY support larger values.
实现必须支持0到2147483647（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.
带引号的字符串以单双引号（<>字符，US-ASCII 34）开始和结束。带引号的字符串中的反斜杠（\”，US-ASCII 92）后跟另一个反斜杠或双引号。这两个字符序列分别表示值中的单反斜杠或双引号。
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编码字符串的能力与现有实践相匹配，并且在无效数据的测试和包含原始MIME部分的参数（用于生成传出消息的扩展操作）中都被证明是有用的。
For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. The CRLF before the final period is considered part of the value. In order to allow the message to contain lines with a single dot, lines are dot-stuffed. That is, when composing a message body, an extra '.' is added before each line that begins with a '.'. When the server interprets the script, these extra dots are removed. Note that a line that begins with a dot followed by a non-dot character is not interpreted as dot-stuffed;
对于输入大量文本（如电子邮件），允许使用多行表单。它以关键字“text:”开头，后跟一个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.
请注意，散列注释或空格可能出现在“text:”和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.
在匹配模式时，通常可以方便地对字符串组而不是单个字符串进行匹配。因此，许多测试中都允许使用字符串列表，这意味着如果使用任何一个字符串的测试为true，那么测试为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”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"]'.
相反，在字符串列表适用的任何情况下，允许单个字符串而不是列表的成员：它相当于具有单个成员的列表。这意味着测试“exists”To“”等同于测试“exists[”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.
标题是字符串的子集。在Internet消息规范[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
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八位字节，可以在字符串中嵌入任意八位字节。序列由八位字节替换，每个十六进制对给出十六进制值。
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
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字符可能不方便或不可取，在这些情况下，可以使用语法编码的Unicode字符。该序列由指定Unicode字符的UTF-8编码替换，这些字符由Unicode十六进制的十六进制值标识。
encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = *blank unicode-hex
*(1*blank unicode-hex) *blank
unicode-hex = 1*HEXDIG
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.)
脚本使用的十六进制值既不在0到D7FF范围内，也不在E000到10FFFF范围内，这是一个错误。（D800到DFFF的范围被排除在外，因为这些字符号仅用作UTF-16编码形式的一部分，不适用于此处语法表示的UTF-8编码。）
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.
注意：除非包含Unicode值的序列符合语法，否则实现不得引发超出范围的Unicode值的错误。
The capability string for use with the require command is "encoded-character".
与require命令一起使用的功能字符串是“编码字符”。
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:
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
"$${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.
一些测试（“allof”和“anyof”，分别实现逻辑“and”和逻辑“or”）可能需要不止一个测试作为参数。testlist语法元素提供了一种将测试分组为括号中逗号分隔列表的方法。
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.com") {
discard;
}
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.
为了指定要执行的操作，大多数命令都使用参数。有三种类型的参数：位置参数、标记参数和可选参数。
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.
一个特别值得注意的例子是“：comparator”参数，它允许用户指定将使用哪个comparator[COLLATION]来比较两个字符串，因为不同的语言可能会对UTF-8[UTF-8]字符串施加不同的顺序。
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节中的语法提供了一个可解析的版本：参数是字符串列表（字符串列表）、数字和标记，后面可能是测试或测试列表（测试列表），后面可能是命令块。不能使用多个测试或测试列表，或多个命令块，以命令块结尾的命令不以分号结尾。
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.
将一个字符串与另一个字符串进行匹配时，有多种方法可以执行匹配操作。这是通过三种类型的匹配完成的：精确匹配、子字符串匹配和通配符glob样式匹配。下文对这些问题进行了说明。
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使用Internet应用程序协议排序注册表[Collation]中定义的比较器。
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".
执行字符串比较的命令可能具有可选的匹配类型参数。本规范中的三种匹配类型是：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”匹配类型描述子字符串匹配。如果value参数包含键参数作为子字符串，则匹配为true。例如，字符串“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”匹配类型描述绝对匹配；如果第一个字符串的内容与第二个字符串的内容完全相同，则它们匹配。只有字符串“frobnitzm”是字符串“frobnitzm”。空键（“”）only“：is”与空值匹配。
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.
“：matches”匹配类型使用字符“*”和“？”指定通配符匹配；必须匹配整个值。“*”匹配值中的零个或多个字符，“？”匹配值中的单个字符，其中使用的比较器（见第2.7.3节）定义了字符的含义。例如，比较器“i；八位字节”和“i；ascii casemap”将字符定义为单个八位字节，因此当其中一个比较器正在使用时“？”始终恰好匹配一个八位字节。相反，基于Unicode的比较器将字符定义为编码一个Unicode字符的任何UTF-8八位字节序列，因此“？”可以匹配多个八位字节。“？”和“*”可以在字符串中转义为“\\？”和“\\*”，以匹配它们自己。第一个反斜杠跳过第二个反斜杠；他们一起逃过了“*”这个词。这很尴尬，但在使用globs和正则表达式的几种编程语言中，这是很常见的。
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”或“：matches”比较器是错误的。
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:
为方便起见，“MATCH-TYPE”语法元素定义如下：
Syntax: ":is" / ":contains" / ":matches"
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]中标题字段的文本转换为Unicode，编码为UTF-8，作为比较器的输入（参见第2.7.3节）。实现必须能够转换US-ASCII、ISO-8859-1、ISO-8859-*字符集的US-ASCII子集和UTF-8。由于任何原因，实现无法转换为Unicode的文本可被视为纯US-ASCII（包括任何[MIME3]语法）或根据本地约定进行处理。编码的NUL八位字节（零字符）不应导致所比较的头内容提前终止。
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的八位字节，则不能认为两个字符串相等。
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应用程序协议整理注册表[整理]提供了描述和命名比较器的框架。
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.
Sieve将“未定义”的比较器结果视为“不匹配”的结果。也就是说，此基本规范不提供任何直接检测无效比较器输入的方法。
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:
比较器由“：comparator”选项和支持匹配的命令指定。此选项后面是一个字符串，提供要使用的比较器的名称。为方便起见，比较器的语法缩写为“comparator”（在多个测试中重复），如下所示：
Syntax: ":comparator" <comparator-name: string>
Syntax: ":comparator" <comparator-name: string>
So in this example,
所以在这个例子中，
Example: if header :contains :comparator "i;octet" "Subject"
"MAKE MONEY FAST" {
discard;
}
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”之外的比较器必须用require声明，因为它们是扩展。如果使用require声明的比较器未知，则这是一个错误，执行失败。如果比较器没有用require声明，那么即使比较器受支持，这也是一个错误。（见第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”和“：contains”匹配类型都与“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.
地址是最常用的字符串形式之一。这些都是结构化的，能够与地址的本地部分或域进行比较是很有用的，因此一些只作用于地址的测试会使用一个额外的可选参数来指定测试作用于什么。
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”和“：all”，它们作用于本地部分（左侧）、域部分（右侧）和整个地址。
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".
如果省略了可选地址部分，则默认值为“：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:
为方便起见，“ADDRESS-PART”语法元素定义如下：
Syntax: ":localpart" / ":domain" / ":all"
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.
对于本备忘录中提供的命令，没有循环。提供的控制结构（if、elsif和else）可以运行一次块，也可以不运行。
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.
有三种命令：测试命令、动作命令和控制命令。
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
- keep，将邮件保存在默认位置-fileinto，将邮件保存在特定邮箱-重定向，将邮件转发到其他地址-discard，以静默方式丢弃邮件
A control command is a command that affects the parsing or the flow of execution of the Sieve script in some way. A control structure is a control command that ends with a block instead of a semicolon.
控制命令是以某种方式影响Sieve脚本的解析或执行流的命令。控制结构是以块而不是分号结尾的控制命令。
A test command is used as part of a control command. It is used to specify whether or not the block of code given to the control command is executed.
测试命令用作控制命令的一部分。它用于指定是否执行给定给控制命令的代码块。
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".
以前使用过滤系统的经验表明，脚本中往往会遗漏案例。为了防止错误，Sieve有一个“隐式保留”。
An implicit keep is a keep action (see section 4.3) performed in absence of any action that cancels the implicit keep.
隐式保留是在没有任何取消隐式保留的操作的情况下执行的保留操作（见第4.3节）。
An implicit keep is performed if a message is not written to a mailbox, redirected to a new address, or explicitly thrown out. That is, if a fileinto, a keep, a redirect, or a discard is performed, an implicit keep is not.
如果邮件未写入邮箱、重定向到新地址或显式抛出，则执行隐式保留。也就是说，如果执行fileinto、保留、重定向或放弃，则不会执行隐式保留。
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; }
Example: if size :over 500K { discard; }
As a result, the implicit keep is taken.
因此，采用隐式keep。
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.
实现不应将消息多次传递到同一邮箱，即使脚本明确要求将消息写入邮箱两次。
The test for equality of two messages is implementation-defined.
两条消息相等的测试由实现定义。
If a script asks for a message to be written to a mailbox twice, it MUST NOT be treated as an error.
如果脚本要求将邮件写入邮箱两次，则不得将其视为错误。
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.
实现必须至少允许一个keep或一个fileinto。如果未实现fileinto，则实现必须至少允许一次保留。
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.
由于许多邮件系统的功能不同，本规范的几个功能是可选的。在执行这些扩展之前，必须使用“require”操作声明它们。
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.
如果扩展未启用“require”，则实现必须将其视为根本不支持扩展。这可以防止脚本的行为被脚本作者可能不知道的扩展所改变。
Implementations MUST NOT execute any Sieve script test or command subsequent to "require" if one of the required extensions is unavailable.
如果所需扩展之一不可用，则实现不得执行“require”之后的任何筛选脚本测试或命令。
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有三个部分：“if”、“elsif”和“else”。就语法而言，每个命令实际上是一个单独的命令。但是，elsif或elsif必须仅在if或elsif之后。如果不满足这些条件，则会发生错误。
Usage: if <test1: test> <block1: block>
Usage: if <test1: test> <block1: block>
Usage: elsif <test2: test> <block2: block>
Usage: elsif <test2: test> <block2: block>
Usage: else <block3: 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.
如果“如果”测试为假，则评估第一个“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时，可能会出现“else”情况。如果存在，并且If或elsif测试均为true，则解释器将运行else的块。
This provides a way of performing exactly one of the blocks in the chain.
这提供了一种精确执行链中一个块的方法。
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";
}
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";
}
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 if…”序列。这是故意的，因为此构造会产生移位-减少冲突。
Usage: require <capabilities: string-list>
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.
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.
必须先使用require命令（如果存在），然后才能使用require以外的任何命令。如果require出现在require以外的命令之后，则会发生错误。
Example: require ["fileinto", "reject"];
示例：要求[“文件导入”，“拒绝”]；
Example: require "fileinto";
require "vacation";
Example: require "fileinto";
require "vacation";
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.
本文档提供了可以对消息执行的四个操作：保留、文件导入、重定向和放弃。
Implementations MUST support the "keep", "discard", and "redirect" actions.
实现必须支持“保留”、“放弃”和“重定向”操作。
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>
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重新编码到其编码方案中。例如，Internet消息访问协议[IMAP]使用修改后的UTF-7，因此“零碎和零碎”的邮箱参数将在IMAP中显示为“零碎和零碎”。
The capability string for use with the require command is "fileinto".
与require命令一起使用的功能字符串是“fileinto”。
In the following script, message A is filed into mailbox "INBOX.harassment".
在下面的脚本中，邮件A被归档到邮箱“INBOX.harrist”中。
Example: require "fileinto";
if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment";
}
Example: require "fileinto";
if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment";
}
Usage: redirect <address: string>
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.)
消息以信封收件人的身份与重定向命令中的地址一起发回。实现可以将给定消息的单独重定向合并到具有多个信封收件人的单个提交中。（这不是邮件用户代理（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.
传出消息上的信封发送者地址由sieve实现选择。它可以从正在处理的邮件中复制。但是，如果正在处理的邮件具有空信封发件人地址，则传出邮件也必须具有空信封发件人地址。这最后一个要求是为了防止在消息被重定向到无效地址的情况下出现循环，然后返回传递状态通知，该通知最终也被重定向到相同的无效地址。
A simple script can be used for redirecting all mail:
可以使用一个简单的脚本重定向所有邮件：
Example: redirect "bart@example.com";
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.
实现必须提供限制Sieve脚本可以执行的重定向数量的方法。详见第10节。
Implementations MAY ignore a redirect action silently due to policy reasons. For example, an implementation MAY choose not to redirect to an address that is known to be undeliverable. Any ignored redirect MUST NOT cancel the implicit keep.
由于策略原因，实现可能会以静默方式忽略重定向操作。例如，一个实现可以选择不重定向到已知无法传递的地址。任何被忽略的重定向都不能取消隐式保留。
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; }
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; }
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.)
Discard用于无声地丢弃消息。它通过简单地取消隐式keep来实现。如果discard与其他操作一起使用，则其他操作仍会发生。放弃与所有其他操作兼容。（例如，fileinto+discard相当于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.
在以下脚本中，来自“”的任何邮件idiot@example.com“被扔掉了。
Example: if header :contains ["from"] ["idiot@example.com"] {
discard;
}
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.
虽然这门语言的一个重要部分是“discard”，但它可能会给用户带来严重的问题：让自己登录到公共计算机实验室无人值守的机器上的学生可能会发现他们的脚本更改为“discard”。为了在这种情况下（以及类似情况下）保护用户，实现可能会无限期地保留由脚本销毁的消息，并且可能不允许使用丢弃所有邮件的脚本。
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".
实现必须支持这些测试：“address”、“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>
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.
“地址”测试匹配包含地址的结构化头中的Internet地址。如果任何标头在地址的指定部分包含任何键（由比较器和匹配关键字修改），则返回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.
和信封和标头一样，若标头列表和键列表参数的任何组合匹配，则该测试返回true，否则返回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.
Internet电子邮件地址[IMAIL]有一个有些尴尬的特点，即at标志左侧的本地部分被视为区分大小写，而at标志右侧的域部分则不区分大小写。“address”命令本身不处理这个问题，但提供了address-PART参数，允许用户处理它。
The address primitive never acts on the phrase part of an email address or on comments within that address. It also never acts on group names, although it does act on the addresses within the group construct.
地址原语从不作用于电子邮件地址的短语部分或该地址内的评论。它也从不作用于组名，尽管它作用于组构造中的地址。
Implementations MUST restrict the address test to headers that contain addresses, but MUST include at least From, To, Cc, Bcc, Sender, Resent-From, and Resent-To, and it SHOULD include any other header that utilizes an "address-list" structured header body.
实现必须将地址测试限制为包含地址的头，但必须至少包括From、to、Cc、Bcc、Sender、Resent From和Resent to，并且应该包括使用“地址列表”结构化头体的任何其他头。
Example: if address :is :all "from" "tim@example.com" {
discard;
}
Example: if address :is :all "from" "tim@example.com" {
discard;
}
Usage: allof <tests: test-list>
Usage: allof <tests: test-list>
The "allof" test performs a logical AND on the tests supplied to it.
“allof”测试对提供给它的测试执行逻辑AND。
Example: allof (false, false) => false
allof (false, true) => false
allof (true, true) => true
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>
Usage: anyof <tests: test-list>
The "anyof" test performs a logical OR on the tests supplied to it.
“anyof”测试对提供给它的测试执行逻辑OR。
Example: anyof (false, false) => false
anyof (false, true) => true
anyof (true, true) => true
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>
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.
如果[SMTP]（或等效）信封的指定部分与指定密钥匹配，“信封”测试为真。本规范定义了（不区分大小写）“from”和“to”封套部分的解释。其他外壳部件可由其他扩展件定义；实现应该考虑未知的信封部分错误。
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.
如果其中一个信封部分字符串为（不区分大小写）“发件人”，则会与SMTP邮件命令中使用的发件人地址进行匹配。不管指定的ADDRESS-PART参数是什么，空反向路径都将作为空字符串进行匹配。
If one of the envelope-part strings is (case insensitive) "to", then matching occurs against the TO address used in the SMTP RCPT command that resulted in this message getting delivered to this user. Note that only the most recent TO is available, and only the one relevant to this user.
如果其中一个信封部分字符串为（不区分大小写）“to”，则会与SMTP RCPT命令中使用的to地址进行匹配，该命令导致将此邮件传递给此用户。请注意，只有最新的TO可用，并且只有与此用户相关的TO可用。
The envelope-part is a string list and may contain more than one parameter, in which case all of the strings specified in the key-list are matched against all parts given in the envelope-part list.
信封部分是一个字符串列表，可能包含多个参数，在这种情况下，键列表中指定的所有字符串都与信封部分列表中给出的所有部分匹配。
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.
和address和header一样，如果信封部件列表和键列表参数的任何组合匹配，则该测试返回true，否则返回false。
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".
信封命令是可选的。实现应该支持它，但并非所有情况下都可以获得必要的信息。与require命令一起使用的功能字符串是“信封”。
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
Usage: exists <header-names: string-list>
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.
如果消息中存在header names参数中列出的头，则“exists”测试为真。所有标题必须存在，否则测试为false。
The following example throws out mail that doesn't have a From header and a Date header.
下面的示例抛出没有From标头和Date标头的邮件。
Example: if not exists ["From","Date"] {
discard;
}
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>
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.
如果任何命名头的值（忽略前导和尾随空格）与任何键匹配，则“header”测试的计算结果为true。匹配类型由可选匹配参数指定，如第2.6节所述，如果未指定，则默认为“：is”。
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.
和address和envelope一样，若头名称列表和键列表参数的任何组合匹配，则该测试返回true，否则返回false。
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
如果header names参数中列出的头存在，则它包含空键（“”）。但是，如果命名标头不存在，则它与任何键（包括空键）都不匹配。因此，如果消息包含头
X-Caffeine: C8H10N4O2
X-咖啡因：C8H10N4O2
these tests on that header evaluate as follows:
该标题上的这些测试评估如下：
header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true
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:
可以使用否定的“header”测试来测试给定的头是否不存在或不包含任何非空白字符：
not header :matches "Cc" "?*"
非标题：匹配“Cc”“？*”
Usage: not <test1: test>
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”测试将其他测试作为参数，并产生相反的结果。“not false”计算为“true”，而“not true”计算为“false”。
Usage: size <":over" / ":under"> <limit: number>
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.
如果参数为“：over”，且消息大小大于提供的数字，则测试为真；否则，这是错误的。
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.
请注意，对于正好为4000个八位字节的消息，该消息既不是“：over”也不是“：under”4000个八位字节。
Usage: true
用法：true
The "true" test always evaluates to true.
“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节中定义的约束交互，例如，它们是否取消隐式保留，以及它们与哪些操作兼容和不兼容。扩展不能改变“require”控件命令的行为，也不能改变参数对“require”控件的解释。
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.
编码字符字符串“encoded character”表示实现支持字符串中“${hex:…}”和“${unicode:…}”的解释。
envelope The string "envelope" indicates that the implementation supports the "envelope" command.
envelope字符串“envelope”表示实现支持“envelope”命令。
fileinto The string "fileinto" indicates that the implementation supports the "fileinto" command.
fileinto字符串“fileinto”表示实现支持“fileinto”命令。
comparator- The string "comparator-elbonia" is provided if the implementation supports the "elbonia" comparator. Therefore, all implementations have at least the "comparator-i;octet" and "comparator-i;ascii-casemap" capabilities. However, these comparators may be used without being declared with require.
比较器-如果实现支持“elbonia”比较器，则提供字符串“comparator elbonia”。因此，所有实现都至少具有“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]
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。添加了一个空的“说明”字段4。“标准跑道/IESG批准的实验RFC编号”字段已重命名为“RFC编号”5。“联系人和电子邮件地址以获取更多信息”字段应重命名为“联系人地址”
This RFC updates the following entries in the IANA registry for Sieve extensions.
此RFC更新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编号表示任意八位字节和Unicode字符：RFC 5228（筛基规范）联系地址：筛讨论列表<ietf mta-filters@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: 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: 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>
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子类型名称：筛选必需参数：无可选参数：无编码注意事项：大多数筛选脚本都是文本的，用UTF-8编写。使用非7bit字符时，带引号的可打印字符适用于需要7bit编码的传输系统。安全注意事项：在本RFC第10节中讨论。互操作性注意事项：在本RFC第2.10.5节中讨论。已发布规范：此RFC。使用此媒体类型的应用程序：启用筛选的邮件服务器和客户端其他信息：幻数：文件扩展名：.siv.sieve 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. 预期用途：共同作者/变更控制者：由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编码；筛脚本中的特殊字符均为US-ASCII。
The following are tokens in Sieve:
以下是Sieve中的令牌：
- identifiers - tags - numbers - quoted strings - multi-line strings - other separators
- 标识符-标签-数字-带引号的字符串-多行字符串-其他分隔符
Identifiers, tags, and numbers are case-insensitive, while quoted strings and multi-line strings are case-sensitive.
标识符、标记和数字不区分大小写，而带引号的字符串和多行字符串区分大小写。
Blanks, horizontal tabs, CRLFs, and comments ("whitespace") are ignored except as they separate tokens. Some whitespace is required to separate otherwise adjacent tokens and in specific places in the multi-line strings. CR and LF can only appear in CRLF pairs.
空白、水平制表符、CRLF和注释（“空白”）将被忽略，除非它们分隔标记。需要一些空格来分隔多行字符串中其他相邻的标记和特定位置。CR和LF只能成对出现。
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.)
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
comment = bracket-comment / hash-comment
hash-comment = "#" *octet-not-crlf CRLF
hash-comment = "#" *octet-not-crlf CRLF
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multiline-literal / multiline-dotstart)
"." CRLF
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multiline-literal / multiline-dotstart)
"." CRLF
multiline-literal = [ octet-not-period *octet-not-crlf ] 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 '.'.
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 = 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
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 ]
number = 1*DIGIT [ QUANTIFIER ]
octet-not-crlf = %x01-09 / %x0B-0C / %x0E-FF
; a single octet other than NUL, CR, or LF
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-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
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"
QUANTIFIER = "K" / "M" / "G"
quoted-other = "\" octet-not-qspecial ; represents just the octet-no-qspecial ; character. SHOULD NOT be used
引用的other=“\”八位字节不特别；仅表示八位字节，无特殊性；性格不应使用
quoted-safe = CRLF / octet-not-qspecial ; either a CRLF pair, OR a single octet other ; than NUL, CR, LF, double-quote, or backslash
引用安全=CRLF/八位字节非特殊；一对CRLF或一对八位组；而不是NUL、CR、LF、双引号或反斜杠
quoted-special = "\" (DQUOTE / "\") ; represents just a double-quote or backslash
特殊报价=“\”（DQUOTE/“\”）；仅表示双引号或反斜杠
quoted-string = DQUOTE quoted-text DQUOTE
quoted-string = DQUOTE quoted-text DQUOTE
quoted-text = *(quoted-safe / quoted-special / quoted-other)
quoted-text = *(quoted-safe / quoted-special / quoted-other)
STAR = "*"
STAR=“*”
tag = ":" identifier
tag=“：”标识符
white-space = 1*(SP / CRLF / HTAB) / comment
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".
下面是Sieve经过词汇解释后的语法。下面没有空白或注释。开始符号是“开始”。
argument = string-list / number / tag
argument = string-list / number / tag
arguments = *argument [ test / test-list ]
arguments = *argument [ test / test-list ]
block = "{" commands "}"
block = "{" commands "}"
command = identifier arguments (";" / block)
command = identifier arguments (";" / block)
commands = *command
commands = *command
start = commands
start = commands
string = quoted-string / multi-line
string = quoted-string / multi-line
string-list = "[" string *("," string) "]" / string
; if there is only a single string, the brackets
; are optional
string-list = "[" string *("," string) "]" / string
; if there is only a single string, the brackets
; are optional
test = identifier arguments
test = identifier arguments
test-list = "(" test *("," test) ")"
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"
ADDRESS-PART = ":localpart" / ":domain" / ":all"
COMPARATOR = ":comparator" string
COMPARATOR=“：COMPARATOR”字符串
MATCH-TYPE = ":is" / ":contains" / ":matches"
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.
下面是Sieve脚本的扩展示例。注意，它没有使用隐式keep。
# # Example Sieve Filter # Declare any optional features or extension used by the script # require ["fileinto"];
##示例筛选筛选器#声明脚本使用的任何可选功能或扩展#require[“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
}
#
# 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";
}
#
# 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.
用户必须收到他们的邮件。无论使用什么实现来存储用户定义的过滤脚本，都必须保护它们不受未经授权的修改，以保持邮件系统的完整性。可以修改脚本的攻击者可导致邮件被丢弃、拒绝或转发给未经授权的收件人。此外，筛选脚本可能会公开私人信息，例如邮箱名称或受欢迎（或不受欢迎）的通讯员的电子邮件地址。因此，还应保护脚本不被未经授权的检索。
Several commands, such as "discard", "redirect", and "fileinto", allow for actions to be taken that are potentially very dangerous.
一些命令，如“discard”、“redirect”和“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.
使用“redirect”命令生成通知可能会很容易地覆盖目标地址，特别是如果它不是为处理大型消息而设计的。
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:
允许一个脚本重定向到多个目的地可以作为放大攻击中消息数量的一种手段。此外，如果未正确实现循环检测，则可能会建立指数增长的消息循环。因此，筛选实现：
(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
(4) 可以使用脚本分析来确定给定脚本是否可以安全执行。虽然Sieve语言非常复杂，因此在计算上不可能对所有可能的脚本进行全面分析，但大多数现实世界的脚本都可以进行分析。例如，一个实现可能会
allow scripts that it has determined are safe to run unhindered, block scripts that are potentially problematic, and subject unclassifiable scripts to additional auditing and logging.
允许已确定安全的脚本不受阻碍地运行，阻止可能有问题的脚本，并对不可分类的脚本进行额外的审核和日志记录。
Allowing redirects at all may not be appropriate in situations where email accounts are freely available and/or not trackable to a human who can be held accountable for creating message bombs or other abuse.
在电子邮件帐户可以免费使用和/或无法追踪到制造邮件炸弹或其他滥用行为的人的情况下，允许重定向可能根本不合适。
As with any filter on a message stream, if the Sieve implementation and the mail agents 'behind' Sieve in the message stream differ in their interpretation of the messages, it may be possible for an attacker to subvert the filter. Of particular note are differences in the interpretation of malformed messages (e.g., missing or extra syntax characters) or those that exhibit corner cases (e.g., NUL octets encoded via [MIME3]).
与消息流上的任何筛选器一样，如果消息流中的筛实现和邮件代理“隐藏”筛对消息的解释不同，攻击者可能会破坏筛选器。特别值得注意的是，在解释格式错误的消息（例如，缺少或额外的语法字符）或显示角情况的消息（例如，通过[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.
本文件的修订部分基于在筛选邮件列表内外进行的评论和讨论。感谢莎伦·奇肖姆、塞勒斯·达布、内德·弗里德、阿恩特·古尔布兰森、迈克尔·哈尔特、杰蒂尔·托格里姆·霍姆、巴里·莱巴、马克·马列特、亚历克赛·梅尔尼科夫、埃里克·雷索拉、罗伯·西姆博斯基和奈杰尔·斯温森的评论和建议。
[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 42342005年10月。
[COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[整理]Newman，C.，Duerst，M.，和A.Gulbrandsen，“互联网应用程序协议整理注册表”，RFC 47902007年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.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年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.
[火焰]Borenstein，N和C.Thyberg，“实用多媒体信息系统中的功率、易用性和协作工作”，人机研究国际期刊，1991年4月。《计算机支持的协作工作和群件》再版，索尔·格林伯格，哈考特·布拉斯·约万诺维奇编辑，1991年。《群件和计算机支持的合作工作读物》再版，Ronald Baecker，Morgan Kaufmann编辑，1993年。
[IMAP] Crispin, M., "Internet Message Access Protocol - version 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年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.，“筛选：邮件过滤语言”，RFC3028，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。澄清了比较器的描述，以匹配[COLLATION]，新的比较器基本规范4。要求在“标题”测试5中去掉前导和尾随空格。澄清或加强了对许多次要项目的处理，包括：-无效[MIME3]编码-标题中的地址无效-测试中的标题字段名称无效-“未定义”比较器结果-未知信封部分-信封测试6中的返回路径为空。功能字符串区分大小写7。阐明fileinto应重新编码非ASCII邮箱名称以匹配邮件存储的约定8。ABNF中的错误已纠正9。对参考文件进行了更新，并将其分为规范性参考文件和信息性参考文件。增加了编码字符功能，并反对（但没有删除）在筛选脚本中使用任意二进制八位字节。11更新了IANA注册模板，并添加了IANA注意事项以允许功能前缀注册。12添加了.sieve作为sieve脚本的有效扩展名。
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）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.