Network Working Group T. Showalter
Request for Comments: 3028 Mirapoint, Inc.
Category: Standards Track January 2001
Network Working Group T. Showalter
Request for Comments: 3028 Mirapoint, Inc.
Category: Standards Track January 2001
Sieve: A Mail 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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs.
本文档描述了在最终传递时过滤电子邮件的语言。它被设计为可以在邮件客户端或邮件服务器上实现。它是可扩展的、简单的，并且独立于访问协议、邮件体系结构和操作系统。它适合在不允许用户执行任意程序的邮件服务器上运行，例如在黑盒Internet Message Access Protocol（IMAP）服务器上，因为它没有变量、循环或向外部程序输出的能力。
Table of Contents
目录
1. Introduction ........................................... 3
1.1. Conventions Used in This Document ..................... 4
1.2. Example mail messages ................................. 4
2. Design ................................................. 5
2.1. Form of the Language .................................. 5
2.2. Whitespace ............................................ 5
2.3. Comments .............................................. 6
2.4. Literal Data .......................................... 6
2.4.1. Numbers ............................................... 6
2.4.2. Strings ............................................... 7
2.4.2.1. String Lists .......................................... 7
2.4.2.2. Headers ............................................... 8
2.4.2.3. Addresses ............................................. 8
2.4.2.4. MIME Parts ............................................ 9
2.5. Tests ................................................. 9
2.5.1. Test Lists ............................................ 9
1. Introduction ........................................... 3
1.1. Conventions Used in This Document ..................... 4
1.2. Example mail messages ................................. 4
2. Design ................................................. 5
2.1. Form of the Language .................................. 5
2.2. Whitespace ............................................ 5
2.3. Comments .............................................. 6
2.4. Literal Data .......................................... 6
2.4.1. Numbers ............................................... 6
2.4.2. Strings ............................................... 7
2.4.2.1. String Lists .......................................... 7
2.4.2.2. Headers ............................................... 8
2.4.2.3. Addresses ............................................. 8
2.4.2.4. MIME Parts ............................................ 9
2.5. Tests ................................................. 9
2.5.1. Test Lists ............................................ 9
2.6. Arguments ............................................. 9
2.6.1. Positional Arguments .................................. 9
2.6.2. Tagged Arguments ...................................... 10
2.6.3. Optional Arguments .................................... 10
2.6.4. Types of Arguments .................................... 10
2.7. String Comparison ..................................... 11
2.7.1. Match Type ............................................ 11
2.7.2. Comparisons Across Character Sets ..................... 12
2.7.3. Comparators ........................................... 12
2.7.4. Comparisons Against Addresses ......................... 13
2.8. Blocks ................................................ 14
2.9. Commands .............................................. 14
2.10. Evaluation ............................................ 15
2.10.1. Action Interaction .................................... 15
2.10.2. Implicit Keep ......................................... 15
2.10.3. Message Uniqueness in a Mailbox ....................... 15
2.10.4. Limits on Numbers of Actions .......................... 16
2.10.5. Extensions and Optional Features ...................... 16
2.10.6. Errors ................................................ 17
2.10.7. Limits on Execution ................................... 17
3. Control Commands ....................................... 17
3.1. Control Structure If .................................. 18
3.2. Control Structure Require ............................. 19
3.3. Control Structure Stop ................................ 19
4. Action Commands ........................................ 19
4.1. Action reject ......................................... 20
4.2. Action fileinto ....................................... 20
4.3. Action redirect ....................................... 21
4.4. Action keep ........................................... 21
4.5. Action discard ........................................ 22
5. Test Commands .......................................... 22
5.1. Test address .......................................... 23
5.2. Test allof ............................................ 23
5.3. Test anyof ............................................ 24
5.4. Test envelope ......................................... 24
5.5. Test exists ........................................... 25
5.6. Test false ............................................ 25
5.7. Test header ........................................... 25
5.8. Test not .............................................. 26
5.9. Test size ............................................. 26
5.10. Test true ............................................. 26
6. Extensibility .......................................... 26
6.1. Capability String ..................................... 27
6.2. IANA Considerations ................................... 28
6.2.1. Template for Capability Registrations ................. 28
6.2.2. Initial Capability Registrations ...................... 28
6.3. Capability Transport .................................. 29
7. Transmission ........................................... 29
2.6. Arguments ............................................. 9
2.6.1. Positional Arguments .................................. 9
2.6.2. Tagged Arguments ...................................... 10
2.6.3. Optional Arguments .................................... 10
2.6.4. Types of Arguments .................................... 10
2.7. String Comparison ..................................... 11
2.7.1. Match Type ............................................ 11
2.7.2. Comparisons Across Character Sets ..................... 12
2.7.3. Comparators ........................................... 12
2.7.4. Comparisons Against Addresses ......................... 13
2.8. Blocks ................................................ 14
2.9. Commands .............................................. 14
2.10. Evaluation ............................................ 15
2.10.1. Action Interaction .................................... 15
2.10.2. Implicit Keep ......................................... 15
2.10.3. Message Uniqueness in a Mailbox ....................... 15
2.10.4. Limits on Numbers of Actions .......................... 16
2.10.5. Extensions and Optional Features ...................... 16
2.10.6. Errors ................................................ 17
2.10.7. Limits on Execution ................................... 17
3. Control Commands ....................................... 17
3.1. Control Structure If .................................. 18
3.2. Control Structure Require ............................. 19
3.3. Control Structure Stop ................................ 19
4. Action Commands ........................................ 19
4.1. Action reject ......................................... 20
4.2. Action fileinto ....................................... 20
4.3. Action redirect ....................................... 21
4.4. Action keep ........................................... 21
4.5. Action discard ........................................ 22
5. Test Commands .......................................... 22
5.1. Test address .......................................... 23
5.2. Test allof ............................................ 23
5.3. Test anyof ............................................ 24
5.4. Test envelope ......................................... 24
5.5. Test exists ........................................... 25
5.6. Test false ............................................ 25
5.7. Test header ........................................... 25
5.8. Test not .............................................. 26
5.9. Test size ............................................. 26
5.10. Test true ............................................. 26
6. Extensibility .......................................... 26
6.1. Capability String ..................................... 27
6.2. IANA Considerations ................................... 28
6.2.1. Template for Capability Registrations ................. 28
6.2.2. Initial Capability Registrations ...................... 28
6.3. Capability Transport .................................. 29
7. Transmission ........................................... 29
8. Parsing ................................................ 30
8.1. Lexical Tokens ........................................ 30
8.2. Grammar ............................................... 31
9. Extended Example ....................................... 32
10. Security Considerations ................................ 34
11. Acknowledgments ........................................ 34
12. Author's Address ....................................... 34
13. References ............................................. 34
14. Full Copyright Statement ............................... 36
8. Parsing ................................................ 30
8.1. Lexical Tokens ........................................ 30
8.2. Grammar ............................................... 31
9. Extended Example ....................................... 32
10. Security Considerations ................................ 34
11. Acknowledgments ........................................ 34
12. Author's Address ....................................... 34
13. References ............................................. 34
14. Full Copyright Statement ............................... 36
This memo documents a language that can be used to create filters for electronic mail. It is not tied to any particular operating system or mail architecture. It requires the use of [IMAIL]-compliant messages, but should otherwise generalize to many systems.
此备忘录记录了一种可用于创建电子邮件筛选器的语言。它与任何特定的操作系统或邮件体系结构无关。它需要使用与[IMAIL]兼容的消息，但应推广到许多系统。
The language is powerful enough to be useful but limited in order to allow for a safe server-side filtering system. The intention is to make it impossible for users to do anything more complex (and dangerous) than write simple mail filters, along with facilitating the use of GUIs for filter creation and manipulation. The language is not Turing-complete: it provides no way to write a loop or a function and variables are not provided.
该语言功能强大，非常有用，但为了实现安全的服务器端过滤系统，其功能有限。这样做的目的是让用户不可能做比编写简单邮件过滤器更复杂（和危险）的事情，同时方便使用GUI创建和操作过滤器。该语言不是图灵完整的：它没有提供编写循环或函数的方法，也没有提供变量。
Scripts written in Sieve are executed during final delivery, when the message is moved to the user-accessible mailbox. In systems where the MTA does final delivery, such as traditional Unix mail, it is reasonable to sort when the MTA deposits mail into the user's mailbox.
当邮件移动到用户可访问的邮箱时，在最终传递期间将执行在Sieve中编写的脚本。在MTA进行最终传递的系统中，如传统的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 e-mail, the emergence of unsolicited email as a form of advertising, and increased usage of mailing lists.
使用过滤系统的原因有很多。大多数用户的邮件流量一直在增加，这是由于电子邮件的使用量增加、主动电子邮件作为广告形式的出现以及邮件列表的使用量增加。
Experience at Carnegie Mellon has shown that if a filtering system is made available to users, many will make use of it in order to file messages from specific users or mailing lists. However, many others did not make use of the Andrew system's FLAMES filtering language [FLAMES] due to difficulty in setting it up.
卡内基梅隆大学的经验表明，如果向用户提供过滤系统，许多人会利用它来归档来自特定用户或邮件列表的邮件。然而，由于设置困难，许多其他人并没有使用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", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[关键词]中的定义进行解释。
Each section on a command (test, action, or control structure) has a line labeled "Syntax:". This line describes the syntax of the command, including its name and its arguments. Required arguments are listed inside angle brackets ("<" and ">"). Optional arguments are listed inside square brackets ("[" and "]"). Each argument is followed by its type, so "<key: string>" represents an argument called "key" that is a string. Literal strings are represented with double-quoted strings. Alternatives are separated with slashes, and parenthesis are used for grouping, similar to [ABNF].
命令（测试、操作或控制结构）的每个部分都有一行标记为“Syntax:”。此行描述命令的语法，包括其名称和参数。必需的参数列在尖括号（“<”和“>”）内。可选参数列在方括号（“[”和“]”）内。每个参数后面跟着它的类型，因此“<key:string>”表示一个名为“key”的参数，该参数是一个字符串。文字字符串用双引号字符串表示。备选方案用斜线分隔，括号用于分组，类似于[ABNF]。
In the "Syntax" line, there are three special pieces of syntax that are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, respectively.
在“Syntax”行中，有三种经常重复的特殊语法：匹配类型、比较器和地址部分。第2.7.1、2.7.3和2.7.4节分别讨论了这些问题。
The formal grammar for these commands in section 10 and is the authoritative reference on how to construct commands, but the formal grammar does not specify the order, semantics, number or types of arguments to commands, nor the legal command names. The intent is to allow for extension without changing the grammar.
第10节中的这些命令的形式语法是关于如何构造命令的权威参考，但形式语法没有指定命令的顺序、语义、参数数量或类型，也没有指定合法的命令名称。其目的是允许在不改变语法的情况下进行扩展。
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
-----------------------------------------------------------
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.edu
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.edu
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.
该语言由一组命令组成。每个命令都由一组由空格分隔的标记组成。命令标识符是第一个标记，后跟零个或多个参数标记。参数可以是文字数据、标记、命令块或测试命令。
The language is represented in UTF-8, as specified in [UTF-8].
按照[UTF-8]中的规定，该语言以UTF-8表示。
Tokens in the ASCII range are considered case-insensitive.
ASCII范围内的标记被视为不区分大小写。
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 and strings.
文字数据指未执行的数据，仅按“原样”计算，用作命令的参数。文字数据仅限于数字和字符串。
Numbers are given as ordinary decimal numbers. However, those numbers that have a tendency to be fairly large, such as message sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of a power of two. To be comparable with the power-of-two-based versions of SI units that computers frequently use, K specifies kibi-, or 1,024 (2^10) times the value of the number; M specifies mebi-, or 1,048,576 (2^20) times the value of the number; and G specifies tebi-, or 1,073,741,824 (2^30) times the value of the number [BINARY-SI].
数字以普通十进制数字的形式给出。然而，那些具有相当大的趋势的数字，例如消息大小，可以附加“K”、“M”或“G”，以指示二的幂的倍数。为了与计算机经常使用的两种基于国际单位制的版本的功率相比较，K指定kibi-，或1024（2^10）倍的数值；M指定mebi-，或1048576（2^20）乘以该数字的值；G指定tebi-，或1073741824（2^30）乘以数字[BINARY-SI]的值。
Implementations MUST provide 31 bits of magnitude in numbers, but MAY provide more.
实现必须提供31位数量级，但可能提供更多。
Only positive integers are permitted by this specification.
本规范只允许正整数。
Scripts involve large numbers of strings as they are used for pattern matching, addresses, textual bodies, etc. Typically, short quoted strings suffice for most uses, but a more convenient form is provided for longer strings such as bodies of messages.
脚本涉及大量字符串，因为它们用于模式匹配、地址、文本正文等。通常，短引号字符串足以用于大多数用途，但为较长的字符串（如消息正文）提供了更方便的形式。
A quoted string starts and ends with a single double quote (the <"> character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted string is followed by either another backslash or a double quote. This two-character sequence represents a single backslash or double-quote within the string, respectively.
带引号的字符串以单双引号（<>字符，ASCII 34）开始和结束。带引号的字符串中的反斜杠（\”，ASCII 92）后跟另一个反斜杠或双引号。这两个字符序列分别表示字符串中的单反斜杠或双引号。
No other characters should be escaped with a single backslash.
不应使用单个反斜杠转义其他字符。
An undefined escape sequence (such as "\a" in a context where "a" has no special meaning) is interpreted as if there were no backslash (in this case, "\a" is just "a").
未定义的转义序列（例如“a”没有特殊含义的上下文中的“\a”）被解释为没有反斜杠（在本例中，“\a”只是“a”）。
Non-printing characters such as tabs, CR and LF, and control characters are permitted in quoted strings. Quoted strings MAY span multiple lines. NUL (ASCII 0) is not allowed in strings.
带引号的字符串中允许使用非打印字符，如制表符、CR和LF以及控制字符。带引号的字符串可以跨越多行。字符串中不允许使用NUL（ASCII 0）。
For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. In order to allow the message to contain lines with a single-dot, lines are dot-stuffed. That is, when composing a message body, an extra `.' is added before each line which begins with a `.'. When the server interprets the script, these extra dots are removed. Note that a line that begins with a dot followed by a non-dot character is not interpreted dot-stuffed; that is, ".foo" is interpreted as ".foo". However, because this is potentially ambiguous, scripts SHOULD be properly dot-stuffed so such lines do not appear.
对于输入大量文本（如电子邮件），允许使用多行表单。它以关键字“text:”开头，后跟一个CRLF，以一个CRLF、一个句点和另一个CRLF的顺序结束。为了允许消息包含带有单点的行，行被点填充。也就是说，在编写消息正文时，在以“.”开头的每一行之前添加一个额外的“.”。当服务器解释脚本时，这些额外的点将被删除。请注意，以点开头，后跟非点字符的行不解释为点填充；也就是说，“.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. Implementations are encouraged to use short-circuit evaluation in these cases.
在匹配模式时，通常可以方便地对字符串组而不是单个字符串进行匹配。因此，许多测试中都允许使用字符串列表，这意味着如果使用任何一个字符串的测试为true，那么测试为true。在这些情况下，鼓励实施使用短路评估。
For instance, the test `header :contains ["To", "Cc"] ["me@example.com", "me00@landru.example.edu"]' is true if either the To header or Cc header of the input message contains either of the e-mail addresses "me@example.com" or "me00@landru.example.edu".
例如，test`header:包含[“To”，“Cc”][”me@example.com", "me00@landru.example.edu“]如果输入消息的“收件人”标头或“抄送”标头包含任一电子邮件地址，则为true”me@example.com“或”me00@landru.example.edu".
Conversely, in any case where a list of strings is appropriate, a single string is allowed without being a member of a list: it is equivalent to a list with a single member. This means that the test `exists "To"' is equivalent to the test `exists ["To"]'.
相反，在字符串列表适用的任何情况下，允许单个字符串而不是列表的成员：它相当于具有单个成员的列表。这意味着测试`exists“To”`等同于测试`exists[“To”]”。
Headers are a subset of strings. In the Internet Message Specification [IMAIL] [RFC1123], each header line is allowed to have whitespace nearly anywhere in the line, including after the field name and before the subsequent colon. Extra spaces between the header name and the ":" in a header field are ignored.
标题是字符串的子集。在Internet消息规范[IMAIL][RFC1123]中，允许每一行头中几乎任何地方都有空格，包括字段名之后和后续冒号之前。标题名称和标题字段中“：”之间的额外空格将被忽略。
A header name never contains a colon. The "From" header refers to a line beginning "From:" (or "From :", etc.). No header will match the string "From:" due to the trailing colon.
标题名称从不包含冒号。“From”标题是指以“From:”（或“From:”）开头的行。由于尾随冒号，没有标题与字符串“From:”匹配。
Folding of long header lines (as described in [IMAIL] 3.4.8) is removed prior to interpretation of the data. The folding syntax (the CRLF that ends a line plus any leading whitespace at the beginning of the next line that indicates folding) are interpreted as if they were a single space.
在解释数据之前，移除长标题行的折叠（如[IMAIL]3.4.8所述）。折叠语法（结束一行的CRLF加上下一行开始处指示折叠的任何前导空格）被解释为好像它们是单个空格一样。
A number of commands call for email addresses, which are also a subset of strings. When these addresses are used in outbound contexts, addresses must be compliant with [IMAIL], but are further constrained. Using the symbols defined in [IMAIL], section 6.1, the syntax of an address is:
许多命令调用电子邮件地址，电子邮件地址也是字符串的子集。在出站上下文中使用这些地址时，地址必须符合[IMAIL]，但会受到进一步的限制。使用[IMAIL]第6.1节中定义的符号，地址的语法为：
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 used here.
也就是说，不允许使用路由和组语法。如果需要多个地址，请使用字符串列表。此处不使用命名组。
Implementations MUST ensure that the addresses are syntactically valid, but need not ensure that they actually identify an email recipient.
实现必须确保地址在语法上是有效的，但不需要确保它们实际标识电子邮件收件人。
In a few places, [MIME] body parts are represented as strings. These parts include MIME headers and the body. This provides a way of embedding typed data within a Sieve script so that, among other things, character sets other than UTF-8 can be used for output messages.
在一些地方，[MIME]主体部分表示为字符串。这些部分包括MIME头和正文。这提供了一种在筛选脚本中嵌入类型化数据的方法，以便除其他外，UTF-8以外的字符集可用于输出消息。
Tests are given as arguments to commands in order to control their actions. In this document, tests are given to if/elsif/else to decide which block of code is run.
测试作为命令的参数提供，以控制其操作。在本文档中，将对if/elsif/else进行测试，以确定运行哪个代码块。
Tests MUST NOT have side effects. That is, a test cannot affect the state of the filter or message. No tests in this specification have side effects, and side effects are forbidden in extension tests as well.
测试不得有副作用。也就是说，测试不能影响筛选器或消息的状态。本规范中的试验没有副作用，延伸试验中也禁止副作用。
The rationale for this is that tests with side effects impair readability and maintainability and are difficult to represent in a graphic interface for generating scripts. Side effects are confined to actions where they are clearer.
其基本原理是，具有副作用的测试会损害可读性和可维护性，并且难以在生成脚本的图形界面中表示。副作用仅限于更明确的行动。
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.
一些测试（“allof”和“anyof”，分别实现逻辑“and”和逻辑“or”）可能需要不止一个测试作为参数。testlist语法元素提供了一种对测试进行分组的方法。
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.edu") {
discard;
}
Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.edu") {
discard;
}
In order to specify what to do, most commands take arguments. There are three types of arguments: positional, tagged, and optional.
为了指定要执行的操作，大多数命令都使用参数。有三种类型的参数：位置参数、标记参数和可选参数。
Positional arguments are given to a command which discerns their meaning based on their order. When a command takes positional arguments, all positional arguments must be supplied and must be in the order prescribed.
位置参数被赋予一个命令，该命令根据它们的顺序识别它们的含义。当命令采用位置参数时，必须提供所有位置参数，并且必须按照规定的顺序。
This document provides for tagged arguments in the style of CommonLISP. These are also similar to flags given to commands in most command-line systems.
本文档提供了CommonLISP样式的标记参数。这些也类似于大多数命令行系统中为命令指定的标志。
A tagged argument is an argument for a command that begins with ":" followed by a tag naming the argument, such as ":contains". This argument means that zero or more of the next tokens have some particular meaning depending on the argument. These next tokens may be numbers or strings but they are never blocks.
标记参数是以“：”开头的命令的参数，后跟命名参数的标记，如“：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.
标记的参数必须出现在位置参数之前，但它们可以与其他标记的参数以任意顺序出现。为了简化规范，这在命令的语法定义中没有表示，但是如果它们出现在位置参数之前，它们仍然可以被任意重新排序。带标记的参数可能与可选参数混合。
To simplify this specification, 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 [ACAP] comparator will be used to compare two strings, since different languages may impose different orderings on UTF-8 [UTF-8] characters.
一个特别值得注意的情况是“：comparator”参数，它允许用户指定将使用哪个[ACAP]比较器来比较两个字符串，因为不同的语言可能会对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 9.2 presents a parsable version of this: Arguments are string-lists, numbers, and tags, which may be followed
然而，从解析的角度来看，这种抽象是不明确的。第9.2节中的语法提供了一个可解析的版本：参数是字符串列表、数字和标记，可以遵循这些参数
by a test or a test-list, which may be followed by a block of commands. No more than one test or test list, nor more than one block of commands, may be used, and commands that end with blocks of commands do not end with semicolons.
通过一个测试或一个测试列表，该列表后面可能有一个命令块。不能使用多个测试或测试列表，也不能使用多个命令块，以命令块结尾的命令不能以分号结尾。
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 borrows ACAP's comparator registry.
为了提供字符集和大小写不敏感之间的匹配，Sieve借用了ACAP的comparator注册表。
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]中定义事物的方式。
There are three match types describing the matching used in this specification: ":is", ":contains", and ":matches". Match type arguments are supplied to those commands which allow them to specify what kind of match is to be performed.
有三种匹配类型描述本规范中使用的匹配：“：is”、“：contains”和“：matches”。匹配类型参数提供给那些允许它们指定要执行的匹配类型的命令。
These are used as tagged arguments to tests that perform string comparison.
这些参数用作执行字符串比较的测试的标记参数。
The ":contains" match type describes a substring match. If the value argument contains the key argument as a substring, the match is true. For instance, the string "frobnitzm" contains "frob" and "nit", but not "fbm". The null key ("") is contained in all values.
“：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 null key ":is" and only ":is" the null value.
“：is”匹配类型描述绝对匹配；如果第一个字符串的内容与第二个字符串的内容完全相同，则它们匹配。只有字符串“frobnitzm”是字符串“frobnitzm”。空键“：为”且仅“：为”空值。
The ":matches" version specifies a wildcard match using the characters "*" and "?". "*" matches zero or more characters, and "?" matches a single character. "?" and "*" may be escaped as "\\?" and "\\*" in strings to match against themselves. The first backslash escapes the second backslash; together, they escape the "*". This is awkward, but it is commonplace in several programming languages that use globs and regular expressions.
“：matches”版本使用字符“*”和“？”指定通配符匹配。“*”匹配零个或多个字符，“？”匹配单个字符。“？”和“*”可以在字符串中转义为“\\？”和“\\*”，以匹配它们自己。第一个反斜杠跳过第二个反斜杠；他们一起逃过了“*”这个词。这很尴尬，但在使用globs和正则表达式的几种编程语言中，这是很常见的。
In order to specify what type of match is supposed to happen, commands that support matching take optional tagged arguments ":matches", ":is", and ":contains". Commands default to using ":is" matching if no match type argument is supplied. Note that these modifiers may interact with comparators; in particular, some comparators are not suitable for matching with ":contains" or ":matches". It is an error to use a comparator with ":contains" or ":matches" that is not compatible with it.
为了指定应该发生哪种类型的匹配，支持匹配的命令采用可选的标记参数“：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"
All Sieve scripts are represented in UTF-8, but messages may involve a number of character sets. In order for comparisons to work across character sets, implementations SHOULD implement the following behavior:
所有筛选脚本都用UTF-8表示，但消息可能涉及许多字符集。为了跨字符集进行比较，实现应实现以下行为：
Implementations decode header charsets to UTF-8. Two strings are considered equal if their UTF-8 representations are identical. Implementations should decode charsets represented in the forms specified by [MIME] for both message headers and bodies. Implementations must be capable of decoding US-ASCII, ISO-8859-1, the ASCII subset of ISO-8859-* character sets, and UTF-8.
实现将头字符集解码为UTF-8。如果两个字符串的UTF-8表示形式相同，则认为它们相等。对于消息头和消息体，实现应该解码以[MIME]指定的形式表示的字符集。实现必须能够解码US-ASCII、ISO-8859-1、ISO-8859-*字符集的ASCII子集和UTF-8。
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. Comparators are described for [ACAP]; a registry is defined for ACAP, and this specification uses that registry.
为了允许语言无关、大小写无关的匹配，匹配类型可以与比较器名称耦合。比较器描述为[ACAP]；为ACAP定义了一个注册表，本规范使用该注册表。
ACAP defines multiple comparator types. Only equality types are used in this specification.
ACAP定义了多种比较器类型。本规范中仅使用相等类型。
All implementations MUST support the "i;octet" comparator (simply compares octets) and the "i;ascii-casemap" comparator (which treats uppercase and lowercase characters in the ASCII subset of UTF-8 as the same). If left unspecified, the default is "i;ascii-casemap".
所有实现都必须支持“i；八位字节”比较器（仅比较八位字节）和“i；ascii casemap”比较器（将UTF-8的ascii子集中的大写和小写字符视为相同）。如果未指定，默认值为“i；ascii casemap”。
Some comparators may not be usable with substring matches; that is, they may only work with ":is". It is an error to try and use a comparator with ":matches" or ":contains" that is not compatible with it.
某些比较器可能无法用于子字符串匹配；也就是说，它们只能与“：is”一起工作。尝试使用与之不兼容的“：matches”或“：contains”比较器是错误的。
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 2.10.5.)
除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”，它们作用于本地部分（左侧）、域部分（右侧）和整个地址。
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. Blocks are supplied to commands so that the commands can implement control commands.
块是用大括号括起来的命令集。块提供给命令，以便命令可以实现控制命令。
A control structure is a command that happens to take a test and a block as one of its arguments; depending on the result of the test supplied as another argument, it runs the code in the block some number of times.
控制结构是一个命令，它碰巧将测试和块作为其参数之一；根据作为另一个参数提供的测试结果，它会在块中运行代码若干次。
With the commands supplied in this memo, there are no loops. The control structures supplied--if, elsif, and else--run a block either once or not at all. So there are two arguments, the test and the block.
对于本备忘录中提供的命令，没有循环。提供的控制结构（if、elsif和else）可以运行一次块，也可以不运行。所以有两个参数，test和block。
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.
最简单的是动作命令。操作命令是一个标识符，后跟零个或多个参数，以分号结尾。操作命令不将测试或块作为参数。
A control command is similar, but it takes a test as an argument, and ends with a block instead of a semicolon.
控制命令与此类似，但它将测试作为参数，并以块而不是分号结束。
A test command is used as part of a control command. It is used to specify whether or not the block of code given to the control command is executed.
测试命令用作控制命令的一部分。它用于指定是否执行给定给控制命令的代码块。
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 4.4) performed in absence of any action that cancels the implicit keep.
隐式保留是在没有任何取消隐式保留的操作的情况下执行的保留操作（见4.4）。
An implicit keep is performed if a message is not written to a mailbox, redirected to a new address, or explicitly thrown out. That is, if a fileinto, a keep, a redirect, or a discard is performed, an implicit keep is not.
如果邮件未写入邮箱、重定向到新地址或显式抛出，则执行隐式保留。也就是说，如果执行fileinto、保留、重定向或放弃，则不会执行隐式保留。
Some actions may be defined to not cancel the implicit keep. These actions may not directly affect the delivery of a message, and are used for their side effects. None of the actions specified in this document meet that criteria, but extension actions will.
某些操作可能被定义为不取消隐式保留。这些操作可能不会直接影响邮件的传递，而是用于产生副作用。本文档中指定的任何操作都不符合该标准，但扩展操作将满足该标准。
For instance, with any of the short messages offered above, the following script produces no actions.
例如，对于上面提供的任何短消息，下面的脚本都不会生成任何操作。
Example: if size :over 500K { discard; }
Example: if size :over 500K { discard; }
As a result, the implicit keep is taken.
因此，采用隐式keep。
Implementations SHOULD NOT deliver a message to the same folder more than once, even if a script explicitly asks for a message to be written to a mailbox twice.
即使脚本明确要求将消息写入邮箱两次，实现也不应将消息多次传递到同一文件夹。
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 numbers of actions taken and MAY impose restrictions on which actions can be used together. In the event that a script hits a policy limit on the number of actions taken for a particular message, an error occurs.
站点策略可能会限制所采取的操作的数量，并且可能会限制哪些操作可以一起使用。如果脚本对特定消息执行的操作数达到策略限制，则会发生错误。
Implementations MUST prohibit more than one reject.
实现必须禁止多个拒绝。
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，则实现必须至少允许一次保留。
Implementations SHOULD prohibit reject when used with other actions.
当与其他操作一起使用时，实现应禁止拒绝。
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.
如果扩展未启用“require”，则实现必须将其视为根本不支持扩展。
If a script does not understand an extension declared with require, the script must not be used at all. Implementations MUST NOT execute scripts which require unknown capability names.
如果脚本不理解使用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等语言的经验表明，这是一种注意给定脚本使用扩展的可行方法。
Experience with PostScript suggests that mechanisms that allow a script to work around missing extensions are not used in practice.
PostScript的经验表明，允许脚本处理缺少的扩展的机制在实践中并未使用。
Extensions which 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 might even go so far as to ensure that scripts can never execute an invalid set of actions (e.g., reject + fileinto) before execution, although this could involve solving the Halting Problem.
实现甚至可以确保脚本在执行之前永远不会执行一组无效的操作（例如，reject+fileinto），尽管这可能涉及解决暂停问题。
This specification allows any of these approaches. Solving the Halting Problem is considered extra credit.
本规范允许这些方法中的任何一种。解决停车问题被认为是额外的学分。
When an error happens, implementations MUST notify the user that an error occurred, 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 MUST only follow an if, and an else MUST follow only either an if or an elsif. An error occurs if these conditions are not met.
if有三个部分：“if”、“elsif”和“else”。就语法而言，每个命令实际上是一个单独的命令。但是，elsif只能跟在if后面，else只能跟在if或elsif后面。如果不满足这些条件，则会发生错误。
Syntax: if <test1: test> <block1: block>
Syntax: if <test1: test> <block1: block>
Syntax: elsif <test2: test> <block2: block>
Syntax: elsif <test2: test> <block2: block>
Syntax: else <block>
Syntax: else <block>
The semantics are similar to those of any of the many other programming languages these control commands appear in. When the interpreter sees an "if", it evaluates the test associated with it. If the test is true, it executes the block associated with it.
语义与这些控制命令出现在的许多其他编程语言的语义相似。当解释器看到一个“if”时，它会评估与之关联的测试。如果测试为真，它将执行与其关联的块。
If the test of the "if" is false, it evaluates the test of the first "elsif" (if any). If the test of "elsif" is true, it runs the elsif's block. An elsif may be followed by an elsif, in which case, the interpreter repeats this process until it runs out of elsifs.
如果“如果”测试为假，则评估第一个“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 case.
当解释器用完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 Message 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.edu; message B, to postmaster@example.edu; any other message is redirected to field@example.edu.
当下面的脚本在消息A上运行时，它会将消息重定向到acm@example.edu; 信息B，发送至postmaster@example.edu; 任何其他消息都会重定向到field@example.edu.
Example: if header :contains ["From"] ["coyote"] {
redirect "acm@example.edu";
} elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.edu";
} else {
redirect "field@example.edu";
}
Example: if header :contains ["From"] ["coyote"] {
redirect "acm@example.edu";
} elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.edu";
} else {
redirect "field@example.edu";
}
Note that this definition prohibits the "... else if ..." sequence used by C. This is intentional, because this construct produces a shift-reduce conflict.
请注意，此定义禁止C使用“…else if…”序列。这是故意的，因为此构造会产生移位-减少冲突。
Syntax: require <capabilities: string-list>
Syntax: require <capabilities: string-list>
The require action notes that a script makes use of a certain extension. Such a declaration is required to use the extension, as discussed in section 2.10.5. Multiple capabilities can be declared with a single require.
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";
Syntax: stop
语法：停止
The "stop" action ends all processing. If no actions have been executed, then the keep action is taken.
“停止”操作结束所有处理。如果没有执行任何操作，则执行keep操作。
This document supplies five actions that may be taken on a message: keep, fileinto, redirect, reject, and discard.
本文档提供了可以对消息执行的五个操作：保留、文件导入、重定向、拒绝和放弃。
Implementations MUST support the "keep", "discard", and "redirect" actions.
实现必须支持“保留”、“放弃”和“重定向”操作。
Implementations SHOULD support "reject" and "fileinto".
实现应该支持“拒绝”和“文件导入”。
Implementations MAY limit the number of certain actions taken (see section 2.10.4).
实施可能会限制采取的某些行动的数量（见第2.10.4节）。
Syntax: reject <reason: string>
Syntax: reject <reason: string>
The optional "reject" action refuses delivery of a message by sending back an [MDN] to the sender. It resends the message to the sender, wrapping it in a "reject" form, noting that it was rejected by the recipient. In the following script, message A is rejected and returned to the sender.
可选的“拒绝”操作通过向发件人发回[MDN]来拒绝邮件的传递。它将消息重新发送给发送者，将其包装成“拒绝”形式，并指出它已被接收者拒绝。在下面的脚本中，消息A被拒绝并返回给发件人。
Example: if header :contains "from" "coyote@desert.example.org" {
reject "I am not taking mail from you, and I don't want
your birdseed, either!";
}
Example: if header :contains "from" "coyote@desert.example.org" {
reject "I am not taking mail from you, and I don't want
your birdseed, either!";
}
A reject message MUST take the form of a failure MDN as specified by [MDN]. The human-readable portion of the message, the first component of the MDN, contains the human readable message describing the error, and it SHOULD contain additional text alerting the original sender that mail was refused by a filter. This part of the MDN might appear as follows:
拒绝消息必须采用[MDN]指定的故障MDN形式。消息的人类可读部分（MDN的第一个组件）包含描述错误的人类可读消息，并且应该包含额外的文本，提醒原始发件人邮件已被筛选器拒绝。MDN的这一部分可能如下所示：
------------------------------------------------------------
Message was refused by recipient's mail filtering program. Reason
given was as follows:
------------------------------------------------------------
Message was refused by recipient's mail filtering program. Reason
given was as follows:
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
The MDN action-value field as defined in the MDN specification MUST be "deleted" and MUST have the MDN-sent-automatically and automatic-action modes set.
MDN规范中定义的MDN操作值字段必须“删除”，并且必须自动发送MDN并设置自动操作模式。
Because some implementations can not or will not implement the reject command, it is optional. The capability string to be used with the require command is "reject".
由于某些实现不能或不会实现reject命令，因此它是可选的。与require命令一起使用的能力字符串是“拒绝”。
Syntax: fileinto <folder: string>
Syntax: fileinto <folder: string>
The "fileinto" action delivers the message into the specified folder. Implementations SHOULD support fileinto, but in some environments this may be impossible.
“fileinto”操作将消息传递到指定的文件夹中。实现应该支持fileinto，但在某些环境中这可能是不可能的。
The capability string for use with the require command is "fileinto".
与require命令一起使用的功能字符串是“fileinto”。
In the following script, message A is filed into folder "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";
}
Syntax: redirect <address: string>
Syntax: redirect <address: string>
The "redirect" action is used to send the message to another user at a supplied address, as a mail forwarding feature does. The "redirect" action makes no changes to the message body or existing headers, but it may add new headers. The "redirect" modifies the envelope recipient.
“重定向”操作用于按照提供的地址将消息发送给另一个用户，就像邮件转发功能一样。“重定向”操作不会更改消息体或现有头，但可能会添加新头。“重定向”修改信封收件人。
The redirect command performs an MTA-style "forward"--that is, what you get from a .forward file using sendmail under UNIX. The address on the SMTP envelope is replaced with the one on the redirect command and the message is sent back out. (This is not an MUA-style forward, which creates a new message with a different sender and message ID, wrapping the old message in a new one.)
redirect命令执行MTA样式的“转发”——即在UNIX下使用sendmail从.forward文件获得的内容。SMTP信封上的地址将替换为重定向命令上的地址，并将邮件发回。（这不是MUA样式的转发，它使用不同的发件人和邮件ID创建新邮件，将旧邮件包装到新邮件中。）
A simple script can be used for redirecting all mail:
可以使用一个简单的脚本重定向所有邮件：
Example: redirect "bart@example.edu";
Example: redirect "bart@example.edu";
Implementations SHOULD take measures to implement loop control, possibly including adding headers to the message or counting received headers. If an implementation detects a loop, it causes an error.
实现应该采取措施来实现循环控制，可能包括向消息添加头或计算收到的头。如果实现检测到循环，则会导致错误。
Syntax: keep
语法：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; }
Syntax: discard
语法：放弃
Discard is used to silently throw away the message. It does so by simply canceling the implicit keep. If discard is used with other actions, the other actions still happen. Discard is compatible with all other actions. (For instance fileinto+discard is equivalent to fileinto.)
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.edu" is thrown out.
在以下脚本中，来自“”的任何邮件idiot@example.edu“被扔掉了。
Example: if header :contains ["from"] ["idiot@example.edu"] {
discard;
}
Example: if header :contains ["from"] ["idiot@example.edu"] {
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.
实现应该支持“信封”测试。
Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list>
Syntax: address [ADDRESS-PART] [COMPARATOR] [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.
地址测试匹配包含地址的结构化头中的Internet地址。如果任何标头在地址的指定部分包含任何键（由比较器和匹配关键字修改），则返回true。
Like envelope and header, this test returns true if any combination of the header-list and key-list arguments match.
和信封和标头一样，若标头列表和键列表参数的任何组合匹配，该测试将返回true。
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, nor 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, Resent-To, and 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;
Syntax: allof <tests: test-list>
Syntax: 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测试将测试列表作为其参数。
Syntax: anyof <tests: test-list>
Syntax: 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
Syntax: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
Syntax: 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.
如果SMTP（或等效）信封的指定部分与指定密钥匹配，“信封”测试为真。
If one of the envelope-part strings is (case insensitive) "from", then matching occurs against the FROM address used in the SMTP MAIL command.
如果其中一个信封部分字符串为（不区分大小写）“发件人”，则会与SMTP邮件命令中使用的发件人地址进行匹配。
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 and key-list arguments is true.
和address和header一样，如果信封部分和键列表参数的任何组合为true，则此测试返回true。
All tests against envelopes MUST drop source routes.
所有针对封套的测试都必须删除源路由。
If the SMTP transaction involved several RCPT commands, only the data from the RCPT command that caused delivery to this user is available in the "to" part of the envelope.
如果SMTP事务涉及多个RCPT命令，则信封的“收件人”部分中只有来自RCPT命令的数据可用于发送给该用户。
If a protocol other than SMTP is used for message transport, implementations are expected to adapt this command appropriately.
如果将SMTP以外的协议用于消息传输，则实现应适当地调整此命令。
The envelope command is optional. Implementations SHOULD support it, but the necessary information may not be available in all cases.
信封命令是可选的。实现应该支持它，但并非所有情况下都可以获得必要的信息。
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
Example: require "envelope";
if envelope :all :is "from" "tim@example.com" {
discard;
}
Syntax: exists <header-names: string-list>
Syntax: exists <header-names: string-list>
The "exists" test is true if the headers listed in the header-names argument exist within the message. All of the headers must exist or the test is false.
如果消息中存在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;
}
Syntax: false
语法：false
The "false" test always evaluates to false.
“false”测试的计算结果始终为false。
Syntax: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
Syntax: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list>
The "header" test evaluates to true if any header name matches any key. The type of match is specified by the optional match argument, which defaults to ":is" if not specified, as specified in section 2.6.
如果任何头名称与任何键匹配，“头”测试的结果为true。匹配类型由可选匹配参数指定，如第2.6节所述，如果未指定，则默认为“：is”。
Like address and envelope, this test returns true if any combination of the string-list and key-list arguments match.
和地址和信封一样，若字符串列表和键列表参数的任何组合匹配，该测试将返回true。
If a header listed in the header-names argument exists, it contains the null key (""). However, if the named header is not present, it does not contain the null key. So if a message contained the header
如果header names参数中列出的头存在，则它包含空键（“”）。但是，如果命名标头不存在，则它不包含null键。因此，如果消息包含头
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
Syntax: not <test>
Syntax: not <test>
The "not" test takes some other test as an argument, and yields the opposite result. "not false" evaluates to "true" and "not true" evaluates to "false".
“not”测试将其他测试作为参数，并产生相反的结果。“not false”计算为“true”，而“not true”计算为“false”。
Syntax: size <":over" / ":under"> <limit: number>
Syntax: size <":over" / ":under"> <limit: number>
The "size" test deals with the size of a message. It takes either a tagged argument of ":over" or ":under", followed by a number representing the size of the message.
“大小”测试处理消息的大小。它接受带标记的参数“：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 from the initial header until the last character in the message body.
消息的大小定义为从初始头到消息体中最后一个字符的八位字节数。
Note that for a message that is exactly 4,000 octets, the message is neither ":over" 4000 octets or ":under" 4000 octets.
请注意，对于正好为4000个八位字节的消息，该消息既不是“：超过”4000个八位字节，也不是“：低于”4000个八位字节。
Syntax: true
语法：true
The "true" test always evaluates to true.
“true”测试的计算结果始终为true。
New control structures, actions, and tests can be added to the language. Sites must make these features known to their users; this document does not define a way to discover the list of extensions supported by the server.
可以向语言中添加新的控制结构、操作和测试。网站必须让用户了解这些功能；本文档未定义查找服务器支持的扩展列表的方法。
Any extensions to this language MUST define a capability string that uniquely identifies that extension. If a new version of an extension changes the functionality of a previously defined extension, it MUST use a different name.
此语言的任何扩展必须定义唯一标识该扩展的功能字符串。如果扩展的新版本更改了先前定义的扩展的功能，则它必须使用不同的名称。
In a situation where there is a submission protocol and an extension advertisement mechanism aware of the details of this language, scripts submitted can be checked against the mail server to prevent use of an extension that the server does not support.
在存在提交协议和扩展公告机制的情况下，可以根据邮件服务器检查提交的脚本，以防止使用服务器不支持的扩展。
Extensions MUST state how they interact with constraints defined in section 2.10, e.g., whether they cancel the implicit keep, and which actions they are compatible and incompatible with.
扩展必须说明它们如何与第2.10节中定义的约束交互，例如，它们是否取消隐式保留，以及它们与哪些操作兼容和不兼容。
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:
本文档定义了以下功能字符串：
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”命令。
reject The string "reject" indicates that the implementation supports the "reject" command.
reject字符串“reject”表示实现支持“reject”命令。
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 provided by IANA. Capability names may be registered on a first-come, first-served basis. Extensions designed for interoperable use SHOULD be defined as standards track or IESG approved experimental RFCs.
为了提供一组标准的扩展，IANA提供了一个注册表。能力名称可以先到先得的方式注册。为互操作使用而设计的扩展应定义为标准跟踪或IESG批准的实验RFC。
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: Capability keyword: Capability arguments: Standards Track/IESG-approved experimental RFC number: Person and email address to contact for further information:
能力名称：能力关键字：能力参数：标准跟踪/IESG批准的实验RFC编号：联系人和电子邮件地址以获取更多信息：
The following are to be added to the IANA registry for Sieve extensions as the initial contents of the capability registry.
以下内容将作为能力注册表的初始内容添加到IANA注册表中，用于筛选扩展。
Capability name: fileinto
Capability keyword: fileinto
Capability arguments: fileinto <folder: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: fileinto
Capability keyword: fileinto
Capability arguments: fileinto <folder: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: reject
Capability keyword: reject
Capability arguments: reject <reason: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: reject
Capability keyword: reject
Capability arguments: reject <reason: string>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: envelope
Capability keyword: envelope
Capability arguments:
envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: envelope
Capability keyword: envelope
Capability arguments:
envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list>
Standards Track/IESG-approved experimental RFC number:
RFC 3028 (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: comparator-* Capability keyword: comparator-* (anything starting with "comparator-") Capability arguments: (none) Standards Track/IESG-approved experimental RFC number: RFC 3028, Sieve, by reference of RFC 2244, Application Configuration Access Protocol Person and email address to contact for further information: Tim Showalter tjs@mirapoint.com
能力名称：comparator-*能力关键字：comparator-*（以“comparator-”开头的任何内容）能力参数：（无）标准跟踪/IESG批准的实验RFC编号：RFC 3028，筛，参考RFC 2244，应用程序配置访问协议联系人和电子邮件地址，以获取更多信息：Tim Showaltertjs@mirapoint.com
As the range of mail systems that this document is intended to apply to is quite varied, a method of advertising which capabilities an implementation supports is difficult due to the wide range of possible implementations. Such a mechanism, however, should have property that the implementation can advertise the complete set of extensions that it supports.
由于本文档拟应用于的邮件系统的范围非常广泛，由于可能实现的范围很广，因此很难实现支持哪种功能的广告方法。然而，这样的机制应该具有这样的属性：实现可以公布它所支持的完整扩展集。
The MIME type for a Sieve script is "application/sieve".
Sieve脚本的MIME类型是“application/Sieve”。
The registration of this type for RFC 2048 requirements is 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.
MIME媒体类型名称：应用程序MIME子类型名称：筛选必需参数：无可选参数：无编码注意事项：大多数筛选脚本都是文本的，用UTF-8编写。使用非7bit字符时，带引号的可打印字符适用于需要7bit编码的传输系统。
Security considerations: Discussed in section 10 of RFC 3028. Interoperability considerations: Discussed in section 2.10.5 of RFC 3028. Published specification: RFC 3028. Applications which use this media type: sieve-enabled mail servers Additional information: Magic number(s): File extension(s): .siv Macintosh File Type Code(s): Person & email address to contact for further information: See the discussion list at ietf-mta-filters@imc.org. Intended usage: COMMON Author/Change controller: See Author information in RFC 3028.
安全注意事项：在RFC 3028第10节中讨论。互操作性注意事项：在RFC 3028第2.10.5节中讨论。已发布规范：RFC 3028。使用此媒体类型的应用程序：启用筛选的邮件服务器其他信息：幻数：文件扩展名：.siv Macintosh文件类型代码：联系人和电子邮件地址了解更多信息：请参阅ietf mta上的讨论列表-filters@imc.org. 预期用途：通用作者/变更控制器：参见RFC 3028中的作者信息。
The Sieve grammar is separated into tokens and a separate grammar as most programming languages are.
与大多数编程语言一样，筛语法被分为标记和单独的语法。
Sieve scripts are encoded in UTF-8. The following assumes a valid UTF-8 encoding; special characters in Sieve scripts are all ASCII.
筛选脚本以UTF-8编码。以下假设为有效的UTF-8编码；筛脚本中的特殊字符都是ASCII。
The following are tokens in Sieve:
以下是Sieve中的令牌：
- identifiers - tags - numbers - quoted strings - multi-line strings - other separators
- 标识符-标签-数字-带引号的字符串-多行字符串-其他分隔符
Blanks, horizontal tabs, CRLFs, and comments ("white space") are ignored except as they separate tokens. Some white space is required to separate otherwise adjacent tokens and in specific places in the multi-line strings.
空白、水平制表符、CRLF和注释（“空白”）将被忽略，除非它们分隔标记。需要一些空白来分隔多行字符串中其他相邻的标记和特定位置。
The other separators are single individual characters, and are mentioned explicitly in the grammar.
其他分隔符是单个字符，并在语法中明确提到。
The lexical structure of sieve is defined in the following BNF (as described in [ABNF]):
sieve的词汇结构在以下BNF中定义（如[ABNF]中所述）：
bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
;; No */ allowed inside a comment.
;; (No * is allowed unless it is the last character,
;; or unless it is followed by a character that isn't a
;; slash.)
bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
;; No */ allowed inside a comment.
;; (No * is allowed unless it is the last character,
;; or unless it is followed by a character that isn't a
;; slash.)
CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
;; no dots, no CRLFs
CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
;; no dots, no CRLFs
CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)
CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
CHAR-NOT-SLASH = (%x00-57 / %x58-ff)
CHAR-NOT-STAR = (%x00-51 / %x53-ff)
CHAR-NOT-STAR = (%x00-51 / %x53-ff)
comment = bracket-comment / hash-comment
comment = bracket-comment / hash-comment
hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
hash-comment = ( "#" *CHAR-NOT-CRLF CRLF )
identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
identifier = (ALPHA / "_") *(ALPHA DIGIT "_")
tag = ":" identifier
tag=“：”标识符
number = 1*DIGIT [QUANTIFIER]
number = 1*DIGIT [QUANTIFIER]
QUANTIFIER = "K" / "M" / "G"
QUANTIFIER = "K" / "M" / "G"
quoted-string = DQUOTE *CHAR DQUOTE
;; in general, \ CHAR inside a string maps to CHAR
;; so \" maps to " and \\ maps to \
;; note that newlines and other characters are all allowed
;; strings
quoted-string = DQUOTE *CHAR DQUOTE
;; in general, \ CHAR inside a string maps to CHAR
;; so \" maps to " and \\ maps to \
;; note that newlines and other characters are all allowed
;; strings
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multi-line-literal / multi-line-dotstuff)
"." CRLF
multi-line-literal = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
;; A line containing only "." ends the multi-line.
;; Remove a leading '.' if followed by another '.'.
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multi-line-literal / multi-line-dotstuff)
"." CRLF
multi-line-literal = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF
multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF
;; A line containing only "." ends the multi-line.
;; Remove a leading '.' if followed by another '.'.
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 white space 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) ")"
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", "reject"];
##示例筛选过滤器#声明脚本使用的任何可选功能或扩展#要求[“fileinto”，“reject”]；
#
# Reject any large messages (note that the four leading dots get
# "stuffed" to three)
#
if size :over 1M
{
reject text:
Please do not send me large attachments.
Put your file on a server and send me the URL.
Thank you.
.... Fred
.
;
stop;
}
#
#
# Reject any large messages (note that the four leading dots get
# "stuffed" to three)
#
if size :over 1M
{
reject text:
Please do not send me large attachments.
Put your file on a server and send me the URL.
Thank you.
.... Fred
.
;
stop;
}
#
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
fileinto "filter"; # move to "filter" folder
}
#
# Keep all messages to or from people in my company
#
elsif address :domain :is ["From", "To"] "example.com"
{
keep; # keep in "In" folder
}
# Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder
#
if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{
fileinto "filter"; # move to "filter" folder
}
#
# Keep all messages to or from people in my company
#
elsif address :domain :is ["From", "To"] "example.com"
{
keep; # keep in "In" folder
}
#
# Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away.
#
elsif anyof (not address :all :contains
["To", "Cc", "Bcc"] "me@example.com",
header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"])
{
# If message header does not contain my address,
# it's from a list.
fileinto "spam"; # move to "spam" folder
}
else
{
# Move all other (non-company) mail to "personal"
# folder.
fileinto "personal";
}
#
# Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away.
#
elsif anyof (not address :all :contains
["To", "Cc", "Bcc"] "me@example.com",
header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"])
{
# If message header does not contain my address,
# it's from a list.
fileinto "spam"; # move to "spam" folder
}
else
{
# Move all other (non-company) mail to "personal"
# folder.
fileinto "personal";
}
Users must get their mail. It is imperative that whatever method implementations use to store the user-defined filtering scripts be secure.
用户必须收到他们的邮件。无论实现使用什么方法来存储用户定义的过滤脚本，都必须是安全的。
It is equally important that implementations sanity-check the user's scripts, and not allow users to create on-demand mailbombs. For instance, an implementation that allows a user to reject or redirect multiple times to a single message might also allow a user to create a mailbomb triggered by mail from a specific user. Site- or implementation-defined limits on actions are useful for this.
同样重要的是，实现的健全性检查用户的脚本，不允许用户创建按需邮件炸弹。例如，允许用户多次拒绝或重定向到单个消息的实现可能还允许用户创建由特定用户的邮件触发的邮件炸弹。站点或实现定义的操作限制对此很有用。
Several commands, such as "discard", "redirect", and "fileinto" allow for actions to be taken that are potentially very dangerous.
一些命令，如“discard”、“redirect”和“fileinto”，允许采取可能非常危险的操作。
Implementations SHOULD take measures to prevent languages from looping.
实现应该采取措施防止语言循环。
I am very thankful to Chris Newman for his support and his ABNF syntax checker, to John Myers and Steve Hole for outlining the requirements for the original drafts, to Larry Greenfield for nagging me about the grammar and finally fixing it, to Greg Sereda for repeatedly fixing and providing examples, to Ned Freed for fixing everything else, to Rob Earhart for an early implementation and a great deal of help, and to Randall Gellens for endless amounts of proofreading. I am grateful to Carnegie Mellon University where most of the work on this document was done. I am also indebted to all of the readers of the ietf-mta-filters@imc.org mailing list.
我非常感谢Chris Newman的支持和他的ABNF语法检查器，感谢John Myers和Steve Hole概述了原始草案的要求，感谢Larry Greenfield就语法问题向我唠叨并最终修正了语法，感谢Greg Sereda反复修正并提供示例，感谢Ned Freed修正了所有其他问题，为了Rob Earhart的早期实施和大量帮助，为了Randall Gellens的无休止的校对。我很感谢卡内基梅隆大学，在那里完成了这份文件的大部分工作。我还要感谢ietf mta的所有读者-filters@imc.org邮件列表。
Tim Showalter Mirapoint, Inc. 909 Hermosa Court Sunnyvale, CA 94085
Tim Showalter Mirapoint，Inc.加利福尼亚州桑尼维尔市赫莫萨法院909号，邮编94085
EMail: tjs@mirapoint.com
EMail: tjs@mirapoint.com
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.G.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年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 1894, January 1996.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and Cooperative Work in a Practical Multimedia Message System", Int. J. of Man-Machine Studies, April, 1991. Reprinted in Computer-Supported Cooperative Work and Groupware, Saul Greenberg, editor, Harcourt Brace Jovanovich, 1991. Reprinted in Readings in Groupware and Computer-Supported Cooperative Work, Ronald Baecker, editor, Morgan Kaufmann, 1993.
[火焰]Borenstein，N和C.Thyberg，“实用多媒体信息系统中的功率、易用性和协作工作”，人机研究国际期刊，1991年4月。《计算机支持的协作工作和群件》再版，索尔·格林伯格，哈考特·布拉斯·约万诺维奇编辑，1991年。《群件和计算机支持的合作工作读物》再版，Ronald Baecker，Morgan Kaufmann编辑，1993年。
[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月。
[IMAP] Crispin, M., "Internet Message Access Protocol - version 4rev1", RFC 2060, December 1996.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 20601996年12月。
[IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[IMAIL]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MDN] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[MDN]Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC22981998年3月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, November 1989.
[RFC1123]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]Postel，J.，“简单邮件传输协议”，STD 10，RFC 8211982年8月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[UTF-8]Yergeau，F.，“UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。