Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 5804 Isode Limited
Category: Standards Track T. Martin
ISSN: 2070-1721 BeThereBeSquare, Inc.
July 2010
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 5804 Isode Limited
Category: Standards Track T. Martin
ISSN: 2070-1721 BeThereBeSquare, Inc.
July 2010
A Protocol for Remotely Managing Sieve Scripts
用于远程管理筛选脚本的协议
Abstract
摘要
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts.
筛选脚本允许用户筛选传入的电子邮件。消息存储通常是密封的服务器，因此用户无法登录到它们，但用户必须能够在它们上更新脚本。本文档描述了一个协议“ManageSevere”，用于安全地管理远程服务器上的筛选脚本。该协议允许用户拥有多个脚本，并向用户发出语法错误脚本的警报。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5804.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5804.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Commands and Responses .....................................3
1.2. Syntax .....................................................3
1.3. Response Codes .............................................3
1.4. Active Script ..............................................6
1.5. Quotas .....................................................6
1.6. Script Names ...............................................6
1.7. Capabilities ...............................................7
1.8. Transport ..................................................9
1.9. Conventions Used in This Document .........................10
2. Commands .......................................................10
2.1. AUTHENTICATE Command ......................................11
2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
2.2. STARTTLS Command ..........................................16
2.2.1. Server Identity Check ..............................17
2.3. LOGOUT Command ............................................20
2.4. CAPABILITY Command ........................................20
2.5. HAVESPACE Command .........................................20
2.6. PUTSCRIPT Command .........................................21
2.7. LISTSCRIPTS Command .......................................23
2.8. SETACTIVE Command .........................................24
2.9. GETSCRIPT Command .........................................25
2.10. DELETESCRIPT Command .....................................25
2.11. RENAMESCRIPT Command .....................................26
2.12. CHECKSCRIPT Command ......................................27
2.13. NOOP Command .............................................28
2.14. Recommended Extensions ...................................28
2.14.1. UNAUTHENTICATE Command ............................28
3. Sieve URL Scheme ...............................................29
4. Formal Syntax ..................................................31
5. Security Considerations ........................................37
6. IANA Considerations ............................................38
6.1. ManageSieve Capability Registration Template ..............39
6.2. Registration of Initial ManageSieve Capabilities ..........39
6.3. ManageSieve Response Code Registration Template ...........41
6.4. Registration of Initial ManageSieve Response Codes ........41
7. Internationalization Considerations ............................46
8. Acknowledgements ...............................................46
9. References .....................................................47
9.1. Normative References ......................................47
9.2. Informative References ....................................48
1. Introduction ....................................................3
1.1. Commands and Responses .....................................3
1.2. Syntax .....................................................3
1.3. Response Codes .............................................3
1.4. Active Script ..............................................6
1.5. Quotas .....................................................6
1.6. Script Names ...............................................6
1.7. Capabilities ...............................................7
1.8. Transport ..................................................9
1.9. Conventions Used in This Document .........................10
2. Commands .......................................................10
2.1. AUTHENTICATE Command ......................................11
2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
2.2. STARTTLS Command ..........................................16
2.2.1. Server Identity Check ..............................17
2.3. LOGOUT Command ............................................20
2.4. CAPABILITY Command ........................................20
2.5. HAVESPACE Command .........................................20
2.6. PUTSCRIPT Command .........................................21
2.7. LISTSCRIPTS Command .......................................23
2.8. SETACTIVE Command .........................................24
2.9. GETSCRIPT Command .........................................25
2.10. DELETESCRIPT Command .....................................25
2.11. RENAMESCRIPT Command .....................................26
2.12. CHECKSCRIPT Command ......................................27
2.13. NOOP Command .............................................28
2.14. Recommended Extensions ...................................28
2.14.1. UNAUTHENTICATE Command ............................28
3. Sieve URL Scheme ...............................................29
4. Formal Syntax ..................................................31
5. Security Considerations ........................................37
6. IANA Considerations ............................................38
6.1. ManageSieve Capability Registration Template ..............39
6.2. Registration of Initial ManageSieve Capabilities ..........39
6.3. ManageSieve Response Code Registration Template ...........41
6.4. Registration of Initial ManageSieve Response Codes ........41
7. Internationalization Considerations ............................46
8. Acknowledgements ...............................................46
9. References .....................................................47
9.1. Normative References ......................................47
9.2. Informative References ....................................48
A ManageSieve connection consists of the establishment of a client/ server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.
ManageSeeve连接包括建立客户机/服务器网络连接、来自服务器的初始问候语以及客户机/服务器交互。这些客户机/服务器交互包括客户机命令、服务器数据和服务器完成结果响应。
All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of a ManageSieve client or server is either reading a line or reading a sequence of octets with a known count followed by a line.
客户端和服务器传输的所有交互都是以行的形式，即以CRLF结尾的字符串。ManageSeeve客户端或服务器的协议接收器正在读取一行或读取一个八位字节序列，其已知计数后跟一行。
ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP], which runs over TCP. There are three data types: atoms, numbers and strings. Strings may be quoted or literal. See [ACAP] for detailed descriptions of these types.
ManageSeeve是一种面向行的协议，与[IMAP]或[ACAP]非常相似，后者在TCP上运行。有三种数据类型：原子、数字和字符串。字符串可以是引号或文字。有关这些类型的详细说明，请参见[ACAP]。
Each command consists of an atom (the command name) followed by zero or more strings and numbers terminated by CRLF.
每个命令都由一个原子（命令名）和零个或多个字符串以及以CRLF结尾的数字组成。
All client queries are replied to with either an OK, NO, or BYE response. Each response may be followed by a response code (see Section 1.3) and by a string consisting of human-readable text in the local language (as returned by the LANGUAGE capability; see Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string SHOULD be shown to the user ,and implementations MUST NOT attempt to parse the message for meaning.
所有客户机查询都会以“确定”、“否”或“再见”回答。每个响应后面可能会有一个响应代码（见第1.3节）和一个由本地语言的人类可读文本组成的字符串（由语言功能返回；见第1.7节），以UTF-8[UTF-8]编码。字符串的内容应该显示给用户，实现不能试图解析消息的含义。
The BYE response SHOULD be used if the server wishes to close the connection. A server may wish to do this because the client was idle for too long or there were too many failed authentication attempts. This response can be issued at any time and should be immediately followed by a server hang-up of the connection. If a server has an inactivity timeout resulting in client autologout, it MUST be no less than 30 minutes after successful authentication. The inactivity timeout MAY be less before authentication.
如果服务器希望关闭连接，则应使用BYE响应。服务器可能希望这样做，因为客户端空闲时间太长，或者身份验证尝试失败太多。此响应可以在任何时候发出，并应立即在服务器挂断连接后发出。如果服务器的非活动超时导致客户端自动登录，则必须在成功身份验证后不少于30分钟。在进行身份验证之前，非活动超时可能较短。
An OK, NO, or BYE response from the server MAY contain a response code to describe the event in a more detailed machine-parsable fashion. A response code consists of data inside parentheses in the form of an atom, possibly followed by a space and arguments.
来自服务器的OK、NO或BYE响应可能包含响应代码，以更详细的机器可解析方式描述事件。响应代码由原子形式的括号内的数据组成，后面可能跟有空格和参数。
Response codes are defined when there is a specific action that a client can take based upon the additional information. In order to support future extension, the response code is represented as a slash-separated (Solidus, %x2F) hierarchy with each level of hierarchy representing increasing detail about the error. Response codes MUST NOT start with the Solidus character. Clients MUST tolerate additional hierarchical response code detail that they don't understand. For example, if the client supports the "QUOTA" response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
当客户端可以根据附加信息执行特定操作时，将定义响应代码。为了支持将来的扩展，响应代码表示为斜杠分隔的（Solidus，%x2F）层次结构，每个层次结构表示有关错误的更多细节。响应代码不得以Solidus字符开头。客户端必须容忍他们不理解的其他层次化响应代码细节。例如，如果客户端支持“QUOTA”响应代码，但不理解“QUOTA/MAXSCRIPTS”响应代码，则应将“QUOTA/MAXSCRIPTS”视为“QUOTA”。
Client implementations MUST tolerate (ignore) response codes that they do not recognize.
客户端实现必须容忍（忽略）它们无法识别的响应代码。
The currently defined response codes are the following:
当前定义的响应代码如下所示：
AUTH-TOO-WEAK
太弱
This response code is returned in the NO or BYE response from an AUTHENTICATE command. It indicates that site security policy forbids the use of the requested mechanism for the specified authentication identity.
此响应代码在AUTHENTICATE命令的NO或BYE响应中返回。它表示站点安全策略禁止对指定的身份验证标识使用请求的机制。
ENCRYPT-NEEDED
需要加密
This response code is returned in the NO or BYE response from an AUTHENTICATE command. It indicates that site security policy requires the use of a strong encryption mechanism for the specified authentication identity and mechanism.
此响应代码在AUTHENTICATE命令的NO或BYE响应中返回。它表示站点安全策略要求对指定的身份验证标识和机制使用强加密机制。
QUOTA
定额
If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined quota constraints. If this response code is returned in the OK response, it can mean that the user's storage is near its quota, or it can mean that the account exceeded its quota but that the condition is being allowed by the server (the server supports so-called soft quotas). The QUOTA response code has two more detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts) and "QUOTA/MAXSIZE" (the maximum script size).
如果在NO/BYE响应中返回此响应代码，则表示该命令将用户置于站点定义的配额约束之上。如果此响应代码在OK响应中返回，则可能意味着用户的存储接近其配额，也可能意味着帐户超出其配额，但服务器允许该条件（服务器支持所谓的软配额）。配额响应代码有两个更详细的变体：“配额/maxscript”（每个用户脚本的最大数量）和“配额/MAXSIZE”（最大脚本大小）。
REFERRAL
送交
This response code may be returned with a BYE result from any command, and includes a mandatory parameter that indicates what server to access to manage this user's Sieve scripts. The server will be specified by a Sieve URL (see Section 3). The scriptname
此响应代码可能会随任何命令的BYE结果一起返回，并包含一个强制参数，该参数指示要访问哪个服务器来管理此用户的筛选脚本。服务器将由筛选URL指定（参见第3节）。脚本名
portion of the URL MUST NOT be specified. The client should authenticate to the specified server and use it for all further commands in the current session.
不能指定URL的一部分。客户端应向指定的服务器进行身份验证，并将其用于当前会话中的所有其他命令。
SASL
萨斯勒
This response code can occur in the OK response to a successful AUTHENTICATE command and includes the optional final server response data from the server as specified by [SASL].
此响应代码可以出现在对成功的AUTHENTICATE命令的OK响应中，并包括由[SASL]指定的来自服务器的可选最终服务器响应数据。
TRANSITION-NEEDED
需要过渡
This response code occurs in a NO response of an AUTHENTICATE command. It indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified mechanism. This is typically done by establishing a secure channel using TLS, verifying server identity as specified in Section 2.2.1, and finally authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions.
此响应代码出现在AUTHENTICATE命令的无响应中。它表示用户名有效，但需要更新身份验证数据库中的条目，以便允许使用指定的机制进行身份验证。这通常是通过使用TLS建立安全通道，按照第2.2.1节的规定验证服务器身份，最后使用[PLAIN]身份验证机制进行一次身份验证来实现的。然后，所选机制应可用于后续会话中的身份验证。
This condition can happen if a user has an entry in a system authentication database such as Unix /etc/passwd, but does not have credentials suitable for use by the specified mechanism.
如果用户在系统身份验证数据库（如Unix/etc/passwd）中有条目，但没有适合指定机制使用的凭据，则可能发生这种情况。
TRYLATER
TRYLATER
A command failed due to a temporary server failure. The client MAY continue using local information and try the command later. This response code only makes sense when returned in a NO/BYE response.
由于临时服务器故障，命令失败。客户端可以继续使用本地信息，稍后重试该命令。此响应代码仅在以NO/BYE响应返回时才有意义。
ACTIVE
忙碌的
A command failed because it is not allowed on the active script, for example, DELETESCRIPT on the active script. This response code only makes sense when returned in a NO/BYE response.
命令失败，因为不允许在活动脚本上使用该命令，例如，在活动脚本上使用DELETESCRIPT。此响应代码仅在以NO/BYE响应返回时才有意义。
NONEXISTENT
不存在
A command failed because the referenced script name doesn't exist. This response code only makes sense when returned in a NO/BYE response.
命令失败，因为引用的脚本名称不存在。此响应代码仅在以NO/BYE响应返回时才有意义。
ALREADYEXISTS
老古董
A command failed because the referenced script name already exists. This response code only makes sense when returned in a NO/BYE response.
命令失败，因为引用的脚本名称已存在。此响应代码仅在以NO/BYE响应返回时才有意义。
TAG
标签
This response code name is followed by a string specified in the command. See Section 2.13 for a possible use case.
此响应代码名后面是命令中指定的字符串。有关可能的用例，请参见第2.13节。
WARNINGS
警告
This response code MAY be returned by the server in the OK response (but it might be returned with the NO/BYE response as well) and signals the client that even though the script is syntactically valid, it might contain errors not intended by the script writer. This response code is typically returned in response to PUTSCRIPT and/or CHECKSCRIPT commands. A client seeing such response code SHOULD present the returned warning text to the user.
此响应代码可能由服务器在OK响应中返回（但也可能与NO/BYE响应一起返回），并向客户端发出信号，表示即使脚本在语法上有效，也可能包含脚本编写器不希望出现的错误。此响应代码通常在响应PUTSCRIPT和/或CHECKSCRIPT命令时返回。看到此类响应代码的客户端应向用户显示返回的警告文本。
A user may have multiple Sieve scripts on the server, yet only one script may be used for filtering of incoming messages. This is the active script. Users may have zero or one active script and MUST use the SETACTIVE command described below for changing the active script or disabling Sieve processing. For example, users may have an everyday script they normally use and a special script they use when they go on vacation. Users can change which script is being used without having to download and upload a script stored somewhere else.
一个用户在服务器上可能有多个筛选脚本，但只有一个脚本可用于筛选传入消息。这是活动脚本。用户可能没有或只有一个活动脚本，必须使用下面描述的SETACTIVE命令来更改活动脚本或禁用筛选处理。例如，用户可能有他们通常使用的日常脚本和他们在度假时使用的特殊脚本。用户可以更改正在使用的脚本，而无需下载和上载存储在其他地方的脚本。
Servers SHOULD impose quotas to prevent malicious users from overflowing available storage. If a command would place a user over a quota setting, servers that impose such quotas MUST reply with a NO response containing the QUOTA response code. Client implementations MUST be able to handle commands failing because of quota restrictions.
服务器应设置配额，以防止恶意用户溢出可用存储。如果命令将用户置于配额设置之上，则施加此类配额的服务器必须使用包含配额响应代码的NO响应进行响应。客户端实现必须能够处理由于配额限制而失败的命令。
A Sieve script name is a sequence of Unicode characters encoded in UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition (Section 2 of [NET-UNICODE]), with the additional restriction of prohibiting the following Unicode characters:
筛脚本名称是以UTF-8[UTF-8]编码的Unicode字符序列。脚本名称必须符合Net-Unicode定义（《Net-Unicode》）第2节的规定，并附加禁止以下Unicode字符的限制：
o 0000-001F; [CONTROL CHARACTERS]
o 0000-001F；[控制字符]
o 007F; DELETE
o 007F；删去
o 0080-009F; [CONTROL CHARACTERS]
o 0080-009F；[控制字符]
o 2028; LINE SEPARATOR
o 2028; 线路分离器
o 2029; PARAGRAPH SEPARATOR
o 2029; 段落分隔符
Sieve script names MUST be at least one octet (and hence Unicode character) long. Zero octets script name has a special meaning (see Section 2.8). Servers MUST allow names of up to 128 Unicode characters in length (which can take up to 512 bytes when encoded in UTF-8, not counting the terminating NUL), and MAY allow longer names. A server that receives a script name longer than its internal limit MUST reject the corresponding operation, in particular it MUST NOT truncate the script name.
筛选脚本名称必须至少有一个八位字节（因此是Unicode字符）长。零八位字节脚本名称具有特殊含义（参见第2.8节）。服务器必须允许长度最多为128个Unicode字符的名称（在UTF-8中编码时可能需要512字节，不包括终止的NUL），并且可能允许更长的名称。接收的脚本名称超过其内部限制的服务器必须拒绝相应的操作，尤其是不能截断脚本名称。
Server capabilities are sent automatically by the server upon a client connection, or after successful STARTTLS and AUTHENTICATE (which establishes a Simple Authentication and Security Layer (SASL)) commands. Capabilities may change immediately after a successfully completed STARTTLS command, and/or immediately after a successfully completed AUTHENTICATE command, and/or after a successfully completed UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST remain static at all other times.
服务器功能在客户端连接时或成功启动TTLS和AUTHENTICATE（建立简单身份验证和安全层（SASL））命令后由服务器自动发送。在成功完成STARTTLS命令后，和/或在成功完成身份验证命令后，和/或在成功完成未经身份验证命令后，功能可能会立即更改（见第2.14.1节）。能力必须在所有其他时间保持静态。
Clients MAY request the capabilities at a later time by issuing the CAPABILITY command described later. The capabilities consist of a series of lines each with one or two strings. The first string is the name of the capability, which is case-insensitive. The second optional string is the value associated with that capability. Order of capabilities is arbitrary, but each capability name can appear at most once.
客户机可以稍后通过发出后面描述的CAPABILITY命令来请求这些功能。这些功能由一系列行组成，每行有一个或两个字符串。第一个字符串是功能的名称，不区分大小写。第二个可选字符串是与该功能关联的值。功能的顺序是任意的，但每个功能名称最多只能出现一次。
The following capabilities are defined in this document:
本文档中定义了以下功能：
IMPLEMENTATION - Name of implementation and version. This capability MUST always be returned by the server.
IMPLEMENTATION—实现的名称和版本。此功能必须始终由服务器返回。
SASL - List of SASL mechanisms supported by the server, each separated by a space. This list can be empty if and only if STARTTLS is also advertised. This means that the client must negotiate TLS encryption with STARTTLS first, at which point the SASL capability will list a non-empty list of SASL mechanisms.
SASL—服务器支持的SASL机制列表，每个机制之间用空格分隔。当且仅当STARTTLS也被公布时，此列表可以为空。这意味着客户端必须首先与STARTTLS协商TLS加密，此时SASL功能将列出一个非空的SASL机制列表。
SIEVE - List of space-separated Sieve extensions (as listed in Sieve "require" action [SIEVE]) supported by the Sieve engine. This capability MUST always be returned by the server.
筛子-筛子引擎支持的空间分离筛子扩展列表（如筛子“要求”操作[SIVE]中所列）。此功能必须始终由服务器返回。
STARTTLS - If TLS [TLS] is supported by this implementation. Before advertising this capability a server MUST verify to the best of its ability that TLS can be successfully negotiated by a client with common cipher suites. Specifically, a server should verify that a server certificate has been installed and that the TLS subsystem has successfully initialized. This capability SHOULD NOT be advertised once STARTTLS or AUTHENTICATE command completes successfully. Client and server implementations MUST implement the STARTTLS extension.
STARTTLS-如果此实现支持TLS[TLS]。在公布此功能之前，服务器必须尽其最大能力验证具有通用密码套件的客户端是否可以成功协商TLS。具体而言，服务器应验证是否已安装服务器证书，以及TLS子系统是否已成功初始化。一旦STARTTLS或AUTHENTICATE命令成功完成，就不应发布此功能。客户端和服务器实现必须实现STARTTLS扩展。
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" actions a script can perform during a single evaluation. Note that this is different from the total number of "redirect" actions a script can contain. The value is a non-negative number represented as a ManageSieve string.
MAXREDIRECTS-指定脚本在单个计算过程中可以执行的筛选“重定向”操作的数量限制。请注意，这与脚本可以包含的“重定向”操作总数不同。该值是以ManageSeeve字符串表示的非负数。
NOTIFY - A space-separated list of URI schema parts for supported notification methods. This capability MUST be specified if the Sieve implementation supports the "enotify" extension [NOTIFY].
NOTIFY—受支持的通知方法的URI架构部分的空格分隔列表。如果Sieve实现支持“enotify”扩展[NOTIFY]，则必须指定此功能。
LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently used for human-readable error messages. If this capability is not returned, the "i-default" [RFC2277] language is assumed. Note that the current language MAY be per-user configurable (i.e., it MAY change after authentication).
语言-当前用于人类可读错误消息的语言（<LANGUAGE Tag>from[RFC5646]）。如果未返回此功能，则假定使用“i-default”[RFC2277]语言。请注意，当前语言可能是每个用户可配置的（即，在身份验证后可能会更改）。
OWNER - The canonical name of the logged-in user (SASL "authorization identity") encoded in UTF-8. This capability MUST NOT be returned in unauthenticated state and SHOULD be returned once the AUTHENTICATE command succeeds.
所有者-以UTF-8编码的登录用户的规范名称（SASL“授权标识”）。此功能不得在未经身份验证的状态下返回，并且应在身份验证命令成功后返回。
VERSION - This capability MUST be returned by servers compliant with this document or its successor. For servers compliant with this document, the capability value is the string "1.0". Lack of this capability means that the server predates this specification and thus doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT, and NOOP.
版本-此功能必须由符合本文档或其后续版本的服务器返回。对于符合本文档要求的服务器，功能值为字符串“1.0”。缺少此功能意味着服务器早于此规范，因此不支持以下命令：RENAMESCRIPT、CHECKSCRIPT和NOOP。
Section 2.14 defines some additional ManageSieve extensions and their respective capabilities.
第2.14节定义了一些附加的ManageSeeve扩展及其各自的功能。
A server implementation MUST return SIEVE, IMPLEMENTATION, and VERSION capabilities.
服务器实现必须返回筛选、实现和版本功能。
A client implementation MUST ignore any listed capabilities that it does not understand.
客户端实现必须忽略它不了解的任何列出的功能。
Example:
例子：
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "StaRTTLS"
S: "NOTIFY" "xmpp mailto"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "StaRTTLS"
S: "NOTIFY" "xmpp mailto"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
After successful authentication, this might look like this:
成功身份验证后，这可能如下所示：
Example:
例子：
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "NOTIFY" "xmpp mailto"
S: "OWNER" "alexey@example.com"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation"
S: "NOTIFY" "xmpp mailto"
S: "OWNER" "alexey@example.com"
S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0"
S: OK
The ManageSieve protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, a ManageSieve server typically listens on port 4190.
ManageSieve协议假定有可靠的数据流，如TCP提供的数据流。使用TCP时，ManageSeeve服务器通常侦听端口4190。
Before opening the TCP connection, the ManageSieve client first MUST resolve the Domain Name System (DNS) hostname associated with the receiving entity and determine the appropriate TCP port for communication with the receiving entity. The process is as follows:
在打开TCP连接之前，ManageSeve客户端必须首先解析与接收实体关联的域名系统（DNS）主机名，并确定与接收实体通信的适当TCP端口。程序如下：
1. Attempt to resolve the hostname using a [DNS-SRV] Service of "sieve" and a Proto of "tcp" for the target domain (e.g., "example.net"), resulting in resource records such as "_sieve._tcp.example.net.". The result of the SRV lookup, if successful, will be one or more combinations of a port and hostname; the ManageSieve client MUST resolve the returned hostnames to IPv4/IPv6 addresses according to returned SRV record weight. IP addresses from the first successfully resolved hostname (with the corresponding port number returned by SRV lookup) are used to connect to the server. If connection using one of the IP addresses fails, the next resolved IP address is
1. 尝试使用[DNS-SRV]服务“sieve”和目标域（例如，“example.net”）的Proto“tcp”解析主机名，从而生成资源记录，如“\u sieve.\u tcp.example.net.”。SRV查找的结果（如果成功）将是端口和主机名的一个或多个组合；ManageSeeve客户端必须根据返回的SRV记录权重将返回的主机名解析为IPv4/IPv6地址。第一个成功解析的主机名中的IP地址（SRV查找返回相应的端口号）用于连接到服务器。如果使用其中一个IP地址的连接失败，则将使用下一个解析的IP地址
used to connect. If connection to all resolved IP addresses fails, then the resolution/connect is repeated for the next hostname returned by SRV lookup.
用于连接。如果与所有解析的IP地址的连接失败，则对SRV查找返回的下一个主机名重复解析/连接。
2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or IPv6 address record resolution to determine the IP address, where the port used is the default ManageSieve port of 4190.
2. 如果SRV查找失败，回退应该是正常的IPv4或IPv6地址记录解析，以确定IP地址，其中使用的端口是默认的ManageSeeve端口4190。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Line breaks that do not start a new "C:" or "S:" exist for editorial reasons.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。由于编辑原因，存在不开始新“C:”或“S:”的换行符。
Examples of authentication in this document are using DIGEST-MD5 [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
本文档中的身份验证示例使用DIGEST-MD5[DIGEST-MD5]和GSSAPI[GSSAPI]SASL机制。
This section and its subsections describe valid ManageSieve commands. Upon initial connection to the server, the client's session is in non-authenticated state. Prior to successful authentication, only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section 2.13) commands are valid. ManageSieve extensions MAY define other commands that are valid in non-authenticated state. Servers MUST reject all other commands with a NO response. Clients may pipeline commands (send more than one command at a time without waiting for completion of the first command). However, a group of commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a HAVESPACE command anywhere but the last command in the list.
本节及其子节介绍有效的ManageSieve命令。初始连接到服务器时，客户端会话处于未验证状态。在成功验证之前，只有AUTHENTICATE、CAPABILITY、STARTTLS、LOGOUT和NOOP（参见第2.13节）命令有效。ManageSeeve扩展可以定义其他在未验证状态下有效的命令。服务器必须拒绝没有响应的所有其他命令。客户机可以管道化命令（一次发送多个命令，而不等待第一个命令完成）。但是，一起发送的一组命令除了列表中的最后一个命令外，任何地方都不能有AUTHENTICATE（*）、STARTTLS或HAVESPACE命令。
(*) - The only exception to this rule is when the AUTHENTICATE command contains an initial response for a SASL mechanism that allows clients to send data first, the mechanism is known to complete in one round trip, and the mechanism doesn't negotiate a SASL security layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL].
（*）-此规则的唯一例外是，当AUTHENTICATE命令包含允许客户端首先发送数据的SASL机制的初始响应时，已知该机制在一次往返中完成，并且该机制不协商SASL安全层。此类SASL机制的两个示例是普通[PLAIN]和外部[SASL]。
Arguments: String - mechanism String - initial data (optional)
参数：字符串-机制字符串-初始数据（可选）
The AUTHENTICATE command indicates a SASL [SASL] authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to identify and authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTHENTICATE command by sending the NO response.
AUTHENTICATE命令向服务器指示SASL[SASL]身份验证机制。如果服务器支持请求的身份验证机制，它将执行身份验证协议交换以识别和验证用户。可选地，它还为后续协议交互协商安全层。如果请求的身份验证机制不受支持，服务器将通过发送NO响应来拒绝AUTHENTICATE命令。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the selected authentication mechanism. A server challenge consists of a string (quoted or literal) followed by a CRLF. The contents of the string is a base-64 encoding [BASE64] of the SASL data. A client response consists of a string (quoted or literal) with the base-64 encoding of the SASL data followed by a CRLF. If the client wishes to cancel the authentication exchange, it issues a string containing a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a NO reply.
身份验证协议交换由一系列特定于所选身份验证机制的服务器质询和客户端响应组成。服务器质询由一个字符串（引号或文字）后跟一个CRLF组成。字符串的内容是SASL数据的base-64编码[BASE64]。客户机响应由一个字符串（带引号或文字）组成，该字符串带有SASL数据的base-64编码，后跟一个CRLF。如果客户端希望取消身份验证交换，它将发出一个包含单个“*”的字符串。如果服务器收到这样的响应，它必须通过发送NO应答来拒绝AUTHENTICATE命令。
Note that an empty challenge/response is sent as an empty string. If the mechanism dictates that the final response is sent by the server, this data MAY be placed within the data portion of the SASL response code to save a round trip.
请注意，空的质询/响应将作为空字符串发送。如果该机制规定最终响应由服务器发送，则该数据可放置在SASL响应代码的数据部分中以保存往返。
The optional initial-response argument to the AUTHENTICATE command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial-response argument as if it were sent in response to the empty challenge. If the initial-response argument to the AUTHENTICATE command is used with a mechanism that sends data in the initial challenge, the server MUST reject the AUTHENTICATE command by sending the NO response.
当使用定义为在初始质询中不发送数据的身份验证机制时，AUTHENTICATE命令的可选初始响应参数用于保存往返。当initialresponse参数与这种机制一起使用时，初始空质询不会发送给客户端，服务器使用initialresponse参数中的数据，就好像它是响应空质询而发送的一样。如果AUTHENTICATE命令的initial response参数与在初始质询中发送数据的机制一起使用，则服务器必须通过发送NO响应来拒绝AUTHENTICATE命令。
The service name specified by this protocol's profile of SASL is "sieve".
此协议的SASL配置文件指定的服务名称为“sieve”。
Reauthentication is not supported by ManageSieve protocol's profile of SASL. That is, after a successfully completed AUTHENTICATE command, no more AUTHENTICATE commands may be issued in the same session. After a successful AUTHENTICATE command completes, a server MUST reject any further AUTHENTICATE commands with a NO reply.
SASL的ManageSeeve协议配置文件不支持重新验证。也就是说，在成功完成身份验证命令后，在同一会话中不能再发出身份验证命令。在成功完成身份验证命令后，服务器必须拒绝任何进一步的身份验证命令，并且没有回复。
However, note that a server may implement the UNAUTHENTICATE extension described in Section 2.14.1.
但是，请注意，服务器可以实现第2.14.1节中描述的未经验证的扩展。
If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the successful authentication exchange for the client, and the CRLF of the OK response for the server.
如果通过SASL身份验证交换协商安全层，则该层将在客户端成功完成身份验证交换的CRLF和服务器的OK响应的CRLF之后立即生效。
When a security layer takes effect, the ManageSieve protocol is reset to the initial state (the state in ManageSieve after a client has connected to the server). The server MUST discard any knowledge obtained from the client that was not obtained from the SASL (or TLS) negotiation itself. Likewise, the client MUST discard any knowledge obtained from the server, such as the list of ManageSieve extensions, that was not obtained from the SASL (and/or TLS) negotiation itself. (Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack. See below.)
当安全层生效时，ManageSeeve协议将重置为初始状态（客户端连接到服务器后ManageSeeve中的状态）。服务器必须放弃从客户机获得的、不是从SASL（或TLS）协商本身获得的任何知识。同样，客户机必须放弃从服务器获得的、不是从SASL（和/或TLS）协商本身获得的任何知识，例如ManageSeeve扩展列表。（请注意，客户端可能会在身份验证前后比较公布的SASL机制，以检测主动向下协商攻击。请参阅下文。）
Once a SASL security layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks that alter the capabilities list prior to SASL negotiation. The capability results MUST include all SASL mechanisms the server was capable of negotiating with that client. This is done in order to allow the client to detect an active down-negotiation attack. If a user-oriented client detects such a down-negotiation attack, it SHOULD either notify the user (it MAY give the user the opportunity to continue with the ManageSieve session in this case) or close the transport connection and indicate that a down-negotiation attack might be in progress. If an automated client detects a down-negotiation attack, it SHOULD return or log an error indicating that a possible attack might be in progress and/or SHOULD close the transport connection.
一旦建立了SASL安全层，服务器必须重新发布功能结果，然后是OK响应。这对于防止中间人攻击是必要的，中间人攻击会在SASL协商之前改变功能列表。能力结果必须包括服务器能够与该客户端协商的所有SASL机制。这样做是为了让客户端能够检测到主动向下协商攻击。如果面向用户的客户端检测到这种向下协商攻击，它应该通知用户（在这种情况下，它可能会给用户继续ManageSeeve会话的机会），或者关闭传输连接并指示向下协商攻击可能正在进行。如果自动客户端检测到向下协商攻击，它应该返回或记录一个错误，指示可能的攻击正在进行和/或应该关闭传输连接。
When both [TLS] and SASL security layers are in effect, the TLS encoding MUST be applied (when sending data) after the SASL encoding.
当[TLS]和SASL安全层都有效时，必须在SASL编码之后应用TLS编码（发送数据时）。
Server implementations SHOULD support SASL proxy authentication so that an administrator can administer a user's scripts. Proxy authentication is when a user authenticates as herself/himself but requests the server to act (authorize) as another user.
服务器实现应该支持SASL代理身份验证，以便管理员可以管理用户的脚本。代理身份验证是指用户以自己身份进行身份验证，但请求服务器以另一用户身份进行操作（授权）。
The authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server MUST use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an
此[SASL]交换生成的授权标识是一个“简单用户名”（在[SASLprep]中定义的含义），客户端和服务器都必须使用[StringPrep]算法的[SASLprep]配置文件来准备这些名称以供传输或比较。如果授权标识的准备失败或导致
empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
空字符串（除非它作为空字符串传输），否则服务器的身份验证必须失败。
If an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command. In other words, the client may request authentication types in decreasing order of preference.
如果AUTHENTICATE命令失败且没有响应，则客户端可以通过发出另一个AUTHENTICATE命令来尝试另一种身份验证机制。换言之，客户机可以按偏好的降序请求认证类型。
Note that a failed (NO) response to the AUTHENTICATE command may contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed description of the relevant conditions.
请注意，对AUTHENTICATE命令的失败（否）响应可能包含以下响应代码之一：AUTH-TOO-WEAK、ENCRYPT-NEEDED或TRANSITION-NEEDED。有关相关条件的详细说明，请参见第1.3节。
To ensure interoperability, both client and server implementations of the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL mechanism, as well as [PLAIN] over [TLS].
为确保互操作性，ManageSeeve协议的客户端和服务器实现必须实现SCRAM-SHA-1[SCRAM]SASL机制，以及[TLS]上的[PLAIN]。
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in other email-related protocols; however, a longer-term goal is to migrate email-related protocols from using PLAIN over TLS to SCRAM-SHA-1 mechanism.
注：PLAIN over TLS的使用反映了当前在其他电子邮件相关协议中使用PLAIN over TLS的情况；然而，一个长期目标是将电子邮件相关协议从使用基于TLS的普通协议迁移到SCRAM-SHA-1机制。
Examples (Note that long lines are folded for readability and are not part of protocol exchange):
示例（请注意，为便于阅读，长行被折叠起来，不属于协议交换的一部分）：
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: "VERSION" "1.0"
S: OK
C: Authenticate "DIGEST-MD5"
S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04"
C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA=="
S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
mZmZA==")
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: "VERSION" "1.0"
S: OK
C: Authenticate "DIGEST-MD5"
S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04"
C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA=="
S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
mZmZA==")
A slightly different variant of the same authentication exchange is:
同一身份验证交换的一个稍有不同的变体是：
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "STARTTLS"
S: OK
C: Authenticate "DIGEST-MD5"
S: {136}
S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04
C: {300+}
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA==
S: {56}
S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C: ""
S: OK
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "STARTTLS"
S: OK
C: Authenticate "DIGEST-MD5"
S: {136}
S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
cyxjaGFyc2V0PXV0Zi04
C: {300+}
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
A9YXV0aA==
S: {56}
S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
C: ""
S: OK
Another example demonstrating use of SASL PLAIN mechanism under TLS follows. This example also demonstrate use of SASL "initial response" (the second parameter to the Authenticate command):
下面是另一个演示在TLS下使用SASL平原机制的示例。此示例还演示了SASL“初始响应”（Authenticate命令的第二个参数）的使用：
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" ""
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
C: STARTTLS
S: OK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN"
S: "SIEVE" "fileinto vacation"
S: OK
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
S: BYE "Too many failed authentication attempts"
<Server closes connection>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" ""
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
C: STARTTLS
S: OK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN"
S: "SIEVE" "fileinto vacation"
S: OK
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
S: NO
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
S: BYE "Too many failed authentication attempts"
<Server closes connection>
The following example demonstrates use of SASL "initial response". It also demonstrates that an empty response can be sent as a literal and that negotiating a SASL security layer results in the server re-issuing server capabilities:
下面的示例演示了SASL“初始响应”的使用。它还演示了空响应可以作为文本发送，并且协商SASL安全层会导致服务器重新发布服务器功能：
C: AUTHENTICATE "GSSAPI" {1488+}
C: YIIE[...1480 octets here ...]dA==
S: {208}
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
[...114 octets here ...]
/yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
C: {0+}
C:
S: {44}
S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
C: {44+}
C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
S: OK
<Further commands/responses are under SASL security layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "LANGUAGE" "ru"
S: "MAXREDIRECTS" "3"
S: ok
C: AUTHENTICATE "GSSAPI" {1488+}
C: YIIE[...1480 octets here ...]dA==
S: {208}
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
[...114 octets here ...]
/yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
C: {0+}
C:
S: {44}
S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
C: {44+}
C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
S: OK
<Further commands/responses are under SASL security layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "LANGUAGE" "ru"
S: "MAXREDIRECTS" "3"
S: ok
This section is normative for ManageSieve client implementations that support SASL [PLAIN] over [TLS].
本节是在[TLS]上支持SASL[PLAIN]的ManageSeeve客户端实现的规范。
If a ManageSieve client is willing to use SASL PLAIN over TLS to authenticate to the ManageSieve server, the client MUST verify the server identity (see Section 2.2.1). If the server identity can't be verified (e.g., the server has not provided any certificate, or if the certificate verification fails), the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism.
如果ManageSeeve客户端愿意使用SASL PLAIN over TLS向ManageSeeve服务器进行身份验证，则客户端必须验证服务器标识（请参阅第2.2.1节）。如果无法验证服务器标识（例如，服务器未提供任何证书，或者证书验证失败），则客户端不得尝试使用SASL普通机制进行身份验证。
Support for STARTTLS command in servers is optional. Its availability is advertised with "STARTTLS" capability as described in Section 1.7.
在服务器中支持STARTTLS命令是可选的。其可用性通过第1.7节所述的“STARTTLS”功能进行宣传。
The STARTTLS command requests commencement of a TLS [TLS] negotiation. The negotiation begins immediately after the CRLF in the OK response. After a client issues a STARTTLS command, it MUST
STARTTLS命令请求开始TLS[TLS]协商。协商在确认响应中的CRLF之后立即开始。客户端发出STARTTLS命令后，必须
NOT issue further commands until a server response is seen and the TLS negotiation is complete.
在看到服务器响应和TLS协商完成之前，不要发出进一步的命令。
The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.
STARTTLS命令仅在未经身份验证的状态下有效。即使在TLS协商期间提供了客户端凭据，服务器仍保持未经身份验证的状态。成功交换TLS客户端凭据后，可以使用SASL[SASL]外部机制进行身份验证，但不需要支持STARTTLS命令的服务器来支持外部机制。
After the TLS layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks that alter the capabilities list prior to STARTTLS. This capability result MUST NOT include the STARTTLS capability.
TLS层建立后，服务器必须重新发布性能结果，然后是OK响应。这对于防止中间人攻击是必要的，因为中间人攻击会改变STARTTLS之前的功能列表。此能力结果不得包括STARTTLS能力。
The client MUST discard cached capability information and replace it with the new information. The server MAY advertise different capabilities after STARTTLS.
客户端必须丢弃缓存的功能信息，并用新信息替换它。服务器可能会在STARTTLS之后公布不同的功能。
Example:
例子：
C: StartTls
S: oK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "LANGUAGE" "fr"
S: ok
C: StartTls
S: oK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "VERSION" "1.0"
S: "LANGUAGE" "fr"
S: ok
During the TLS negotiation, the ManageSieve client MUST check its understanding of the server hostname/IP address against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. In this section, the client's understanding of the server's identity is called the "reference identity".
在TLS协商期间，ManageSeve客户端必须对照服务器证书消息中显示的服务器标识检查其对服务器主机名/IP地址的理解，以防止中间人攻击。在本节中，客户机对服务器标识的理解称为“参考标识”。
Checking is performed according to the following rules:
根据以下规则进行检查：
o If the reference identity is a hostname:
o 如果引用标识是主机名：
1. If a subjectAltName extension of the SRVName [X509-SRV], dNSName [X509] (in that order of preference) type is present in the server's certificate, then it SHOULD be used as the
1. 如果服务器的证书中存在SRVName[X509-SRV]、dNSName[X509]（按优先顺序）类型的subjectAltName扩展名，则应将其用作
source of the server's identity. Matching is performed as described in Section 2.2.1.1, with the exception that no wildcard matching is allowed for SRVName type. If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
服务器标识的源。按照第2.2.1.1节中的描述执行匹配，但SRVName类型不允许通配符匹配。如果证书包含多个名称（例如，多个dNSName字段），则认为与任何一个字段的匹配都是可接受的。
2. The client MAY use other types of subjectAltName for performing comparison.
2. 客户端可以使用其他类型的subjectAltName来执行比较。
3. The server's identity MAY also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 2.2.1.1, below. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention.
3. 还可以通过将参考标识与服务器证书的subjectName字段的叶相对可分辨名称（RDN）中的公共名称（CN）[RFC4519]值进行比较来验证服务器的标识。使用下面第2.2.1.1节中的DNS名称比较规则执行此比较。虽然公共名称值的使用是现有的做法，但不推荐使用，并鼓励证书颁发机构提供subjectAltName值。注意，TLS实现可以根据X.500或其他约定在证书中表示DNs。例如，一些X.500实现使用从左到右（最重要到最不重要）约定而不是LDAP的从右到左约定对DN中的RDN进行排序。
o When the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison. The comparison is performed as described in Section 2.2.1.2.
o 当引用标识是IP地址时，客户端应使用iPAddress subjectAltName进行比较。按照第2.2.1.2节所述进行比较。
If the server identity check fails, user-oriented clients SHOULD either notify the user (clients MAY give the user the opportunity to continue with the ManageSieve session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD return or log an error indicating that the server's identity is suspect and/or SHOULD close the transport connection. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
如果服务器标识检查失败，面向用户的客户端应该通知用户（在这种情况下，客户端可能会给用户机会继续ManageSeeve会话），或者关闭传输连接并指示服务器标识可疑。自动客户端应返回或记录一个错误，指示服务器的标识可疑，和/或应关闭传输连接。自动客户端可以提供禁用此检查的配置设置，但必须提供启用此检查的设置。
Beyond the server identity check described in this section, clients should be prepared to do further checking to ensure that the server is authorized to provide the service it is requested to provide. The client may need to make use of local policy information in making this determination.
除了本节中描述的服务器身份检查之外，客户机还应该准备进行进一步的检查，以确保服务器有权提供请求提供的服务。客户可能需要利用当地的政策信息来确定。
If the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] before comparison with subjectAltName values of type dNSName. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of [RFC3490] as follows:
如果参考标识是国际化域名，则在与dNSName类型的subjectAltName值进行比较之前，一致性实现必须将其转换为RFC 3490[RFC3490]第4节中规定的ASCII兼容编码（ACE）格式。具体而言，一致性实施必须执行[RFC3490]第4节中规定的转换操作，如下所示：
o in step 1, the domain name SHALL be considered a "stored string";
o 在步骤1中，域名应被视为“存储字符串”；
o in step 3, set the flag called "UseSTD3ASCIIRules";
o 在步骤3中，设置名为“usestd3ascirules”的标志；
o in step 4, process each label with the "ToASCII" operation; and
o 在步骤4中，使用“ToASCII”操作处理每个标签；和
o in step 5, change all label separators to U+002E (full stop).
o 在步骤5中，将所有标签分隔符更改为U+002E（句号）。
After performing the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules specified in Section 3 of [RFC3490]; i.e., once all label separators are replaced with U+002E (dot) they are compared in the case-insensitive manner.
执行“到ASCII”转换后，必须根据[RFC3490]第3节规定的规则比较DNS标签和名称是否相等；i、 例如，一旦所有标签分隔符被U+002E（dot）替换，它们将以不区分大小写的方式进行比较。
The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com.
dNSName类型的subjectAltName值中允许使用“*”（ASCII 42）通配符，然后仅作为该值中最左侧（最低有效）的DNS标签。此通配符与服务器名称中最左边的DNS标签匹配。也就是说，subject*.example.com与服务器名a.example.com和b.example.com匹配，但与example.com或a.b.example.com不匹配。
When the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the octet string will contain exactly four octets. For IP Version 6, as specified in RFC 2460, the octet string will contain exactly sixteen octets. This octet string is then compared against subjectAltName values of type iPAddress. A match occurs if the reference identity octet string and value octet strings are identical.
当参考标识是IP地址时，该标识必须转换为“网络字节顺序”八位字节字符串表示形式[RFC791][RFC2460]。对于IP版本4，如RFC 791中所述，八位字节字符串将正好包含四个八位字节。对于IP版本6，如RFC 2460中所规定，八位字节字符串将正好包含十六个八位字节。然后将此八位组字符串与iPAddress类型的subjectAltName值进行比较。如果引用标识八位字节字符串和值八位字节字符串相同，则会发生匹配。
Client implementations MAY support matching against subjectAltName values of other types as described in other documents.
客户端实现可能支持与其他文档中描述的其他类型的subjectAltName值进行匹配。
The client sends the LOGOUT command when it is finished with a connection and wishes to terminate it. The server MUST reply with an OK response. The server MUST ignore commands issued by the client after the LOGOUT command.
客户端在完成连接并希望终止连接时发送注销命令。服务器必须以OK响应进行回复。服务器必须忽略注销命令后客户端发出的命令。
The client SHOULD wait for the OK response before closing the connection. This avoids the TCP connection going into the TIME_WAIT state on the server. In order to avoid going into the TIME_WAIT TCP state, the server MAY wait for a short while for the client to close the TCP connection first. Whether or not the server waits for the client to close the connection, it MUST then close the connection itself.
客户端应在关闭连接之前等待OK响应。这避免了TCP连接在服务器上进入TIME_WAIT状态。为了避免进入TIME_WAIT TCP状态，服务器可能会等待一小段时间，让客户端先关闭TCP连接。无论服务器是否等待客户端关闭连接，它都必须关闭连接本身。
Example:
例子：
C: Logout
S: Ok
<connection is terminated>
C: Logout
S: Ok
<connection is terminated>
The CAPABILITY command requests the server capabilities as described earlier in this document. It has no parameters.
CAPABILITY命令请求本文档前面所述的服务器功能。它没有参数。
Example:
例子：
C: CAPABILITY
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
C: CAPABILITY
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "VERSION" "1.0"
S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
S: "SIEVE" "fileinto vacation"
S: "STARTTLS"
S: OK
Arguments: String - name Number - script size
参数：字符串-名称编号-脚本大小
The HAVESPACE command is used to query the server for available space. Clients specify the name they wish to save the script as and its size in octets. Both parameters can be used by the server to see if the script with the specified name and size is within a user's quota(s). For example, the server MAY use the script name to check if a script would be replaced or a new one would be created. Servers respond with a NO if storing a script with that name and size would
HAVESPACE命令用于查询服务器的可用空间。客户端指定希望将脚本另存为的名称及其大小（以八位字节为单位）。服务器可以使用这两个参数来查看具有指定名称和大小的脚本是否在用户配额内。例如，服务器可能会使用脚本名称来检查是否要替换脚本或是否要创建新脚本。如果存储具有该名称和大小的脚本会
fail or OK otherwise. Clients SHOULD issue this command before attempting to place a script on the server.
否则失败或正常。客户端应在尝试在服务器上放置脚本之前发出此命令。
Note that the OK response from the HAVESPACE command does not constitute a guarantee of success as server disk space conditions could change between the client issuing the HAVESPACE and the client issuing the PUTSCRIPT commands. A QUOTA response code (see Section 1.3) remains a possible (albeit unlikely) response to a subsequent PUTSCRIPT with the same name and size.
请注意，HAVESPACE命令的OK响应并不构成成功的保证，因为发出HAVESPACE命令的客户端和发出PUTSCRIPT命令的客户端之间的服务器磁盘空间条件可能会发生变化。配额响应代码（见第1.3节）仍然是对具有相同名称和大小的后续PUTSCRIPT的可能（尽管不太可能）响应。
Example:
例子：
C: HAVESPACE "myscript" 999999
S: NO (QUOTA/MAXSIZE) "Quota exceeded"
C: HAVESPACE "myscript" 999999
S: NO (QUOTA/MAXSIZE) "Quota exceeded"
C: HAVESPACE "foobar" 435
S: OK
C: HAVESPACE "foobar" 435
S: OK
Arguments: String - Script name String - Script content
参数：字符串-脚本名称字符串-脚本内容
The PUTSCRIPT command is used by the client to submit a Sieve script to the server.
客户端使用PUTSCRIPT命令向服务器提交筛选脚本。
If the script already exists, upon success the old script will be overwritten. The old script MUST NOT be overwritten if PUTSCRIPT fails in any way. A script of zero length SHOULD be disallowed.
如果脚本已存在，则成功后将覆盖旧脚本。如果PUTSCRIPT以任何方式失败，则不得覆盖旧脚本。不允许使用长度为零的脚本。
This command places the script on the server. It does not affect whether the script is processed on incoming mail, unless it replaces the script that is already active. The SETACTIVE command is used to mark a script as active.
此命令将脚本放置在服务器上。它不影响是否在接收邮件时处理脚本，除非它替换已处于活动状态的脚本。SETACTIVE命令用于将脚本标记为活动。
When submitting large scripts, clients SHOULD use the HAVESPACE command beforehand to query if the server is willing to accept a script of that size.
提交大型脚本时，客户机应事先使用HAVESPACE命令查询服务器是否愿意接受该大小的脚本。
The server MUST check the submitted script for validity, which includes checking that the script complies with the Sieve grammar [SIEVE] and that all Sieve extensions mentioned in the script's "require" statement(s) are supported by the Sieve interpreter. (Note that if the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], any unrecognized/unsupported extension mentioned in the "ihave" test MUST NOT cause the validation failure.) Other checks such as validating the supplied command arguments for each command MAY be performed. Essentially, the performed validation SHOULD be
服务器必须检查提交的脚本的有效性，包括检查脚本是否符合筛语法[SIVE]，以及脚本的“require”语句中提到的所有筛扩展是否受筛解释器支持。（注意，如果Sieve解释器支持Sieve“ihave”扩展[I-HAVE]，则“ihave”测试中提到的任何未识别/不支持的扩展不得导致验证失败。）可以执行其他检查，例如验证每个命令的提供命令参数。本质上，执行的验证应该是
the same as performed when compiling the script for execution. Implementations that use a binary representation to store compiled scripts can extend the validation to a full compilation, in order to avoid validating uploaded scripts multiple times.
与编译脚本以执行时执行的相同。使用二进制表示来存储已编译脚本的实现可以将验证扩展到完整编译，以避免多次验证上载的脚本。
If the script fails the validation, the server MUST reply with a NO response. Any script that fails the validity test MUST NOT be stored on the server. The message given with a NO response MUST be human readable and SHOULD contain a specific error message giving the line number of the first error. Implementors should strive to produce helpful error messages similar to those given by programming language compilers. Client implementations should note that this may be a multiline literal string with more than one error message separated by CRLFs. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8].
如果脚本未通过验证，服务器必须以无响应的方式进行响应。任何未通过有效性测试的脚本都不得存储在服务器上。没有响应的消息必须是可读的，并且应该包含给出第一个错误行号的特定错误消息。实现者应该努力产生有用的错误消息，类似于编程语言编译器给出的错误消息。客户机实现应该注意，这可能是一个多行文字字符串，其中有多条错误消息由CRLFs分隔。人类可读消息使用最新语言功能（或“i-default”；见第1.7节）返回的语言，以UTF-8[UTF-8]编码。
An OK response MAY contain the WARNINGS response code. In such a case the human-readable message that follows the OK response SHOULD contain a specific warning message (or messages) giving the line number(s) in the script that might contain errors not intended by the script writer. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a response code SHOULD present the message to the user.
正常响应可能包含警告响应代码。在这种情况下，OK响应之后的人类可读消息应包含一条或多条特定的警告消息，给出脚本中可能包含脚本编写器不希望出现的错误的行号。人类可读消息使用最新语言功能（或“i-default”；见第1.7节）返回的语言，以UTF-8[UTF-8]编码。看到这样的响应代码的客户机应该向用户呈现消息。
Examples:
示例：
C: Putscript "foo" {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
C: Putscript "foo" {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
C: Putscript "mysievescript" {110+}
C: require ["fileinto"];
C:
C: if envelope :contains "to" "tmartin+sent" {
C: fileinto "INBOX.sent";
C: }
S: OK
C: Putscript "mysievescript" {110+}
C: require ["fileinto"];
C:
C: if envelope :contains "to" "tmartin+sent" {
C: fileinto "INBOX.sent";
C: }
S: OK
C: Putscript "myforwards" {190+}
C: redirect "111@example.net";
C:
C: if size :under 10k {
C: redirect "mobile@cell.example.com";
C: }
C:
C: if envelope :contains "to" "tmartin+lists" {
C: redirect "lists@groups.example.com";
C: }
S: OK (WARNINGS) "line 8: server redirect action
limit is 2, this redirect might be ignored"
C: Putscript "myforwards" {190+}
C: redirect "111@example.net";
C:
C: if size :under 10k {
C: redirect "mobile@cell.example.com";
C: }
C:
C: if envelope :contains "to" "tmartin+lists" {
C: redirect "lists@groups.example.com";
C: }
S: OK (WARNINGS) "line 8: server redirect action
limit is 2, this redirect might be ignored"
This command lists the scripts the user has on the server. Upon success, a list of CRLF-separated script names (each represented as a quoted or literal string) is returned followed by an OK response. If there exists an active script, the atom ACTIVE is appended to the corresponding script name. The atom ACTIVE MUST NOT appear on more than one response line.
此命令列出用户在服务器上拥有的脚本。成功后，返回一个由CRLF分隔的脚本名称列表（每个名称表示为引号或文字字符串），然后返回OK响应。如果存在活动脚本，则会将atom active附加到相应的脚本名称中。激活的原子不能出现在多个响应行上。
Example:
例子：
C: Listscripts
S: "summer_script"
S: "vacation_script"
S: {13}
S: clever"script
S: "main_script" ACTIVE
S: OK
C: Listscripts
S: "summer_script"
S: "vacation_script"
S: {13}
S: clever"script
S: "main_script" ACTIVE
S: OK
C: listscripts
S: "summer_script"
S: "main_script" active
S: OK
C: listscripts
S: "summer_script"
S: "main_script" active
S: OK
Arguments: String - script name
参数：字符串-脚本名称
This command sets a script active. If the script name is the empty string (i.e., ""), then any active script is disabled. Disabling an active script when there is no script active is not an error and MUST result in an OK reply.
此命令将脚本设置为活动状态。如果脚本名称为空字符串（即“”），则禁用任何活动脚本。在没有活动脚本的情况下禁用活动脚本不是错误，必须得到“确定”回复。
If the script does not exist on the server, then the server MUST reply with a NO response. Such a reply SHOULD contain the NONEXISTENT response code.
如果服务器上不存在脚本，则服务器必须以无响应的方式进行响应。这样的回复应该包含不存在的响应代码。
Examples:
示例：
C: Setactive "vacationscript"
S: Ok
C: Setactive "vacationscript"
S: Ok
C: Setactive ""
S: Ok
C: Setactive ""
S: Ok
C: Setactive "baz"
S: No (NONEXISTENT) "There is no script by that name"
C: Setactive "baz"
S: No (NONEXISTENT) "There is no script by that name"
C: Setactive "baz"
S: No (NONEXISTENT) {31}
S: There is no script by that name
C: Setactive "baz"
S: No (NONEXISTENT) {31}
S: There is no script by that name
Arguments: String - script name
参数：字符串-脚本名称
This command gets the contents of the specified script. If the script does not exist, the server MUST reply with a NO response. Such a reply SHOULD contain the NONEXISTENT response code.
此命令获取指定脚本的内容。如果脚本不存在，服务器必须以无响应的方式进行响应。这样的回复应该包含不存在的响应代码。
Upon success, a string with the contents of the script is returned followed by an OK response.
成功后，返回一个包含脚本内容的字符串，后跟一个OK响应。
Example:
例子：
C: Getscript "myscript"
S: {54}
S: #this is my wonderful script
S: reject "I reject all";
S:
S: OK
C: Getscript "myscript"
S: {54}
S: #this is my wonderful script
S: reject "I reject all";
S:
S: OK
Arguments: String - script name
参数：字符串-脚本名称
This command is used to delete a user's Sieve script. Servers MUST reply with a NO response if the script does not exist. Such responses SHOULD include the NONEXISTENT response code.
此命令用于删除用户的筛选脚本。如果脚本不存在，服务器必须以无响应的方式进行响应。此类响应应包括不存在的响应代码。
The server MUST NOT allow the client to delete an active script, so the server MUST reply with a NO response if attempted. Such a response SHOULD contain the ACTIVE response code. If a client wishes to delete an active script, it should use the SETACTIVE command to disable the script first.
服务器不得允许客户端删除活动脚本，因此如果尝试，服务器必须以无响应的方式进行答复。此类响应应包含活动响应代码。如果客户端希望删除活动脚本，则应首先使用SETACTIVE命令禁用该脚本。
Example:
例子：
C: Deletescript "foo"
S: Ok
C: Deletescript "foo"
S: Ok
C: Deletescript "baz"
S: No (ACTIVE) "You may not delete an active script"
C: Deletescript "baz"
S: No (ACTIVE) "You may not delete an active script"
Arguments: String - Old Script name String - New Script name
参数：字符串-旧脚本名称字符串-新脚本名称
This command is used to rename a user's Sieve script. Servers MUST reply with a NO response if the old script does not exist (in which case the NONEXISTENT response code SHOULD be included), or a script with the new name already exists (in which case the ALREADYEXISTS response code SHOULD be included). Renaming the active script is allowed; the renamed script remains active.
此命令用于重命名用户的筛选脚本。如果旧脚本不存在（在这种情况下，应包括不存在的响应代码），或者具有新名称的脚本已经存在（在这种情况下，应包括ALREADYEXISTS响应代码），则服务器必须以无响应的方式进行响应。允许重命名活动脚本；重命名后的脚本仍处于活动状态。
Example:
例子：
C: Renamescript "foo" "bar"
S: Ok
C: Renamescript "foo" "bar"
S: Ok
C: Renamescript "baz" "bar"
S: No "bar already exists"
C: Renamescript "baz" "bar"
S: No "bar already exists"
If the server doesn't support the RENAMESCRIPT command, the client can emulate it by performing the following steps:
如果服务器不支持RENAMESCRIPT命令，则客户端可以通过执行以下步骤来模拟该命令：
1. List available scripts with LISTSCRIPTS. If the script with the new script name exists, then the client should ask the user whether to abort the operation, to replace the script (by issuing the DELETESCRIPT <newname> after that), or to choose a different name.
1. 使用LISTSCRIPTS列出可用的脚本。如果存在具有新脚本名称的脚本，则客户端应询问用户是中止操作、替换脚本（在该操作之后发出DELETESCRIPT<newname>），还是选择其他名称。
2. Download the old script with GETSCRIPT <oldname>.
2. 使用GETSCRIPT<oldname>下载旧脚本。
3. Upload the old script with the new name: PUTSCRIPT <newname>.
3. 使用新名称上载旧脚本：PUTSCRIPT<newname>。
4. If the old script was active (as reported by LISTSCRIPTS in step 1), then make the new script active: SETACTIVE <newname>.
4. 如果旧脚本处于活动状态（如步骤1中LISTSCRIPTS所报告），则将新脚本设置为活动状态：SETACTIVE<newname>。
5. Delete the old script: DELETESCRIPT <oldname>.
5. 删除旧脚本：DELETESCRIPT<oldname>。
Note that these steps don't describe how to handle various other error conditions (for example, NO response containing QUOTA response code in step 3). Error handling is left as an exercise for the reader.
请注意，这些步骤没有描述如何处理各种其他错误条件（例如，步骤3中没有包含配额响应代码的响应）。错误处理留给读者作为练习。
Arguments: String - Script content
参数：字符串-脚本内容
The CHECKSCRIPT command is used by the client to verify Sieve script validity without storing the script on the server.
客户端使用CHECKSCRIPT命令验证脚本的有效性，而无需将脚本存储在服务器上。
The server MUST check the submitted script for syntactic validity, which includes checking that all Sieve extensions mentioned in Sieve script "require" statement(s) are supported by the Sieve interpreter. (Note that if the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], any unrecognized/unsupported extension mentioned in the "ihave" test MUST NOT cause the syntactic validation failure.) If the script fails this test, the server MUST reply with a NO response. The message given with a NO response MUST be human readable and SHOULD contain a specific error message giving the line number of the first error. Implementors should strive to produce helpful error messages similar to those given by programming language compilers. Client implementations should note that this may be a multiline literal string with more than one error message separated by CRLFs. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8].
服务器必须检查提交的脚本的语法有效性，包括检查筛脚本“require”语句中提到的所有筛扩展是否受筛解释器支持。（请注意，如果Sieve解释器支持Sieve“ihave”扩展名[I-HAVE]，则“ihave”测试中提到的任何未识别/不支持的扩展名都不得导致语法验证失败。）如果脚本未能通过此测试，服务器必须以无响应进行回复。没有响应的消息必须是可读的，并且应该包含给出第一个错误行号的特定错误消息。实现者应该努力产生有用的错误消息，类似于编程语言编译器给出的错误消息。客户机实现应该注意，这可能是一个多行文字字符串，其中有多条错误消息由CRLFs分隔。人类可读消息使用最新语言功能（或“i-default”；见第1.7节）返回的语言，以UTF-8[UTF-8]编码。
Examples:
示例：
C: CheckScript {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
C: CheckScript {31+}
C: #comment
C: InvalidSieveCommand
C:
S: NO "line 2: Syntax error"
A ManageSieve server supporting this command MUST NOT check if the script will put the current user over its quota limit.
支持此命令的ManageSeeve服务器不得检查脚本是否会使当前用户超过其配额限制。
An OK response MAY contain the WARNINGS response code. In such a case, the human-readable message that follows the OK response SHOULD contain a specific warning message (or messages) giving the line number(s) in the script that might contain errors not intended by the script writer. The human-readable message is in the language returned in the latest LANGUAGE capability (or in "i-default"; see Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a response code SHOULD present the message to the user.
正常响应可能包含警告响应代码。在这种情况下，OK响应之后的人类可读消息应该包含一条或多条特定的警告消息，给出脚本中可能包含脚本编写器不希望出现的错误的行号。人类可读消息使用最新语言功能（或“i-default”；见第1.7节）返回的语言，以UTF-8[UTF-8]编码。看到这样的响应代码的客户机应该向用户呈现消息。
Arguments: String - tag to echo back (optional)
参数：字符串-要回显的标记（可选）
The NOOP command does nothing, beyond returning a response to the client. It may be used by clients for protocol re-synchronization or to reset any inactivity auto-logout timer on the server.
NOOP命令除了向客户端返回响应外，什么也不做。客户端可以使用它进行协议重新同步或重置服务器上的任何非活动自动注销计时器。
The response to the NOOP command is always OK, followed by the TAG response code together with the supplied string. If no string was supplied in the NOOP command, the TAG response code MUST NOT be included.
对NOOP命令的响应总是OK，后面是标记响应代码和提供的字符串。如果NOOP命令中未提供任何字符串，则不得包含标记响应代码。
Examples:
示例：
C: NOOP
S: OK "NOOP completed"
C: NOOP
S: OK "NOOP completed"
C: NOOP "STARTTLS-SYNC-42"
S: OK (TAG {16}
S: STARTTLS-SYNC-42) "Done"
C: NOOP "STARTTLS-SYNC-42"
S: OK (TAG {16}
S: STARTTLS-SYNC-42) "Done"
The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" capability with no parameters) defines a new UNAUTHENTICATE command, which allows a client to return the server to non-authenticated state. Support for this extension is RECOMMENDED.
UNAUTHENTICATE扩展（广告称为“UNAUTHENTICATE”功能，没有参数）定义了一个新的UNAUTHENTICATE命令，该命令允许客户端将服务器返回到未经身份验证的状态。建议支持此扩展。
The UNAUTHENTICATE command returns the server to the non-authenticated state. It doesn't affect any previously established TLS [TLS] or SASL (Section 2.1) security layer.
UNAUTHENTICATE命令将服务器返回到未经身份验证的状态。它不影响任何先前建立的TLS[TLS]或SASL（第2.1节）安全层。
The UNAUTHENTICATE command is only valid in authenticated state. If issued in a wrong state, the server MUST reject it with a NO response.
UNAUTHENTICATE命令仅在已验证状态下有效。如果在错误状态下发出，服务器必须拒绝它，并且没有响应。
The UNAUTHENTICATE command has no parameters.
UNAUTHENTICATE命令没有参数。
When issued in the authenticated state, the UNAUTHENTICATE command MUST NOT fail (i.e., it must never return anything other than OK or BYE).
在已验证状态下发出时，UNAUTHENTICATE命令不得失败（即，它不得返回OK或BYE以外的任何内容）。
URI scheme name: sieve
URI方案名称：sieve
Status: permanent
地位：永久
URI scheme syntax: Described using ABNF [ABNF]. Some ABNF productions not defined below are from [URI-GEN].
URI方案语法：使用ABNF[ABNF]描述。下面未定义的一些ABNF产品来自[URI-GEN]。
sieveurl = sieveurl-server / sieveurl-list-scripts / sieveurl-script
SIVEEURL=SIVEEURL服务器/SIVEEURL列表脚本/SIVEEURL脚本
sieveurl-server = "sieve://" authority
sieveurl-server = "sieve://" authority
sieveurl-list-scripts = "sieve://" authority ["/"]
sieveurl-list-scripts = "sieve://" authority ["/"]
sieveurl-script = "sieve://" authority "/"
[owner "/"] scriptname
sieveurl-script = "sieve://" authority "/"
[owner "/"] scriptname
authority = <defined in [URI-GEN]>
authority = <defined in [URI-GEN]>
owner = *ochar
;; %-encoded version of [SASL] authorization
;; identity (script owner) or "userid".
;;
;; Empty owner is used to reference
;; global scripts.
;;
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
owner = *ochar
;; %-encoded version of [SASL] authorization
;; identity (script owner) or "userid".
;;
;; Empty owner is used to reference
;; global scripts.
;;
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
scriptname = 1*ochar
;; %-encoded version of UTF-8 representation
;; of the script name.
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
scriptname = 1*ochar
;; %-encoded version of UTF-8 representation
;; of the script name.
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" must be %-encoded
;; as per rule specified in [URI-GEN].
ochar = unreserved / pct-encoded / sub-delims-sh /
":" / "@"
;; Same as [URI-GEN] 'pchar',
;; but without ";", "&" and "=".
ochar = unreserved / pct-encoded / sub-delims-sh /
":" / "@"
;; Same as [URI-GEN] 'pchar',
;; but without ";", "&" and "=".
unreserved = <defined in [URI-GEN]>
unreserved = <defined in [URI-GEN]>
pct-encoded = <defined in [URI-GEN]>
pct-encoded = <defined in [URI-GEN]>
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
URI scheme semantics:
URI方案语义：
A Sieve URL identifies a Sieve server or a Sieve script on a Sieve server. The latter form is associated with the application/sieve MIME type defined in [SIEVE]. There is no MIME type associated with the former form of Sieve URI.
筛URL标识筛服务器或筛服务器上的筛脚本。后一种形式与[筛]中定义的应用程序/筛MIME类型关联。没有与前一种形式的筛选URI关联的MIME类型。
The server form is used in the REFERRAL response code (see Section 1.3) in order to designate another server where the client should perform its operations.
服务器表单用于参考响应代码（参见第1.3节），以指定客户端应在其中执行其操作的另一台服务器。
The script form allows to retrieve (GETSCRIPT), update (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the named script; however, the most typical action would be to retrieve the script. If the script name is empty (omitted), the URI requests that the client lists available scripts using the LISTSCRIPTS command.
脚本表单允许检索（GETSCRIPT）、更新（PUTSCRIPT）、删除（DELETESCRIPT）或激活（SETACTIVE）命名脚本；但是，最典型的操作是检索脚本。如果脚本名称为空（省略），URI将请求客户端使用LISTSCRIPTS命令列出可用脚本。
Encoding considerations:
编码注意事项：
The script name and/or the owner, if present, is in UTF-8. Non-- US-ASCII UTF-8 octets MUST be percent-encoded as described in [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. Note that "&" and "?" are in this list in order to allow for future extensions.
脚本名称和/或所有者（如果存在）采用UTF-8格式。非-US-ASCII UTF-8八位字节必须按照[URI-GEN]中的说明进行百分比编码。US-ASCII字符，如“”（空格）、“；”、“&”、“=”、“/”和“？”，必须按照[URI-GEN]中的说明进行%编码。请注意，此列表中包含“&”和“？”，以便将来扩展。
Note that the empty owner (e.g., sieve://example.com//script) is different from the missing owner (e.g., sieve://example.com/script) and is reserved for referencing global scripts.
请注意，空所有者（例如。，sieve://example.com//script)与丢失的所有者不同（例如。，sieve://example.com/script)并保留用于引用全局脚本。
The user name (in the "authority" part), if present, is in UTF-8. Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in [URI-GEN].
用户名（在“授权”部分）如果存在，则为UTF-8格式。非美国ASCII UTF-8八位字节必须按照[URI-GEN]中的说明进行百分比编码。
Applications/protocols that use this URI scheme name: ManageSieve [RFC5804] clients and servers. Clients that can store user preferences in protocols such as [LDAP] or [ACAP].
使用此URI方案名称的应用程序/协议：ManageSife[RFC5804]客户端和服务器。可以在[LDAP]或[ACAP]等协议中存储用户首选项的客户端。
Interoperability considerations: None.
互操作性考虑：无。
Security considerations: The <scriptname> part of a ManageSieve URL might potentially disclose some confidential information about the author of the script or, depending on a ManageSieve implementation, about configuration of the mail system. The latter might be used to prepare for a more complex attack on the mail system.
安全注意事项：ManageSeeve URL的<scriptname>部分可能会泄露有关脚本作者的一些机密信息，或者根据ManageSeeve实现，泄露有关邮件系统配置的一些机密信息。后者可能用于准备对邮件系统进行更复杂的攻击。
Clients resolving ManageSieve URLs that wish to achieve data confidentiality and/or integrity SHOULD use the STARTTLS command (if supported by the server) before starting authentication, or use a SASL mechanism, such as GSSAPI, that provides a confidentiality security layer.
希望实现数据机密性和/或完整性的ManageSeeve URL解析客户端应在启动身份验证之前使用STARTTLS命令（如果服务器支持），或使用提供机密性安全层的SASL机制，如GSSAPI。
Contact: Alexey Melnikov <alexey.melnikov@isode.com>
Contact: Alexey Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG.
作者/变更控制员：IESG。
References: This document and RFC 5228 [SIEVE].
参考文献：本文件和RFC 5228[SIFE]。
The following syntax specification uses the Augmented Backus-Naur Form (BNF) notation as specified in [ABNF]. This uses the ABNF core rules as specified in Appendix A of the ABNF specification [ABNF]. "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
以下语法规范使用[ABNF]中指定的增广巴科斯诺尔形式（BNF）表示法。这使用ABNF规范[ABNF]附录A中规定的ABNF核心规则。[UTF-8]中定义了“UTF8-2”、“UTF8-3”和“UTF8-4”非端子。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅用于编辑清晰性。实现必须以不区分大小写的方式接受这些字符串。
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
%x5D-7F
;; any TEXT-CHAR except QUOTED-SPECIALS
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
%x5D-7F
;; any TEXT-CHAR except QUOTED-SPECIALS
QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
QUOTED-CHAR=SAFE-UTF8-CHAR/“\”QUOTED-SPECIALS
QUOTED-SPECIALS = DQUOTE / "\"
QUOTED-SPECIALS=DQUOTE/“\”
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 ;; <UTF8-2>, <UTF8-3>, and <UTF8-4> ;; are defined in [UTF-8].
SAFE-UTF8-CHAR=SAFE-CHAR/UTF8-2/UTF8-3/UTF8-4<UTF8-2>、<UTF8-3>和<UTF8-4>；；定义见[UTF-8]。
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
;; Any CHAR except ATOM-SPECIALS
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
;; Any CHAR except ATOM-SPECIALS
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
NZDIGIT = %x31-39
;; 1-9
NZDIGIT = %x31-39
;; 1-9
atom = 1*1024ATOM-CHAR
atom = 1*1024ATOM-CHAR
iana-token = atom ;; MUST be registered with IANA
iana令牌=原子；；必须在IANA注册
auth-type = DQUOTE auth-type-name DQUOTE
auth-type = DQUOTE auth-type-name DQUOTE
auth-type-name = iana-token ;; as defined in SASL [SASL]
身份验证类型名称=iana令牌；；根据SASL[SASL]中的定义
command = (command-any / command-auth /
command-nonauth) CRLF
;; Modal based on state
command = (command-any / command-auth /
command-nonauth) CRLF
;; Modal based on state
command-any = command-capability / command-logout /
command-noop
;; Valid in all states
command-any = command-capability / command-logout /
command-noop
;; Valid in all states
command-auth = command-getscript / command-setactive /
command-listscripts / command-deletescript /
command-putscript / command-checkscript /
command-havespace /
command-renamescript /
command-unauthenticate
;; Valid only in Authenticated state
command-auth = command-getscript / command-setactive /
command-listscripts / command-deletescript /
command-putscript / command-checkscript /
command-havespace /
command-renamescript /
command-unauthenticate
;; Valid only in Authenticated state
command-nonauth = command-authenticate / command-starttls
;; Valid only when in Non-Authenticated
;; state
command-nonauth = command-authenticate / command-starttls
;; Valid only when in Non-Authenticated
;; state
command-authenticate = "AUTHENTICATE" SP auth-type [SP string] *(CRLF string)
命令authenticate=“authenticate”SP身份验证类型[SP字符串]*（CRLF字符串）
command-capability = "CAPABILITY"
command-capability = "CAPABILITY"
command-deletescript = "DELETESCRIPT" SP sieve-name
命令deletescript=“deletescript”SP筛名称
command-getscript = "GETSCRIPT" SP sieve-name
命令getscript=“getscript”SP筛名称
command-havespace = "HAVESPACE" SP sieve-name SP number
命令havespace=“havespace”SP筛名称SP编号
command-listscripts = "LISTSCRIPTS"
command-listscripts = "LISTSCRIPTS"
command-noop = "NOOP" [SP string]
命令noop=“noop”[SP string]
command-logout = "LOGOUT"
command-logout = "LOGOUT"
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
命令putscript=“putscript”SP sieve name SP sieve script
command-checkscript = "CHECKSCRIPT" SP sieve-script
命令checkscript=“checkscript”SP筛选脚本
sieve-script = string
sieve-script = string
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP new-sieve-name
命令renamescript=“renamescript”SP旧筛名称SP新筛名称
old-sieve-name = sieve-name
old-sieve-name = sieve-name
new-sieve-name = sieve-name
new-sieve-name = sieve-name
command-setactive = "SETACTIVE" SP active-sieve-name
命令setactive=“setactive”SP活动筛名称
command-starttls = "STARTTLS"
command-starttls = "STARTTLS"
command-unauthenticate= "UNAUTHENTICATE"
命令unauthenticate=“unauthenticate”
extend-token = atom
;; MUST be defined by a Standards Track or
;; IESG-approved experimental protocol
;; extension
extend-token = atom
;; MUST be defined by a Standards Track or
;; IESG-approved experimental protocol
;; extension
extension-data = extension-item *(SP extension-item)
扩展数据=扩展项*（SP扩展项）
extension-item = extend-token / string / number /
"(" [extension-data] ")"
extension-item = extend-token / string / number /
"(" [extension-data] ")"
literal-c2s = "{" number "+}" CRLF *OCTET
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the client to the server.
literal-c2s = "{" number "+}" CRLF *OCTET
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the client to the server.
literal-s2c = "{" number "}" CRLF *OCTET
;; Almost identical to literal-c2s,
;; but with no '+' character.
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the server to the client.
literal-s2c = "{" number "}" CRLF *OCTET
;; Almost identical to literal-c2s,
;; but with no '+' character.
;; The number represents the number of
;; octets.
;; This type of literal can only be sent
;; from the server to the client.
number = (NZDIGIT *DIGIT) / "0"
;; A 32-bit unsigned number
;; with no extra leading zeros.
;; (0 <= n < 4,294,967,296)
number = (NZDIGIT *DIGIT) / "0"
;; A 32-bit unsigned number
;; with no extra leading zeros.
;; (0 <= n < 4,294,967,296)
number-str = string ;; <number> encoded as a <string>.
数字str=string<编号>编码为<string>。
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
;; limited to 1024 octets between the <">s
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
;; limited to 1024 octets between the <">s
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
["/" ("MAXSCRIPTS" / "MAXSIZE")] /
resp-code-sasl /
resp-code-referral /
"TRANSITION-NEEDED" / "TRYLATER" /
"ACTIVE" / "NONEXISTENT" /
"ALREADYEXISTS" / "WARNINGS" /
"TAG" SP string /
resp-code-ext
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
["/" ("MAXSCRIPTS" / "MAXSIZE")] /
resp-code-sasl /
resp-code-referral /
"TRANSITION-NEEDED" / "TRYLATER" /
"ACTIVE" / "NONEXISTENT" /
"ALREADYEXISTS" / "WARNINGS" /
"TAG" SP string /
resp-code-ext
resp-code-referral = "REFERRAL" SP sieveurl
resp code referral=“referral”SP SIVEEURL
resp-code-sasl = "SASL" SP string
响应代码sasl=“sasl”SP字符串
resp-code-name = iana-token
;; The response code name is hierarchical,
;; separated by '/'.
;; The response code name MUST NOT start
;; with '/'.
resp-code-name = iana-token
;; The response code name is hierarchical,
;; separated by '/'.
;; The response code name MUST NOT start
;; with '/'.
resp-code-ext = resp-code-name [SP extension-data] ;; unknown response codes MUST be tolerated ;; by the client.
resp code ext=resp代码名称[SP扩展数据]；；必须容忍未知响应代码；；由客户提供。
response = response-authenticate / response-logout / response-getscript / response-setactive / response-listscripts / response-deletescript / response-putscript / response-checkscript / response-capability / response-havespace / response-starttls / response-renamescript / response-noop /
响应=响应身份验证/响应注销/响应getscript/response setactive/response ListScript/response deletescript/response putscript/response checkscript/response capability/response havespace/response starttls/response renamescript/response noop/
response-unauthenticate
未经验证的响应
response-authenticate = *(string CRLF)
((response-ok [response-capability]) /
response-nobye)
;; <response-capability> is REQUIRED if a
;; SASL security layer was negotiated and
;; MUST be omitted otherwise.
response-authenticate = *(string CRLF)
((response-ok [response-capability]) /
response-nobye)
;; <response-capability> is REQUIRED if a
;; SASL security layer was negotiated and
;; MUST be omitted otherwise.
response-capability = *(single-capability) response-oknobye
response-capability = *(single-capability) response-oknobye
single-capability = capability-name [SP string] CRLF
单个功能=功能名称[SP字符串]CRLF
capability-name = string
capability-name = string
;; Note that literal-s2c is allowed.
;; 请注意，允许使用literal-s2c。
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
DQUOTE "SASL" DQUOTE SP sasl-mechs /
DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language /
DQUOTE "VERSION" DQUOTE SP version /
DQUOTE "OWNER" DQUOTE SP string
;; Each capability conforms to
;; the syntax for single-capability.
;; Also, note that the capability name
;; can be returned as either literal-s2c
;; or quoted, even though only "quoted"
;; string is shown above.
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
DQUOTE "SASL" DQUOTE SP sasl-mechs /
DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language /
DQUOTE "VERSION" DQUOTE SP version /
DQUOTE "OWNER" DQUOTE SP string
;; Each capability conforms to
;; the syntax for single-capability.
;; Also, note that the capability name
;; can be returned as either literal-s2c
;; or quoted, even though only "quoted"
;; string is shown above.
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
version-ext = DQUOTE ver-major "." ver-minor DQUOTE
; Future versions specified in updates
; to this document. An increment to
; the ver-major means a backward-incompatible
; change to the protocol, e.g., "3.5" (ver-major "3")
; is not backward-compatible with any "2.X" version.
; Any version "Z.W" MUST be backward compatible
; with any version "Z.Q", where Q < W.
; For example, version "2.4" is backward compatible
; with version "2.0", "2.1", "2.2", and "2.3".
version-ext = DQUOTE ver-major "." ver-minor DQUOTE
; Future versions specified in updates
; to this document. An increment to
; the ver-major means a backward-incompatible
; change to the protocol, e.g., "3.5" (ver-major "3")
; is not backward-compatible with any "2.X" version.
; Any version "Z.W" MUST be backward compatible
; with any version "Z.Q", where Q < W.
; For example, version "2.4" is backward compatible
; with version "2.0", "2.1", "2.2", and "2.3".
ver-major = number
ver-major = number
ver-minor = number
ver-minor = number
sasl-mechs = string
; Space-separated list of SASL mechanisms,
; each SASL mechanism name complies with rules
; specified in [SASL].
; Can be empty.
sasl-mechs = string
; Space-separated list of SASL mechanisms,
; each SASL mechanism name complies with rules
; specified in [SASL].
; Can be empty.
sieve-extensions = string ; Space-separated list of supported SIEVE extensions. ; Can be empty.
筛孔延伸=管柱；支持的筛网扩展的空间分隔列表；可以是空的。
language = string ; Contains <Language-Tag> from [RFC5646].
语言=字符串；包含[RFC5646]中的<Language Tag>。
notify-mechs = string
; Space-separated list of URI schema parts
; for supported notification [NOTIFY] methods.
; MUST NOT be empty.
notify-mechs = string
; Space-separated list of URI schema parts
; for supported notification [NOTIFY] methods.
; MUST NOT be empty.
response-deletescript = response-oknobye
response-deletescript = response-oknobye
response-getscript = (sieve-script CRLF response-ok) /
response-nobye
response-getscript = (sieve-script CRLF response-ok) /
response-nobye
response-havespace = response-oknobye
response-havespace = response-oknobye
response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
response-oknobye
;; ACTIVE may only occur with one sieve-name
response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
response-oknobye
;; ACTIVE may only occur with one sieve-name
response-logout = response-oknobye
response-logout = response-oknobye
response-unauthenticate= response-oknobye
;; "NO" response can only be returned when
;; the command is issued in a wrong state
;; or has a wrong number of parameters
response-unauthenticate= response-oknobye
;; "NO" response can only be returned when
;; the command is issued in a wrong state
;; or has a wrong number of parameters
response-ok = "OK" [SP "(" resp-code ")"] [SP string] CRLF ;; The string contains human-readable text ;; encoded as UTF-8.
响应ok=“ok”[SP”（“响应代码”）][SP字符串]CRLF；；字符串包含人类可读的文本；；编码为UTF-8。
response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
[SP string] CRLF
;; The string contains human-readable text
;; encoded as UTF-8.
response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
[SP string] CRLF
;; The string contains human-readable text
;; encoded as UTF-8.
response-oknobye = response-ok / response-nobye
response-oknobye = response-ok / response-nobye
response-noop = response-ok
response-noop = response-ok
response-putscript = response-oknobye
response-putscript = response-oknobye
response-checkscript = response-oknobye
response-checkscript = response-oknobye
response-renamescript = response-oknobye
response-renamescript = response-oknobye
response-setactive = response-oknobye
response-setactive = response-oknobye
response-starttls = (response-ok response-capability) /
response-nobye
response-starttls = (response-ok response-capability) /
response-nobye
sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; Empty string is not allowed.
sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; Empty string is not allowed.
active-sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; This is similar to <sieve-name>, but
;; empty string is allowed and has a special
;; meaning.
active-sieve-name = string
;; See Section 1.6 for the full list of
;; prohibited characters.
;; This is similar to <sieve-name>, but
;; empty string is allowed and has a special
;; meaning.
string = quoted / literal-c2s / literal-s2c
;; literal-c2s is only allowed when sent
;; from the client to the server.
;; literal-s2c is only allowed when sent
;; from the server to the client.
;; quoted is allowed in either direction.
string = quoted / literal-c2s / literal-s2c
;; literal-c2s is only allowed when sent
;; from the client to the server.
;; literal-s2c is only allowed when sent
;; from the server to the client.
;; quoted is allowed in either direction.
The AUTHENTICATE command uses SASL [SASL] to provide authentication and authorization services. Integrity and privacy services can be provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the security considerations for that mechanism apply.
AUTHENTICATE命令使用SASL[SASL]提供身份验证和授权服务。完整性和隐私服务可由[SASL]和/或[TLS]提供。当使用SASL机制时，该机制的安全注意事项适用。
This protocol's transactions are susceptible to passive observers or man-in-the-middle attacks that alter the data, unless the optional encryption and integrity services of the SASL (via the AUTHENTICATE command) and/or [TLS] (via the STARTTLS command) are enabled, or an external security mechanism is used for protection. It may be useful to allow configuration of both clients and servers to refuse to transfer sensitive information in the absence of strong encryption.
此协议的事务容易受到被动观察者或中间人攻击的影响，从而改变数据，除非启用SASL（通过AUTHENTICATE命令）和/或[TLS]（通过STARTTLS命令）的可选加密和完整性服务，或者使用外部安全机制进行保护。允许客户端和服务器的配置在没有强加密的情况下拒绝传输敏感信息可能会很有用。
If an implementation supports SASL mechanisms that are vulnerable to passive eavesdropping attacks (such as [PLAIN]), then the implementation MUST support at least one configuration where these SASL mechanisms are not advertised or used without the presence of an external security layer such as [TLS].
如果一个实现支持易受被动窃听攻击的SASL机制（如[PLAIN]），那么该实现必须支持至少一种配置，其中这些SASL机制在没有外部安全层（如[TLS]）的情况下不会公布或使用。
Some response codes returned on failed AUTHENTICATE command may disclose whether or not the username is valid (e.g., TRANSITION-NEEDED), so server implementations SHOULD provide the ability to disable these features (or make them not conditional on a per-user basis) for sites concerned about such disclosure. In the case of ENCRYPT-NEEDED, if it is applied to all identities then no extra information is disclosed, but if it is applied on a per-user basis it can disclose information.
失败的AUTHENTICATE命令返回的一些响应代码可能会泄露用户名是否有效（例如，需要转换），因此服务器实现应该能够为关注此类泄露的站点禁用这些功能（或使其不受每个用户的限制）。在需要加密的情况下，如果加密应用于所有身份，则不会披露额外信息，但如果加密应用于每个用户，则可以披露信息。
A compromised or malicious server can use the TRANSITION-NEEDED response code to force the client that is configured to use a mechanism that does not disclose the user's password to the server (e.g., Kerberos), to send the bare password to the server. Clients SHOULD have the ability to disable the password transition feature, or disclose that risk to the user and offer the user an option of how to proceed.
受损或恶意服务器可以使用转换所需的响应代码强制配置为使用不向服务器透露用户密码的机制（例如Kerberos）的客户端向服务器发送裸密码。客户端应该能够禁用密码转换功能，或者向用户披露该风险，并为用户提供如何继续的选项。
IANA has reserved TCP port number 4190 for use with the ManageSieve protocol described in this document.
IANA已保留TCP端口号4190，以便与本文档中描述的ManageSeeve协议一起使用。
IANA has registered the "sieve" URI scheme defined in Section 3 of this document.
IANA已注册了本文件第3节中定义的“筛选”URI方案。
IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service Names" registry.
IANA已在“GSSAPI/Kerberos/SASL服务名称”注册表中注册了“sieve”。
IANA has created a new registry for ManageSieve capabilities. The registration template for ManageSieve capabilities is specified in Section 6.1. ManageSieve protocol capabilities MUST be specified in a Standards-Track or IESG-approved Experimental RFC.
IANA为ManageSeeve功能创建了一个新的注册表。第6.1节中规定了ManageSeeve功能的注册模板。ManageSeeve协议功能必须在标准跟踪或IESG批准的实验RFC中指定。
IANA has created a new registry for ManageSieve response codes. The registration template for ManageSieve response codes is specified in Section 6.3. ManageSieve protocol response codes MUST be specified in a Standards-Track or IESG-approved Experimental RFC.
IANA已经为ManageSeeve响应代码创建了一个新的注册表。第6.3节规定了ManageSeeve响应代码的注册模板。ManageSeeve协议响应代码必须在标准跟踪或IESG批准的实验RFC中指定。
To: iana@iana.org Subject: ManageSieve Capability Registration
致：iana@iana.org主题：管理能力注册
Please register the following ManageSieve capability:
请注册以下ManageSeeve功能：
Capability name: Description: Relevant publications: Person & email address to contact for further information: Author/Change controller:
能力名称：描述：相关出版物：联系人和电子邮件地址以获取更多信息：作者/变更控制员：
To: iana@iana.org Subject: ManageSieve Capability Registration
致：iana@iana.org主题：管理能力注册
Please register the following ManageSieve capabilities:
请注册以下ManageSeeve功能：
Capability name: IMPLEMENTATION Description: Its value contains the name of the server implementation and its version. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：实现描述：其值包含服务器实现的名称及其版本。相关出版物：本RFC，第1.7节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: SASL Description: Its value contains a space-separated list of SASL mechanisms supported by the server. Relevant publications: this RFC, Sections 1.7 and 2.1. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：SASL描述：其值包含服务器支持的SASL机制的空格分隔列表。相关出版物：本RFC第1.7节和第2.1节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: SIEVE Description: Its value contains a space-separated list of supported SIEVE extensions. Relevant publications: this RFC, Section 1.7. Also [SIEVE]. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：SIEVE Description：其值包含一个以空格分隔的受支持的SIEVE扩展列表。相关出版物：本RFC，第1.7节。也[筛]。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: STARTTLS Description: This capability is returned if the server supports TLS (STARTTLS command). Relevant publications: this RFC, Sections 1.7 and 2.2. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：STARTTLS说明：如果服务器支持TLS（STARTTLS命令），则返回此功能。相关出版物：本RFC第1.7节和第2.2节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: NOTIFY Description: This capability is returned if the server supports the 'enotify' [NOTIFY] Sieve extension. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：NOTIFY描述：如果服务器支持“enotify”[NOTIFY]筛扩展，则返回此功能。相关出版物：本RFC，第1.7节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: MAXREDIRECTS Description: This capability returns the limit on the number of Sieve "redirect" actions a script can perform during a single evaluation. The value is a non-negative number represented as a ManageSieve string. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：MAXREDIRECTS描述：此功能返回脚本在单个评估期间可以执行的筛选“重定向”操作的数量限制。该值是以ManageSeeve字符串表示的非负数。相关出版物：本RFC，第1.7节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: LANGUAGE Description: The language (<Language-Tag> from [RFC5646]) currently used for human-readable error messages. Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：语言描述：当前用于人类可读错误消息的语言（<LANGUAGE Tag>from[RFC5646]）。相关出版物：本RFC，第1.7节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: OWNER Description: Its value contains the UTF-8-encoded name of the currently logged-in user ("authorization identity" according to RFC 4422). Relevant publications: this RFC, Section 1.7. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
能力名称：所有者描述：其值包含当前登录用户的UTF-8编码名称（“根据RFC 4422的授权标识”）。相关出版物：本RFC，第1.7节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Capability name: VERSION Description: This capability is returned if the server is compliant with RFC 5804; i.e., that it supports RENAMESCRIPT, CHECKSCRIPT, and NOOP commands. Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13. Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
功能名称：版本描述：如果服务器符合RFC 5804，则返回此功能；i、 例如，它支持RENAMESCRIPT、CHECKSCRIPT和NOOP命令。相关出版物：本RFC，第2.11、2.12和2.13节。联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
To: iana@iana.org Subject: ManageSieve Response Code Registration
致：iana@iana.org主题：ManageSeeve响应代码注册
Please register the following ManageSieve response code:
请注册以下ManageSeeve响应代码：
Response Code: Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): Purpose: Published Specification(s): Person & email address to contact for further information: Author/Change controller:
响应代码：参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：用途：发布的规范：联系人和电子邮件地址以获取更多信息：作者/变更控制者：
To: iana@iana.org Subject: ManageSieve Response Code Registration
致：iana@iana.org主题：ManageSeeve响应代码注册
Please register the following ManageSieve response codes:
请注册以下ManageSeeve响应代码：
Response Code: AUTH-TOO-WEAK Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code is returned in the NO response from an AUTHENTICATE command. It indicates that site security policy forbids the use of the requested mechanism for the specified authentication identity. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：AUTH-TOO-WEAK参数（使用ABNF指定语法，如果无法指定，则使用“无”一词）：无目的：此响应代码在AUTHENTICATE命令的“无”响应中返回。它表示站点安全策略禁止对指定的身份验证标识使用请求的机制。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: ENCRYPT-NEEDED Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code is returned in the NO response from an AUTHENTICATE command. It indicates that site security policy requires the use of a strong encryption mechanism for the specified authentication identity and mechanism. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：ENCRYPT-REQUIRED参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：无目的：此响应代码在来自AUTHENTICATE命令的NO响应中返回。它表示站点安全策略要求对指定的身份验证标识和机制使用强加密机制。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: QUOTA Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined quota constraints. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：配额参数（使用ABNF指定语法，如果无法指定，则使用NONE）：无目的：如果此响应代码在NO/BYE响应中返回，则表示该命令将用户置于站点定义的配额约束之上。如果此响应代码在OK响应中返回，则可能表示用户接近其配额或用户超过其配额，但服务器支持软配额。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: QUOTA/MAXSCRIPTS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined limit on the number of Sieve scripts. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. This response code is a more specific version of the QUOTA response code. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：QUOTA/MAXSCRIPTS参数（使用ABNF指定语法，如果无法指定，则使用NONE）：无目的：如果在NO/BYE响应中返回此响应代码，则表示该命令将用户置于站点定义的筛选脚本数量限制之上。如果此响应代码在OK响应中返回，则可能表示用户接近其配额或用户超过其配额，但服务器支持软配额。此响应代码是配额响应代码的更具体版本。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: QUOTA/MAXSIZE Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: If this response code is returned in the NO/BYE response, it means that the command would have placed the user above the site-defined maximum script size. If this response code is returned in the OK response, it can mean that the user is near its quota or that the user exceeded its quota, but the server supports soft quotas. This response code is a more specific version of the QUOTA response code. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：QUOTA/MAXSIZE参数（使用ABNF指定语法，如果无法指定，则使用单词NONE）：无目的：如果在NO/BYE响应中返回此响应代码，则表示该命令将用户置于站点定义的最大脚本大小之上。如果此响应代码在OK响应中返回，则可能表示用户接近其配额或用户超过其配额，但服务器支持软配额。此响应代码是配额响应代码的更具体版本。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: REFERRAL Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): <sieveurl> Purpose: This response code may be returned with a BYE result from any command, and includes a mandatory parameter that indicates what server to access to manage this user's Sieve scripts. The server will be specified by a Sieve URL (see Section 3). The scriptname portion of the URL MUST NOT be specified. The client should authenticate to the specified server and use it for all further commands in the current session. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：引用参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：<SIVEEURL>目的：此响应代码可能会随任何命令的BYE结果一起返回，并包含一个强制参数，指示要访问哪个服务器来管理此用户的筛选脚本。服务器将由筛选URL指定（参见第3节）。不能指定URL的scriptname部分。客户端应向指定的服务器进行身份验证，并将其用于当前会话中的所有其他命令。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: SASL Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): <string> Purpose: This response code can occur in the OK response to a successful AUTHENTICATE command and includes the optional final server response data from the server as specified by [SASL]. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：SASL参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：<string>目的：此响应代码可以出现在对成功的身份验证命令的OK响应中，并包括由[SASL]指定的来自服务器的可选最终服务器响应数据。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: TRANSITION-NEEDED Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code occurs in a NO response of an AUTHENTICATE command. It indicates that the user name is valid, but the entry in the authentication database needs to be updated in order to permit authentication with the specified mechanism. This is typically done by establishing a secure channel using TLS, followed by authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：转换所需的参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：无目的：此响应代码出现在AUTHENTICATE命令的无响应中。它表示用户名有效，但需要更新身份验证数据库中的条目，以便允许使用指定的机制进行身份验证。这通常是通过使用TLS建立安全通道，然后使用[PLAIN]身份验证机制进行一次身份验证来完成的。然后，所选机制应可用于后续会话中的身份验证。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: TRYLATER Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed due to a temporary server failure. The client MAY continue using local information and try the command later. This response code only make sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：TRYLATER参数（使用ABNF指定语法，如果无法指定，则使用NONE一词）：无目的：由于临时服务器故障，命令失败。客户端可以继续使用本地信息，稍后重试该命令。此响应代码仅在以NO/BYE响应返回时才有意义。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: ACTIVE Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because it is not allowed on the active script, for example, DELETESCRIPT on the active script. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：活动参数（使用ABNF指定语法，如果无法指定，则使用“无”一词）：无目的：命令失败，因为它不允许在活动脚本上使用，例如，在活动脚本上使用DELETESCRIPT。此响应代码仅在以NO/BYE响应返回时才有意义。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: NONEXISTENT Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because the referenced script name doesn't exist. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：不存在参数（使用ABNF指定语法，如果无法指定，则使用“无”一词）：无目的：由于引用的脚本名称不存在，命令失败。此响应代码仅在以NO/BYE响应返回时才有意义。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: ALREADYEXISTS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: A command failed because the referenced script name already exists. This response code only makes sense when returned in a NO/BYE response. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：ALREADYEXISTS Arguments（使用ABNF指定语法，如果无法指定语法，则使用NONE）：无目的：由于引用的脚本名称已存在，因此命令失败。此响应代码仅在以NO/BYE响应返回时才有意义。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: WARNINGS Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): NONE Purpose: This response code MAY be returned by the server in the OK response (but it might be returned with the NO/ BYE response as well) and signals the client that even though the script is syntactically valid, it might contain errors not intended by the script writer. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：警告参数（使用ABNF指定语法，如果无法指定，则使用NONE）：无用途：服务器可能会在OK响应中返回此响应代码（但也可能与NO/BYE响应一起返回），并向客户端发出信号，表示即使脚本在语法上有效，它可能包含脚本编写器不希望出现的错误。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
Response Code: TAG Arguments (use ABNF to specify syntax, or the word NONE if none can be specified): string Purpose: This response code name is followed by a string specified in the command that caused this response. It is typically used for client state synchronization. Published Specification(s): [RFC5804] Person & email address to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com> Author/Change controller: IESG.
响应代码：标记参数（使用ABNF指定语法，如果无法指定，则使用“无”一词）：字符串用途：此响应代码名后面跟着导致此响应的命令中指定的字符串。它通常用于客户端状态同步。发布的规范：[RFC5804]联系人和电子邮件地址，以获取更多信息：Alexey Melnikov<Alexey。melnikov@isode.com>作者/变更控制员：IESG。
The LANGUAGE capability (see Section 1.7) allows a client to discover the current language used in all human-readable responses that might be returned at the end of any OK/NO/BYE response. Human-readable text in OK responses typically doesn't need to be shown to the user, unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT command that also contains the WARNINGS response code (Section 1.3). Human-readable text from NO/BYE responses is intended be shown to the user, unless the client can automatically handle failure of the command that caused such a response. Clients SHOULD use response codes (Section 1.3) for automatic error handling. Response codes MAY also be used by the client to present error messages in a language understood by the user, for example, if the LANGUAGE capability doesn't return a language understood by the user.
语言功能（见第1.7节）允许客户端发现所有人类可读响应中使用的当前语言，这些响应可能在任何OK/NO/BYE响应结束时返回。正常响应中的人类可读文本通常不需要向用户显示，除非它是在响应也包含警告响应代码的PUTSCRIPT或CHECKSCRIPT命令时返回的（第1.3节）。来自NO/BYE响应的人类可读文本旨在显示给用户，除非客户端能够自动处理导致此类响应的命令故障。客户应使用响应代码（第1.3节）进行自动错误处理。例如，如果语言功能没有返回用户理解的语言，客户端也可以使用响应代码以用户理解的语言显示错误消息。
Note that the human-readable text from OK (WARNINGS) or NO/BYE responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced users that understand Sieve language. Such advanced users are often sophisticated enough to be able to handle whatever language the server is using, even if it is not their preferred language, and will want to see error/warning text no matter what language the server puts it in.
请注意，PUTSCRIPT/CHECKSCRIPT命令的OK（警告）或NO/BYE响应中的可读文本适用于理解SIVE语言的高级用户。这些高级用户通常非常成熟，能够处理服务器使用的任何语言，即使它不是他们的首选语言，并且无论服务器使用何种语言，都希望看到错误/警告文本。
A client that generates Sieve script automatically, for example, if the script is generated without user intervention or from a UI that presents an abstract list of conditions and corresponding actions, SHOULD NOT present warning/error messages to the user, because the user might not even be aware that the client is using Sieve underneath. However, if the client has a debugging mode, such warnings/errors SHOULD be available in the debugging mode.
自动生成筛选脚本的客户端，例如，如果脚本是在没有用户干预的情况下生成的，或者是从显示条件和相应操作的抽象列表的UI生成的，则不应向用户显示警告/错误消息，因为用户甚至可能不知道客户端正在使用筛选。但是，如果客户端具有调试模式，则此类警告/错误应在调试模式下可用。
Note that this document doesn't provide a way to modify the currently used language. It is expected that a future extension will address that.
请注意，本文档不提供修改当前使用的语言的方法。预计今后的延期将解决这一问题。
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus Westerlund, Tim Polk, and Julien Coloos for help with this document. Special thank you to Phil Pennock for providing text for the NOOP command, as well as finding various bugs in the document.
感谢Simon Josefsson、Larry Greenfield、Allen Johnson、Chris Newman、Lyndon Nerenberg、Tim Showalter、Sarah Robeson、Walter Wong、Barry Leiba、Arnt Gulbrandsen、Stephan Bosch、Ken Murchison、Phil Pennock、Ned Freed、Jeffrey Hutzelman、Mark E.Mallett、Dilyan Palauzov、Dave Cridland、Aaron Stone、Robert Burrell Donkin、Patrick Ben Koetter、，Bjoern Hoehrmann、Martin Duerst、Pasi Eronen、Magnus Westerlund、Tim Polk和Julien Colos为本文档提供帮助。特别感谢Phil Pennock为NOOP命令提供文本，以及在文档中发现各种错误。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV]Gulbrandsen，A.，Vixie，P.，和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[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月。
[NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[NET-UNICODE]Klensin，J.和M.Padlipsky，“网络交换的UNICODE格式”，RFC 51982008年3月。
[NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[通知]Melnikov，A.，Leiba，B.，Segmuller，W.，和T.Martin，“筛选电子邮件过滤：通知扩展”，RFC 54352009年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519]Sciberras，A.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，2006年6月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga，K.，“SASLprep:Stringprep用户名和密码配置文件”，RFC 4013，2005年2月。
[SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[SCRAM]Menon Sen，A.，Melnikov，A.，Newman，C.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，2010年7月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.和T.Showalter，“筛：电子邮件过滤语言”，RFC 52282008年1月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep]Hoffman，P.和M.Blanchet，“国际化弦的准备（“StringPrep”）”，RFC 3454，2002年12月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI-GEN]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[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月。
[X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[X509]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[X509-SRV] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[X509-SRV]Santesson，S.，“互联网X.509公钥基础设施主体服务名称表达的备选名称”，RFC 4985，2007年8月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[GSSAPI]Melnikov，A.，“Kerberos V5（“GSSAPI”）简单身份验证和安全层（SASL）机制”，RFC 4752，2006年11月。
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", RFC 5463, March 2009.
[I-HAVE]Freed，N.，“筛选电子邮件过滤：Ihave扩展”，RFC 54632009年3月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[LDAP]Zeilenga，K.，“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[普通]Zeilenga，K.，“普通简单认证和安全层（SASL）机制”，RFC4616，2006年8月。
Authors' Addresses
作者地址
Alexey Melnikov (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov（编辑）Isode Limited 5城堡商业村英国米德尔塞克斯郡汉普顿车站路36号TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Tim Martin BeThereBeSquare, Inc. 672 Haight st. San Francisco, CA 94117 USA
Tim Martin BeThereBeSquare，公司672海特圣旧金山，CA 94117美国
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu