Network Working Group A. Melnikov, Ed.
Request for Comments: 5435 Isode Limited
Category: Standards Track B. Leiba, Ed.
W. Segmuller
IBM T.J. Watson Research Center
T. Martin
Endless Crossword
January 2009
Network Working Group A. Melnikov, Ed.
Request for Comments: 5435 Isode Limited
Category: Standards Track B. Leiba, Ed.
W. Segmuller
IBM T.J. Watson Research Center
T. Martin
Endless Crossword
January 2009
Sieve Email Filtering: Extension for Notifications
筛选电子邮件筛选：通知的扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent.
用户尽最大努力尽快收到新邮件的通知。大多数方法都涉及定期轮询以检查新消息。最终交付代理处理的推送方法为用户提供了更快的通知并节省了服务器资源。本文档未指定通知方法，但预计使用现有即时消息基础设施（如可扩展消息和状态协议（XMPP））或全球移动通信系统（GSM）短消息服务（SMS）消息将非常流行。本文档描述了对Sieve邮件过滤语言的一个扩展，该语言允许用户给出发送通知的方式和时间的特定规则。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Capability Identifier ...........................................3
3. Notify Action ...................................................3
3.1. Notify Action Syntax and Semantics .........................3
3.2. Notify Parameter "method" ..................................3
3.3. Notify Tag ":from" .........................................4
3.4. Notify Tag ":importance" ...................................4
3.5. Notify Tag ":options" ......................................5
3.6. Notify Tag ":message" ......................................5
3.7. Examples ...................................................6
3.8. Requirements on Notification Methods Specifications ........7
4. Test valid_notify_method ........................................8
5. Test notify_method_capability ...................................9
6. Modifier encodeurl to the 'set' Action .........................10
7. Interactions with Other Sieve Actions ..........................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................13
9.1. Registration of Sieve Extension ...........................13
9.2. New Registry for Sieve Notification Mechanisms ............14
9.3. New Registry for Notification-Capability Parameters .......14
10. Acknowledgements ..............................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Capability Identifier ...........................................3
3. Notify Action ...................................................3
3.1. Notify Action Syntax and Semantics .........................3
3.2. Notify Parameter "method" ..................................3
3.3. Notify Tag ":from" .........................................4
3.4. Notify Tag ":importance" ...................................4
3.5. Notify Tag ":options" ......................................5
3.6. Notify Tag ":message" ......................................5
3.7. Examples ...................................................6
3.8. Requirements on Notification Methods Specifications ........7
4. Test valid_notify_method ........................................8
5. Test notify_method_capability ...................................9
6. Modifier encodeurl to the 'set' Action .........................10
7. Interactions with Other Sieve Actions ..........................11
8. Security Considerations ........................................11
9. IANA Considerations ............................................13
9.1. Registration of Sieve Extension ...........................13
9.2. New Registry for Sieve Notification Mechanisms ............14
9.3. New Registry for Notification-Capability Parameters .......14
10. Acknowledgements ..............................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
This is an extension to the Sieve language defined by [Sieve] for providing instant notifications. It defines the new action "notify".
这是对[Sieve]定义的Sieve语言的扩展，用于提供即时通知。它定义了新操作“通知”。
This document does not specify the notification methods. Examples of possible notification methods are email and XMPP. To allow for the portability of scripts that use notifications, implementation of the [MailTo] method is mandatory. Other available methods shall depend upon the implementation and configuration of the system.
本文档未指定通知方法。可能的通知方法有电子邮件和XMPP。为了实现使用通知的脚本的可移植性，必须实现[MailTo]方法。其他可用方法应取决于系统的实施和配置。
Conventions for notations are as in [Sieve], Section 1.1, including the use of [ABNF].
符号惯例如第1.1节[SIVE]所述，包括[ABNF]的使用。
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 [Kwds].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[Kwds]中所述进行解释。
The capability string associated with the extension defined in this document is "enotify".
与本文档中定义的扩展相关联的功能字符串为“enotify”。
Usage: notify [":from" string]
[":importance" <"1" / "2" / "3">]
[":options" string-list]
[":message" string]
<method: string>
Usage: notify [":from" string]
[":importance" <"1" / "2" / "3">]
[":options" string-list]
[":message" string]
<method: string>
The "notify" action specifies that a notification should be sent to a user. The format of the notification is implementation-defined and is also affected by the notification method used (see Section 3.2). However, all content specified in the ":message" parameter SHOULD be included.
“通知”操作指定应向用户发送通知。通知的格式由实施定义，并受所用通知方法的影响（见第3.2节）。但是，应包括“：message”参数中指定的所有内容。
The "method" positional parameter identifies the notification method that will be used; it is a URI [URI]. For example, the notification method can be a tel URI [TEL-URI] with a phone number to send SMS messages to, or an XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI].
“方法”位置参数标识将使用的通知方法；它是一个URI[URI]。例如，通知方法可以是具有要向其发送SMS消息的电话号码的tel-URI[tel-URI]，或者包含XMPP标识符[XMPP-URI]的XMPP[XMPP]URI。
The supported URI values will be site-specific, but support for the [MailTo] method is REQUIRED in order to ensure interoperability. If a URI schema is specified that the implementation does not support, the notification MUST cause an error condition at run time. Sieve scripts can check the supported methods using the valid_notify_method test to be sure that they only use supported ones, to avoid such error conditions.
支持的URI值将是特定于站点的，但为了确保互操作性，需要支持[MailTo]方法。如果指定了实现不支持的URI架构，则通知必须在运行时导致错误情况。筛子脚本可以使用有效的方法测试来检查受支持的方法，以确保它们只使用受支持的方法，从而避免此类错误情况。
If the "method" parameter contains a supported URI schema, then the URI MUST be checked for syntactic validity. Invalid URI syntax or an unsupported URI extension MUST cause an error. An implementation MAY enforce other semantic restrictions on URIs -- for example, to restrict phone numbers in a tel: URI to a particular geographical region -- and will treat violations of such semantic restrictions as errors.
如果“method”参数包含受支持的URI模式，则必须检查URI的语法有效性。无效的URI语法或不受支持的URI扩展必须导致错误。一个实现可以对URI实施其他语义限制——例如，将tel:URI中的电话号码限制在特定的地理区域——并将违反此类语义限制视为错误。
A ":from" tag may be used to specify an author of the notification. The syntax of this parameter's value is method-specific. Implementations SHOULD check the syntax according to the notification method specification and generate an error when a syntactically invalid ":from" tag is specified.
“：from”标记可用于指定通知的作者。此参数值的语法是特定于方法的。实现应该根据通知方法规范检查语法，并在指定语法无效的“：from”标记时生成错误。
In order to minimize/prevent forgery of the author value, implementations SHOULD impose restrictions on what values can be specified in a ":from" tag. For example, an implementation may restrict this value to be a member of a list of known author addresses or to belong to a particular domain. It is suggested that values that don't satisfy such restrictions simply be ignored rather than causing the "notify" action to fail.
为了最小化/防止伪造作者值，实现应该对“：from”标记中可以指定的值施加限制。例如，实现可能会将此值限制为已知作者地址列表的成员或属于特定域。建议忽略不满足此类限制的值，而不是导致“notify”操作失败。
The ":importance" tag specifies the importance of quick delivery of the notification, as perceived by the Sieve script owner. The ":importance" tag is followed by a numeric value represented as a string: "1" (high importance), "2" (normal importance), and "3" (low importance). If no importance is given, the default value "2" SHOULD be assumed. A notification method MAY treat the importance value as a transport indicator. For example, it might deliver notifications of high importance quicker than notifications of normal or low importance. Some notification methods allow users to specify their state of activity (for example, "busy" or "away from keyboard"). If the notification method provides this information, it SHOULD be used to selectively send notifications. If, for example, the user marks
“：重要性”标记指定了脚本所有者认为的快速传递通知的重要性。“：重要性”标记后面是一个数字值，表示为字符串：“1”（高重要性）、“2”（正常重要性）和“3”（低重要性）。如果没有给出重要性，则应假定默认值“2”。通知方法可以将重要性值视为传输指标。例如，它可能会比正常或低重要性的通知更快地发送高重要性的通知。某些通知方法允许用户指定其活动状态（例如，“忙碌”或“远离键盘”）。如果通知方法提供此信息，则应使用它有选择地发送通知。例如，如果用户标记
herself as "busy", a notification method can require that a notification with importance of "3" is not to be sent; however, the user might be notified of a notification with higher importance.
作为“忙”，通知方法可以要求不发送重要性为“3”的通知；但是，可能会向用户通知具有更高重要性的通知。
If the notification method allows users to filter messages based upon certain parameters in the message, users SHOULD be able to filter based upon importance. If the notification method does not support importance, then this parameter MUST be ignored. An implementation MAY include the importance value in the default message, Section 3.6, if one is not provided.
如果通知方法允许用户根据消息中的某些参数筛选消息，则用户应该能够根据重要性进行筛选。如果通知方法不支持重要性，则必须忽略此参数。如果未提供重要性值，则实现可在默认消息第3.6节中包括重要性值。
The ":options" tag is used to send additional parameters to the notification method. Interpretation of the parameters is method-specific. This document doesn't specify any such additional parameter.
“：options”标记用于向通知方法发送附加参数。参数的解释是特定于方法的。本文档未指定任何此类附加参数。
Each string in the options string list has the following syntax: "<optionname>=<value>" where optionname has the following ABNF [ABNF]:
选项字符串列表中的每个字符串都具有以下语法：“<optionname>=<value>”，其中optionname具有以下ABNF[ABNF]：
l-d = ALPHA / DIGIT
l-d-p = l-d / "." / "-" / "_"
optionname = l-d *l-d-p
value = *(%x01-09 / %x0B-0C / %x0E-FF)
l-d = ALPHA / DIGIT
l-d-p = l-d / "." / "-" / "_"
optionname = l-d *l-d-p
value = *(%x01-09 / %x0B-0C / %x0E-FF)
The ":message" tag specifies the message data to be included in the notification. The entirety of the string SHOULD be sent, but implementations MAY shorten the message for technical or aesthetic reasons. If the ":message" parameter is absent, a default implementation-specific message is used. Unless otherwise specified by a particular notification mechanism, an implementation default containing at least the value of the "From" header field and the value of the "Subject" header field is RECOMMENDED.
“：message”标记指定要包含在通知中的消息数据。应该发送整个字符串，但由于技术或美学原因，实现可能会缩短消息。如果缺少“：message”参数，则使用默认的特定于实现的消息。除非特定通知机制另有规定，否则建议使用至少包含“From”头字段值和“Subject”头字段值的实现默认值。
In order to construct more complex messages, the notify extension can be used together with the Sieve variables extension [Variables], as shown in the examples below.
为了构造更复杂的消息，notify扩展可以与Sieve variables扩展[variables]一起使用，如下例所示。
Example 1: require ["enotify", "fileinto", "variables"];
示例1：要求[“enotify”、“fileinto”、“variables”]；
if header :contains "from" "boss@example.org" {
notify :importance "1"
:message "This is probably very important"
"mailto:alm@example.com";
# Don't send any further notifications
stop;
}
if header :contains "from" "boss@example.org" {
notify :importance "1"
:message "This is probably very important"
"mailto:alm@example.com";
# Don't send any further notifications
stop;
}
if header :contains "to" "sievemailinglist@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
if header :contains "to" "sievemailinglist@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the value of the From header
if header :matches "From" "*" {
set "from" "${1}";
}
# :matches is used to get the value of the From header
if header :matches "From" "*" {
set "from" "${1}";
}
notify :importance "3"
:message "[SIEVE] ${from}: ${subject}"
"mailto:alm@example.com";
fileinto "INBOX.sieve";
}
notify :importance "3"
:message "[SIEVE] ${from}: ${subject}"
"mailto:alm@example.com";
fileinto "INBOX.sieve";
}
Example 2: require ["enotify", "fileinto", "variables", "envelope"];
示例2：要求[“enotify”、“fileinto”、“variables”、“envelope”]；
if header :matches "from" "*@*.example.org" {
# :matches is used to get the MAIL FROM address
if envelope :all :matches "from" "*" {
set "env_from" " [really: ${1}]";
}
if header :matches "from" "*@*.example.org" {
# :matches is used to get the MAIL FROM address
if envelope :all :matches "from" "*" {
set "env_from" " [really: ${1}]";
}
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the address from the From header
if address :matches :all "from" "*" {
set "from_addr" "${1}";
}
# :matches is used to get the address from the From header
if address :matches :all "from" "*" {
set "from_addr" "${1}";
}
notify :message "${from_addr}${env_from}: ${subject}"
"mailto:alm@example.com";
}
notify :message "${from_addr}${env_from}: ${subject}"
"mailto:alm@example.com";
}
Example 3: require ["enotify", "variables"];
例3：要求[“enotify”，“variables”]；
set "notif_method"
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
set "notif_method"
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
if header :contains "subject" "Your dog" {
set "notif_method" "tel:+14085551212";
}
if header :contains "subject" "Your dog" {
set "notif_method" "tel:+14085551212";
}
if header :contains "to" "sievemailinglist@example.org" {
set "notif_method" "";
}
if header :contains "to" "sievemailinglist@example.org" {
set "notif_method" "";
}
if not string :is "${notif_method}" "" {
notify "${notif_method}";
}
if not string :is "${notif_method}" "" {
notify "${notif_method}";
}
if header :contains "from" "boss@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
if header :contains "from" "boss@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# don't need high importance notification for
# a 'for your information'
if not header :contains "subject" "FYI:" {
notify :importance "1" :message "BOSS: ${subject}"
"tel:+14085551212";
}
}
# don't need high importance notification for
# a 'for your information'
if not header :contains "subject" "FYI:" {
notify :importance "1" :message "BOSS: ${subject}"
"tel:+14085551212";
}
}
This section describes requirements for documents that define specific Sieve notification methods.
本节描述了定义特定筛分通知方法的文件要求。
Notification mechanisms MUST NOT add new Sieve tags to the "notify" action.
通知机制不得向“通知”操作添加新的筛选标记。
A notification method MAY allow modification of the final notification text -- for example, truncating it if it exceeds a length limit or modifying characters that can not be represented in the target character set. Characters in the notification text that
通知方法可能允许修改最终通知文本——例如，如果文本超过长度限制，则将其截断，或者修改无法在目标字符集中表示的字符。通知文本中
can't be represented by the notification method SHOULD be replaced with a symbol indicating an unknown character. Allowed modifications MUST be documented in the document describing the notification method.
通知方法无法表示，应替换为指示未知字符的符号。允许的修改必须记录在描述通知方法的文件中。
A notification method MAY ignore parameters specified in the "notify" action.
通知方法可以忽略“通知”操作中指定的参数。
A notification method MAY recommend the default message value to be used if the ":message" argument is not specified.
如果未指定“：message”参数，通知方法可能会建议使用默认消息值。
Notifications SHOULD include timestamps, if the notification method allows for their transmission outside of the textual message. Implementation methods that can only transmit timestamps in the textual message MAY include them in the textual message.
如果通知方法允许在文本消息之外传输通知，则通知应包括时间戳。只能在文本消息中传输时间戳的实现方法可以在文本消息中包含它们。
A notification MUST include means to identify/track its origin in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help with tracking a misconfigured or abusive origin of notifications.
通知必须包括识别/跟踪其来源的方法，以便允许收件人停止通知或了解如何联系发件人。此要求有助于跟踪错误配置或滥用的通知来源。
Methods SHOULD NOT include any other extraneous information not specified in parameters to the "notify" action.
方法不应包括“notify”操作的参数中未指定的任何其他无关信息。
Methods MUST specify which URI parameters (if any) must be ignored, which ones must be used in the resulting notification, and which ones must cause an error.
方法必须指定哪些URI参数（如果有）必须忽略，哪些参数必须在结果通知中使用，哪些参数必须导致错误。
Methods MUST specify what values are returned by the notify_method_capability test, Section 5, in particular for the "online" notification-capability.
方法必须指定notify_method_能力测试第5节返回的值，尤其是“在线”通知能力。
If there are errors sending the notification, the Sieve interpreter SHOULD ignore the notification and not retry indefinitely. The Sieve interpreter MAY throttle notifications; if it does, a request to send a notification MAY be silently ignored. Documents describing notification methods SHOULD describe how retries, throttling, duplicate suppression (if any), etc. are to be handled by implementations.
如果发送通知时出现错误，Sieve解释器应该忽略该通知，而不是无限期地重试。筛解释器可以限制通知；如果是这样，发送通知的请求可能会被静默忽略。描述通知方法的文档应该描述实现如何处理重试、节流、重复抑制（如果有）等。
Usage: valid_notify_method <notification-uris: string-list>
Usage: valid_notify_method <notification-uris: string-list>
The valid_notify_method test is true if the notification methods listed in the notification-uris argument are supported and they are valid both syntactically (including URI parameters) and semantically
如果支持notification URI参数中列出的通知方法，并且它们在语法（包括URI参数）和语义上都有效，则valid_notify_方法测试为true
(including implementation-specific semantic restrictions). This test MUST perform exactly the same validation as would be performed on the "method" parameter to the "notify" action.
（包括特定于实现的语义限制）。此测试必须执行与“notify”操作的“method”参数完全相同的验证。
The test is true only if ALL of the listed notification methods are supported and valid.
仅当所有列出的通知方法都受支持且有效时，测试才为真。
Example 4 (partial):
if not valid_notify_method ["mailto:",
"http://gw.example.net/notify?test"] {
stop;
}
Example 4 (partial):
if not valid_notify_method ["mailto:",
"http://gw.example.net/notify?test"] {
stop;
}
Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
<notification-uri: string>
<notification-capability: string>
<key-list: string-list>
Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
<notification-uri: string>
<notification-capability: string>
<key-list: string-list>
The notify_method_capability test retrieves the notification capability specified by the notification-capability string that is specific to the notification-uri and matches it to the values specified in the key-list. The test succeeds if a match occurs. The type of match defaults to ":is", and the default comparator is "i;ascii-casemap".
notify_method_capability测试检索特定于通知uri的通知功能字符串指定的通知功能，并将其与键列表中指定的值相匹配。如果出现匹配，测试将成功。匹配类型默认为“：is”，默认比较器为“i；ascii casemap”。
The notification-capability parameter is case insensitive.
notification capability参数不区分大小写。
The notify_method_capability test MUST fail unconditionally if the specified notification-uri is syntactically invalid (as determined by the valid_notify_method test, Section 4) or specifies an unsupported notification method. However this MUST NOT cause an error.
如果指定的通知uri在语法上无效（由有效的通知方法测试第4节确定）或指定了不受支持的通知方法，则通知方法能力测试必须无条件失败。但是，这不得导致错误。
The notify_method_capability test MUST fail unconditionally if the specified notification-capability item is not known to the Sieve interpreter. A script MUST NOT fail with an error if the item does not exist. This allows scripts to be written that handle nonexistent items gracefully.
如果指定的通知能力项不为SIVE解释器所知，则notify_method_能力测试必须无条件失败。如果项目不存在，则脚本不得因错误而失败。这允许编写优雅地处理不存在项的脚本。
This document defines a single notification-capability value "online", which is described below. Additional notification-capability values may be defined by using the procedure defined in Section 9.3.
本文档定义了一个“在线”通知功能值，如下所述。可使用第9.3节中定义的程序定义其他通知能力值。
The "relational" extension [Relational] adds a match type called ":count". The count of an notify_method_capability test is 0, if the returned information is the empty string, or 1.
“relational”扩展[relational]添加了一个名为“：count”的匹配类型。如果返回的信息是空字符串，则notify_method_能力测试的计数为0，或1。
For the "online" notification-capability, the notify_method_capability test can match one of the following key-list values:
对于“在线”通知功能，notify_method_功能测试可以匹配以下关键列表值之一：
o "yes" - the entity identified by the notification-uri can receive a notify notification immediately. Note that even after this value is returned, there is no guarantee that the entity would actually be able to receive any notification immediately or even receive it at all. Transport errors, recipient policy, etc. can prevent that.
o “是”-由通知uri标识的实体可以立即接收通知。请注意，即使返回此值，也不能保证实体能够立即收到任何通知，甚至根本无法收到通知。传输错误、收件人策略等可以防止这种情况发生。
o "no" - the entity identified by the notification-uri is not currently available to receive an immediate notification.
o “否”-通知uri标识的实体当前无法接收即时通知。
o "maybe" - the Sieve interpreter can't determine if the entity identified by the notification-uri is online or not.
o “可能”-Sieve解释器无法确定由通知uri标识的实体是否在线。
Example 5: require ["enotify"];
例5：要求[“enotify”]；
if notify_method_capability
"xmpp:tim@example.com?message;subject=SIEVE"
"Online"
"yes" {
notify :importance "1" :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
} else {
notify :message "You got mail" "tel:+14085551212";
}
if notify_method_capability
"xmpp:tim@example.com?message;subject=SIEVE"
"Online"
"yes" {
notify :importance "1" :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
} else {
notify :message "You got mail" "tel:+14085551212";
}
Usage: ":encodeurl"
用法：“：encodeurl”
When the Sieve script specifies both "variables" [Variables] and "enotify" capabilities in the "require", a new "set" action modifier (see [Variables]) ":encodeurl" becomes available to Sieve scripts. This modifier performs percent-encoding of any octet in the string that doesn't belong to the "unreserved" set (see [URI]). The percent-encoding procedure is described in [URI].
当Sieve脚本在“require”中同时指定“variables”[variables]和“enotify”功能时，一个新的“set”操作修饰符（请参见[variables]）“：encodeurl”将可用于Sieve脚本。此修饰符对字符串中不属于“未保留”集的任何八位字节执行百分比编码（请参见[URI]）。[URI]中描述了百分比编码过程。
The ":encodeurl" modifier has precedence 15.
“：encodeurl”修饰符的优先级为15。
Example 6: require ["enotify", "variables"];
例6：要求[“enotify”，“variables”]；
set :encodeurl "body_param" "Safe body&evil=evilbody";
set :encodeurl "body_param" "Safe body&evil=evilbody";
notify "mailto:tim@example.com?body=${body_param}";
notify "mailto:tim@example.com?body=${body_param}";
The "notify" action is compatible with all other actions, and does not affect the operation of other actions. In particular, the "notify" action MUST NOT cancel the implicit keep.
“通知”操作与所有其他操作兼容，不影响其他操作的操作。特别是，“通知”操作不能取消隐式保留。
Multiple executed "notify" actions are allowed. Specific notification methods MAY allow multiple notifications from the same script to be collapsed into one.
允许执行多个“通知”操作。特定的通知方法可能允许将来自同一脚本的多个通知折叠为一个。
Security considerations are discussed in [Sieve]. Additionally, implementations must be careful to follow the security considerations of the specific notification methods.
[SIFE]中讨论了安全注意事项。此外，实现必须小心地遵循特定通知方法的安全注意事项。
The "notify" action is potentially very dangerous. The path the notification takes through the network may not be secure. An error in the options string may cause the message to be transmitted to someone it was not intended for, or may expose information to eavesdroppers.
“通知”操作可能非常危险。通知通过网络的路径可能不安全。选项字符串中的错误可能会导致将消息发送给不打算发送给的人，或者可能会将信息暴露给窃听者。
Just because a notification is received doesn't mean that it was sent by the Sieve implementation. It might be possible to forge notifications or modify parts of valid notifications with some notification methods.
接收到通知并不意味着它是由Sieve实现发送的。可以使用某些通知方法伪造通知或修改部分有效通知。
Forgery of the ":importance" value (for example, by unauthorized script modification) can potentially result in slowdown in notification delivery.
伪造“：重要性”值（例如，通过未经授权的脚本修改）可能会导致通知传递速度减慢。
Note that some components of notifications should not be trusted. For example, the timestamp field can be easily forged or modified when some notification transports are used. Even if the timestamp is believed to be correct by the sender and is not modified in transit, it might be misleading on the receiving system due to clock differences.
请注意，不应信任通知的某些组件。例如，当使用某些通知传输时，时间戳字段很容易伪造或修改。即使发送方认为时间戳是正确的，并且在传输过程中没有修改，但由于时钟差异，它可能会误导接收系统。
An organization may have a policy about the forwarding of classified information to unclassified networks. Unless the policy is also enforced in the module responsible for the generating (or sending) of notifications, users can use the extension defined in this document to extract classified information and bypass the policy.
一个组织可能有一个关于将机密信息转发到非机密网络的策略。除非在负责生成（或发送）通知的模块中也强制执行该策略，否则用户可以使用本文档中定义的扩展来提取机密信息并绕过该策略。
Notifications can result in loops and bounces. Also, allowing a single script to notify multiple destinations can be used as a means of amplifying the number of messages in an attack. Moreover, if loop detection is not properly implemented, it may be possible to set up exponentially growing notification loops. Accordingly, Sieve notification methods:
通知可能导致循环和反弹。此外，允许单个脚本通知多个目的地也可以用作放大攻击中消息数量的一种手段。此外，如果未正确实现循环检测，则可能会建立指数增长的通知循环。因此，筛选通知方法：
1. MUST provide mechanisms for avoiding notification loops.
1. 必须提供避免通知循环的机制。
2. MUST provide the means for administrators to limit the ability of users to abuse notify. In particular, it MUST be possible to limit the number of "notify" actions a script can perform. Additionally, if no use cases exist for using "notify" with multiple destinations, this limit SHOULD be set to 1. Additional limits, such as the ability to restrict "notify" to local users, MAY also be implemented.
2. 必须为管理员提供限制用户滥用通知能力的方法。特别是，必须能够限制脚本可以执行的“通知”操作的数量。此外，如果不存在对多个目的地使用“notify”的用例，则该限制应设置为1。还可以实施其他限制，例如限制本地用户“通知”的能力。
3. MUST provide facilities to log the use of "notify" in order to facilitate tracking down abuse.
3. 必须提供记录“通知”使用情况的设施，以便于追踪滥用情况。
4. MAY use script analysis to determine whether or not a given script can be executed safely. While the Sieve language is sufficiently complex so that full analysis of all possible scripts is computationally infeasible, the majority of real-world scripts are amenable to analysis. For example, an implementation might allow scripts that it has determined to be safe to run unhindered, block scripts that are potentially problematic, and subject unclassifiable scripts to additional auditing and logging.
4. 可以使用脚本分析来确定给定脚本是否可以安全执行。虽然Sieve语言非常复杂，因此在计算上不可能对所有可能的脚本进行全面分析，但大多数现实世界的脚本都可以进行分析。例如，一个实现可能允许它确定为安全的脚本不受阻碍地运行，阻止可能有问题的脚本，并对不可分类的脚本进行额外的审核和日志记录。
Allowing "notify" action at all may not be appropriate in situations where Sieve scripts are associated with email accounts that are freely-available and/or not trackable to a human who can be held accountable for creating message bombs or other abuse.
在筛选脚本与电子邮件帐户关联的情况下，允许“通知”操作可能根本不合适，因为电子邮件帐户是免费提供的和/或不可跟踪的，而该人可能要为制造邮件炸弹或其他滥用行为负责。
Implementations that construct URIs internally from various notify parameters MUST make sure that all components of such URIs are properly percent-encoded (see [URI]). In particular, this applies to values of the ":from" and ":message" tagged arguments and may apply to the ":options" values.
从各种notify参数内部构造URI的实现必须确保这些URI的所有组件都正确地进行了百分比编码（请参见[URI]）。特别是，这适用于“：from”和“：message”标记参数的值，并且可能适用于“：options”值。
Header/envelope tests [Sieve], together with Sieve variables, can be used to extract the list of users to receive notifications from the incoming email message or its envelope. This is potentially quite dangerous, as this can be used for denial-of-service attacks on recipients controlled by the message sender. For this reason, implementations SHOULD NOT allow the use of variables containing values extracted from the email message in the "method" parameter to the "notify" action. Note that violation of this SHOULD NOT may result in the creation of an open relay, i.e., any sender would be able to create specially crafted email messages that would result in notifications delivered to recipients under the control of the sender. In the worst case, this might result in financial loss by the user controlling the Sieve script and/or by recipients of notifications (e.g., if a notification is an SMS message).
标题/信封测试[Sieve]以及Sieve变量可用于从传入电子邮件或其信封中提取接收通知的用户列表。这可能相当危险，因为这可用于对邮件发件人控制的收件人进行拒绝服务攻击。因此，实现不应允许在“method”参数中使用包含从电子邮件中提取的值的变量来执行“notify”操作。请注意，违反此规定不应导致创建开放式中继，即任何发件人都可以创建精心编制的电子邮件，从而在发件人的控制下向收件人发送通知。在最坏的情况下，这可能会导致控制筛选脚本的用户和/或通知接收者（例如，如果通知是SMS消息）的财务损失。
Note that the last SHOULD NOT is not a generic prohibition of use of variables in the "notify" action, as controlling the target of a notification by extracting it from user-owned data stores (such as user's Lightweight Directory Access Protocol (LDAP) entry) is considered to be useful.
请注意，最后一条不应是一般禁止在“notify”操作中使用变量，因为通过从用户拥有的数据存储（例如用户的轻量级目录访问协议（LDAP）条目）中提取通知来控制通知的目标被认为是有用的。
It is imperative that whatever implementations use to store the user-defined filtering scripts protect them from unauthorized modification, to preserve the integrity of the mail system. An attacker who can modify a script can cause mail to be discarded, rejected, or forwarded to an unauthorized recipient. In addition, it's possible that Sieve scripts might expose private information, such as mailbox names or email addresses of favored (or disfavored) correspondents. Because of that, scripts SHOULD also be protected from unauthorized retrieval.
无论使用什么实现来存储用户定义的过滤脚本，都必须保护它们不受未经授权的修改，以保持邮件系统的完整性。可以修改脚本的攻击者可导致邮件被丢弃、拒绝或转发给未经授权的收件人。此外，筛选脚本可能会公开私人信息，如受欢迎（或不受欢迎）的通讯员的邮箱名称或电子邮件地址。因此，还应保护脚本不被未经授权的检索。
To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: enotify
Description: adds the "notify" action for notifying user about the
received message. It also provides two new tests:
valid_notify_method checks notification URIs for validity;
notify_method_capability can check recipients capabilities.
RFC number: this RFC
Contact address: The Sieve discussion list
<ietf-mta-filters@imc.org>
To: iana@iana.org
Subject: Registration of new Sieve extension
Capability name: enotify
Description: adds the "notify" action for notifying user about the
received message. It also provides two new tests:
valid_notify_method checks notification URIs for validity;
notify_method_capability can check recipients capabilities.
RFC number: this RFC
Contact address: The Sieve discussion list
<ietf-mta-filters@imc.org>
This information has been added to the list of Sieve extensions available from http://www.iana.org/.
此信息已添加到可从中获得的筛网扩展列表中http://www.iana.org/.
IANA has created a new registry for Sieve notification mechanisms. This registry contains both vendor-controlled notification mechanism names (beginning with "vnd.") and IETF-controlled notification mechanism names. Vendor-controlled notification mechanism names have the format as defined in the following paragraph and may be registered on a "First Come First Served" basis [IANA-GUIDELINES], by applying to IANA with the form specified later in this section. Registration of notification mechanisms that do not begin with "vnd." are registered using a "Specification Required" policy [IANA-GUIDELINES].
IANA为筛选通知机制创建了一个新的注册表。此注册表包含供应商控制的通知机制名称（以“vnd.”开头）和IETF控制的通知机制名称。供应商控制的通知机制名称具有以下段落中定义的格式，可通过使用本节下文规定的格式向IANA申请，在“先到先得”的基础上注册[IANA-指南]。不以“vnd”开头的通知机制的注册使用“所需规范”策略[IANA-GUIDELINES]进行注册。
Vendor-controlled notification mechanism names MUST have the form "vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as specified in the Application Configuration Access Protocol (ACAP) Vendor Subtree registry [ACAP].
供应商控制的通知机制名称的格式必须为“vnd.<Vendor name><mechanism name>”，其中<Vendor name>在应用程序配置访问协议（ACAP）供应商子树注册表[ACAP]中指定。
This defines the template for a new registry for Sieve notification mechanisms, which has been created and is available from http://www.iana.org/. There are no initial entries for this registry.
这定义了用于筛选通知机制的新注册表的模板，该模板已创建，可从http://www.iana.org/. 此注册表没有初始项。
To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: [the name of the mechanism]
Mechanism URI: [the RFC number of the document that defines the URI
used by this mechanism. Different mechanisms MUST use different
URI schema.]
Mechanism-specific options: [the names of any Sieve notify options
(as used in the ":options" parameter) that are specific to this
mechanism, or "none"]
Permanent and readily available reference: [the RFC number or an URL
of the document that defines this notification mechanism]
Person and email address to contact for further information: [the
name and email address of the technical contact for information
about this mechanism]
To: iana@iana.org
Subject: Registration of new Sieve notification mechanism
Mechanism name: [the name of the mechanism]
Mechanism URI: [the RFC number of the document that defines the URI
used by this mechanism. Different mechanisms MUST use different
URI schema.]
Mechanism-specific options: [the names of any Sieve notify options
(as used in the ":options" parameter) that are specific to this
mechanism, or "none"]
Permanent and readily available reference: [the RFC number or an URL
of the document that defines this notification mechanism]
Person and email address to contact for further information: [the
name and email address of the technical contact for information
about this mechanism]
IANA has created a new registry for the notification-capability parameters of the notify_method_capability test. This registry contains both vendor-controlled notification-capability values (beginning with "vnd.") and IETF-controlled notification-capability values. Vendor-controlled notification-capability values have the format as defined in the following paragraph and may be registered on a "First Come First Served" basis [IANA-GUIDELINES], by applying to IANA with the form specified later in this section. Registration of
IANA已为notify_方法_能力测试的通知能力参数创建了一个新的注册表。此注册表包含供应商控制的通知功能值（以“vnd.”开头）和IETF控制的通知功能值。供应商控制的通知能力值具有以下段落中定义的格式，可通过使用本节后面规定的格式向IANA申请，在“先到先得”的基础上注册[IANA-指南]。注册
notification-capability values that do not begin with "vnd." are registered using the "Specification Required" policy [IANA-GUIDELINES].
使用“所需规范”策略[IANA-GUIDELINES]注册不以“vnd”开头的通知功能值。
Vendor-controlled notification-capability values MUST have the form "vnd.<vendor-name>.<capability-name>", where <vendor-name> is as specified in the ACAP Vendor Subtree registry [ACAP].
供应商控制的通知功能值的格式必须为“vnd.<Vendor name><capability name>”，其中<Vendor name>在ACAP供应商子树注册表[ACAP]中指定。
The following template must be used for registering notification-capability parameters:
必须使用以下模板注册通知功能参数：
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: [the name of the notification-capability]
Description: [an explanation of the purpose of the notification-
capability]
Syntax: [formal definition of allowed values and their syntax]
Permanent and readily available reference(s): [the RFC number(s) or
an URL of the document that defines this notification mechanism]
Contact information: [the name and email address of the technical
contact for information about this mechanism]
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: [the name of the notification-capability]
Description: [an explanation of the purpose of the notification-
capability]
Syntax: [formal definition of allowed values and their syntax]
Permanent and readily available reference(s): [the RFC number(s) or
an URL of the document that defines this notification mechanism]
Contact information: [the name and email address of the technical
contact for information about this mechanism]
Below is the registration form for the "online" notification-capability:
以下是“在线”通知功能的注册表格：
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: online
Description: Returns whether the entity identified by the
notification-uri parameter to the notify_method_capability test
can receive a notify notification immediately.
Syntax: Can contain one of three values: "yes", "no", and, "maybe".
Values MUST be in lowercase.
Permanent and readily available reference(s): This RFC
Contact information: The Sieve discussion list
<ietf-mta-filters@imc.org>
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: online
Description: Returns whether the entity identified by the
notification-uri parameter to the notify_method_capability test
can receive a notify notification immediately.
Syntax: Can contain one of three values: "yes", "no", and, "maybe".
Values MUST be in lowercase.
Permanent and readily available reference(s): This RFC
Contact information: The Sieve discussion list
<ietf-mta-filters@imc.org>
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings, and Pasi Eronen for help with this document.
感谢拉里·格林菲尔德、莎拉·罗伯森、蒂姆·肖沃尔特、赛勒斯·达布、奈杰尔·斯温森、杰蒂尔·托格里姆·霍姆、迈克尔·哈尔德、马克·E·马利特、内德·弗里德、丽莎·杜肖特、迪连·帕劳佐夫、阿恩特·古尔布兰森、彼得·圣安德烈、肖恩·特纳、卡伦·詹宁斯和帕西·埃隆对本文件的帮助。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Kwds]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, January 2009.
[MailTo]Leiba，B.和M.Haardt，“筛选通知机制：MailTo”，RFC 5436，2009年1月。
[Relational] Segmuller, W. and B. Leiba, "Sieve Extension: Relational Tests", RFC 5231, January 2008.
[Relational]Segmiller，W.和B.Leiba，“筛子扩展：关系测试”，RFC 52312008年1月。
[Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.，Ed.和T.Showalter，Ed.，“筛：电子邮件过滤语言”，RFC 5228，2008年1月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[Variables] Homme, K., "Sieve Extension: Variables", RFC 5229, January 2008.
[变量]霍姆，K.，“筛网扩展：变量”，RFC 52292008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-GUIDELINES]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[TEL-URI] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[TEL-URI]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP]Saint Andre，Ed.，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，2004年10月。
[XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[XMPP-URI]Saint Andre，P.，“可扩展消息传递和存在协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
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
Barry Leiba (editor) IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
Barry Leiba（编辑）IBM T.J.Watson研究中心美国纽约州霍桑市天际大道19号，邮编10532
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com
Wolfgang Segmuller IBM T.J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 US
美国纽约州霍桑市天际大道19号Wolfgang Segmuller IBM T.J.Watson研究中心，邮编10532
Phone: +1 914 784 7408
EMail: werewolf@us.ibm.com
Phone: +1 914 784 7408
EMail: werewolf@us.ibm.com
Tim Martin Endless Crossword 672 Haight st. San Francisco, CA 94117 US
提姆马丁无止境纵横672海特圣旧金山，CA 94117美国
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu
Phone: +1 510 260-4175
EMail: timmartin@alumni.cmu.edu