Internet Engineering Task Force (IETF) S. Bosch
Request for Comments: 7352 September 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Bosch
Request for Comments: 7352 September 2014
Category: Standards Track
ISSN: 2070-1721
Sieve Email Filtering: Detecting Duplicate Deliveries
筛选电子邮件筛选：检测重复传递
Abstract
摘要
This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.
本文档为Sieve电子邮件过滤语言定义了一个新的测试命令“duplicate”。此测试增加了检测重复的能力。这个新测试的主要应用程序是处理由邮件列表订阅或重定向邮件地址引起的重复传递。检测通常通过将消息ID与以前传递的消息的消息ID的内部列表相匹配来执行。对于更复杂的应用程序，“复制”测试还可以使用特定头字段的内容或消息的其他部分。
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/rfc7352.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7352.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................2
2. Conventions Used in This Document ...............................3
3. Test "duplicate" ................................................3
3.1. Arguments ":header" and ":uniqueid" ........................5
3.2. Argument ":handle" .........................................7
3.3. Arguments ":seconds" and ":last" ...........................8
3.4. Interaction with Other Sieve Extensions ....................9
4. Sieve Capability Strings ........................................9
5. Examples ........................................................9
5.1. Example 1 ..................................................9
5.2. Example 2 .................................................10
5.3. Example 3 .................................................11
5.4. Example 4 .................................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Test "duplicate" ................................................3
3.1. Arguments ":header" and ":uniqueid" ........................5
3.2. Argument ":handle" .........................................7
3.3. Arguments ":seconds" and ":last" ...........................8
3.4. Interaction with Other Sieve Extensions ....................9
4. Sieve Capability Strings ........................................9
5. Examples ........................................................9
5.1. Example 1 ..................................................9
5.2. Example 2 .................................................10
5.3. Example 3 .................................................11
5.4. Example 4 .................................................12
6. Security Considerations ........................................12
7. IANA Considerations ............................................13
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
This document specifies an extension to the Sieve filtering language defined by RFC 5228 [SIEVE]. It adds a test to track whether or not a text string was seen before by the delivery agent in an earlier execution of the Sieve script. This can be used to detect and handle duplicate message deliveries.
本文件规定了RFC 5228[SIFE]定义的SIFE过滤语言的扩展。它添加了一个测试，以跟踪交付代理在之前执行Sieve脚本时是否看到文本字符串。这可用于检测和处理重复的消息传递。
Duplicate deliveries are a common side effect of being subscribed to a mailing list. For example, if a member of the list decides to reply to both the user and the mailing list itself, the user will often get one copy of the message directly and another through the mailing list. Also, if someone crossposts over several mailing lists to which the user is subscribed, the user will likely receive a copy from each of those lists. In another scenario, the user has several redirected mail addresses all pointing to his main mail account. If one of the user's contacts sends the message to more than one of those addresses, the user will likely receive more than a single copy. Using the "duplicate" extension, users have the means to detect and handle such duplicates (e.g., by discarding them, marking them as "seen", or putting them in a special folder).
重复投递是订阅邮件列表的常见副作用。例如，如果列表中的一个成员决定回复用户和邮件列表本身，用户通常会直接获得一份邮件副本，通过邮件列表获得另一份。此外，如果有人在用户订阅的多个邮件列表上交叉发布，用户可能会从每个列表中收到一份副本。在另一个场景中，用户有几个重定向的邮件地址，所有这些地址都指向他的主邮件帐户。如果用户的一个联系人将消息发送到其中一个以上的地址，则用户可能会收到多个副本。使用“复制”扩展，用户可以检测和处理这些复制品（例如，丢弃它们，将它们标记为“已看到”，或将它们放在一个特殊文件夹中）。
Duplicate messages are normally detected using the Message-ID header field, which is required to be unique for each message. However, the "duplicate" test is flexible enough to use different criteria for defining what makes a message a duplicate (e.g., using the subject line or parts of the message body). Other applications of this new test command are also possible, as long as the tracked unique value is a string.
重复消息通常使用消息ID标头字段检测，该字段对于每条消息都必须是唯一的。但是，“重复”测试足够灵活，可以使用不同的标准来定义消息的重复内容（例如，使用主题行或消息正文的部分）。只要跟踪的唯一值是字符串，这个新测试命令的其他应用程序也是可能的。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Conventions for notations are as in Section 1.1 of [SIEVE], including use of the "Usage:" label for the definition of action and tagged arguments syntax.
符号惯例如[SIFE]第1.1节所述，包括使用“用法：”标签定义动作和标记参数语法。
Usage: "duplicate" [":handle" <handle: string>]
[":header" <header-name: string> /
":uniqueid" <value: string>]
[":seconds" <timeout: number>] [":last"]
Usage: "duplicate" [":handle" <handle: string>]
[":header" <header-name: string> /
":uniqueid" <value: string>]
[":seconds" <timeout: number>] [":last"]
The "duplicate" test identifies the message by a "unique ID" and, using that unique ID, keeps track of which messages were seen by a "duplicate" test during an earlier Sieve execution. In its basic form, the test gets the unique ID from the content of the message's Message-ID header field. The "duplicate" test evaluates to "true" if the message was seen before, and it evaluates to "false" if it was not.
“重复”测试通过“唯一ID”标识消息，并使用该唯一ID跟踪“重复”测试在早期执行时看到的消息。在其基本形式中，测试从消息的消息ID头字段的内容中获取唯一ID。如果以前看到过消息，“复制”测试将评估为“true”，如果没有看到消息，则评估为“false”。
As a side effect, the "duplicate" test adds the unique ID to an internal duplicate-tracking list once the Sieve execution finishes successfully. The first time a particular unique ID is seen, the message is not a duplicate, and the unique ID is added to the tracking list. If a future Sieve execution sees a message whose unique ID appears in the tracking list, that test will evaluate to "true", and that message will be considered a duplicate.
作为一个副作用，“重复”测试在筛选成功完成后将唯一ID添加到内部重复跟踪列表中。第一次看到特定的唯一ID时，消息不是重复的，唯一ID将添加到跟踪列表中。如果将来的筛选执行看到一条消息，其唯一ID出现在跟踪列表中，则该测试将评估为“true”，并且该消息将被视为重复消息。
Note that this side effect is performed only when the "duplicate" test is actually evaluated. If the "duplicate" test is nested in a control structure or if it is not the first item of an "allof" or "anyof" test list, its evaluation depends on the result of preceding tests, which may produce unexpected results.
请注意，只有在实际评估“重复”测试时才执行此副作用。如果“重复”测试嵌套在控制结构中，或者如果它不是“allof”或“anyof”测试列表的第一项，则其评估取决于先前测试的结果，这可能会产生意外的结果。
Implementations MUST only update the internal duplicate-tracking list when the Sieve script execution finishes successfully. If failing script executions add the unique ID to the duplicate-tracking list, all "duplicate" tests in the Sieve script would erroneously yield "true" for the next delivery attempt of the same message. This can -- depending on the action taken for a duplicate -- easily lead to discarding the message without further notice.
实现必须仅在Sieve脚本执行成功完成时更新内部重复跟踪列表。如果脚本执行失败，将唯一ID添加到重复跟踪列表中，则筛脚本中的所有“重复”测试将错误地为同一消息的下一次传递尝试生成“true”。这很容易导致在不另行通知的情况下丢弃消息，具体取决于对重复消息所采取的操作。
However, deferring the definitive modification of the tracking list to the end of a successful Sieve script execution is not without problems. It can cause a race condition when a duplicate message is delivered in parallel before the tracking list is updated. This way, a duplicate message could be missed by the "duplicate" test. More complex implementations could use a locking mechanism to prevent this problem. But, irrespective of what implementation is chosen, situations in which the "duplicate" test erroneously yields "true" MUST be prevented.
但是，将跟踪列表的最终修改推迟到成功执行筛选脚本的末尾并非没有问题。当在更新跟踪列表之前并行传递重复消息时，可能会导致竞争条件。这样，“重复”测试可能会错过重复的消息。更复杂的实现可以使用锁定机制来防止此问题。但是，无论选择什么实现，都必须防止“重复”测试错误地产生“真”的情况。
The "duplicate" test MUST only check for duplicates amongst unique ID values encountered in previous executions of the Sieve script; it MUST NOT consider ID values encountered earlier in the current Sieve script execution as potential duplicates. This means that all "duplicate" tests in a Sieve script execution, including those located in scripts included using the "include" [INCLUDE] extension, MUST always yield the same result if the arguments are identical.
“重复”测试必须仅检查在之前执行筛选脚本时遇到的唯一ID值中是否存在重复项；它不能考虑在当前筛选器脚本执行中较早遇到的ID值作为潜在副本。这意味着，如果参数相同，则在一个Sieve脚本执行中的所有“重复”测试，包括那些位于使用“include”[include]扩展名包含的脚本中的测试，必须始终产生相同的结果。
The Message-ID header field is assumed to be globally unique as required in Section 3.6.4 of RFC 5322 [IMAIL]. In practice, this assumption may not always prove to be true. The "duplicate" test does not deal with this situation, which means that false duplicates may be detected in this case. However, the user can address such situations by specifying an alternative means of message identification using the ":header" or the ":uniqueid" argument, as described in the next section.
根据RFC 5322[IMAIL]第3.6.4节的要求，假定消息ID标头字段是全局唯一的。在实践中，这一假设可能并不总是正确的。“重复”测试不处理这种情况，这意味着在这种情况下可能检测到虚假重复。然而，用户可以通过使用“：header”或“：uniqueid”参数指定消息标识的替代方法来解决这种情况，如下一节所述。
Duplicate tracking involves determining the unique ID for a given message and checking whether that unique ID is in the duplicate-tracking list. The unique ID for a message is determined as follows:
重复跟踪涉及确定给定邮件的唯一ID，并检查该唯一ID是否在重复跟踪列表中。消息的唯一ID确定如下：
o When neither the ":header" argument nor the ":uniqueid" argument is used, the unique ID is the content of the message's Message-ID header field.
o 如果既不使用“：header”参数也不使用“：uniqueid”参数，则唯一ID是消息的消息ID头字段的内容。
o When the ":header" argument is used, the unique ID is the content of the specified header field in the message. The header field name is not part of the resulting unique ID; it consists only of the field value.
o 使用“：header”参数时，唯一ID是消息中指定标头字段的内容。标题字段名称不是生成的唯一ID的一部分；它只包含字段值。
o When the ":uniqueid" argument is used, the unique ID is the string parameter that is specified with the argument.
o 使用“：uniqueid”参数时，唯一ID是随参数指定的字符串参数。
The ":header" and ":uniqueid" arguments are mutually exclusive; specifying both for a single "duplicate" test command MUST trigger an error.
“：header”和“：uniqueid”参数是互斥的；为单个“重复”测试命令同时指定这两个必须触发错误。
The syntax rules for the header name parameter of the ":header" argument are specified in Section 2.4.2.2 of RFC 5228 [SIEVE]. Note that implementations MUST NOT trigger an error for an invalid header name. Instead, the "duplicate" test MUST yield "false" unconditionally in this case. The parameter of the ":uniqueid" argument can be any string.
RFC 5228[SIFE]第2.4.2.2节规定了“：header”参数的header name参数的语法规则。请注意，实现不得触发无效头名称的错误。相反，在这种情况下，“重复”测试必须无条件地产生“false”。“：uniqueid”参数的参数可以是任何字符串。
If the tracked unique ID value is extracted directly from a message header field (i.e., when the ":uniqueid" argument is not used), the following operations MUST be performed before the actual duplicate verification:
如果直接从消息头字段提取跟踪的唯一ID值（即：未使用“：uniqueid”参数），则在实际重复验证之前必须执行以下操作：
o Unfold the header line as described in Section 2.2.3 of RFC 5322 [IMAIL] (see also Section 2.4.2.2 of RFC 5228 [SIEVE]).
o 按照RFC 5322[IMAIL]第2.2.3节中的说明展开收割台线（另请参见RFC 5228[SIVE]第2.4.2.2节）。
o If possible, convert the header value to Unicode, encoded as UTF-8 (see Section 2.7.2 of RFC 5228 [SIEVE]). If conversion is not possible, the value is left unchanged.
o 如果可能，将标题值转换为Unicode，编码为UTF-8（参见RFC 5228[SIFE]第2.7.2节）。如果无法转换，则该值保持不变。
o Trim leading and trailing whitespace from the header value (see Section 2.2 of RFC 5228 [SIEVE]).
o 从标题值中修剪前导和尾随空格（参见RFC 5228[筛]第2.2节）。
Note that these rules also apply to the Message-ID header field used by the basic "duplicate" test without a ":header" or ":uniqueid" argument. When the ":uniqueid" argument is used, any normalization needs to be done in the Sieve script itself as the unique ID is created.
请注意，这些规则也适用于基本的“复制”测试（不带“：header”或“：uniqueid”参数）使用的消息ID头字段。当使用“：uniqueid”参数时，在创建唯一ID时，需要在Sieve脚本本身中执行任何规范化。
If the header field specified using the ":header" argument exists multiple times in the message, extraction of the unique ID MUST use only the first occurrence. This is true whether or not multiple occurrences are allowed by Section 3.6 of RFC 5322 [IMAIL]. If the specified header field is not present in the message, the "duplicate" test MUST yield "false" unconditionally. In that case, the duplicate-tracking list is left unmodified by this test, since no unique ID value is available. The same rules apply with respect to the Message-ID header field for the basic "duplicate" test without a ":header" or ":uniqueid" argument, since that header field could also be missing or occur multiple times.
如果使用“：header”参数指定的标头字段在消息中多次存在，则提取唯一ID必须仅使用第一次出现。无论RFC 5322[IMAIL]第3.6节是否允许多次出现，都是如此。如果消息中不存在指定的头字段，“重复”测试必须无条件地产生“false”。在这种情况下，由于没有唯一的ID值可用，因此此测试不会修改重复跟踪列表。同样的规则适用于基本“复制”测试的消息ID头字段，不带“：header”或“：uniqueid”参数，因为该头字段也可能丢失或出现多次。
The string parameter of the ":uniqueid" argument can be composed from arbitrary text extracted from the message using the "variables" [VARIABLES] extension. To extract text from the message body, the "foreverypart" and "extracttext" [SIEVE-MIME] extensions need to be used as well. This provides the user with detailed control over how the message's unique ID is created.
“：uniqueid”参数的字符串参数可以由使用“variables”[variables]扩展名从消息中提取的任意文本组成。要从消息正文中提取文本，还需要使用“foreverypart”和“extracttext”[SIEVE-MIME]扩展。这为用户提供了如何创建消息唯一ID的详细控制。
The unique ID MUST be matched case-sensitively with the contents of the duplicate-tracking list, irrespective of how the unique ID was determined. To achieve case-insensitive behavior when the ":uniqueid" argument is used, the "set" command added by the "variables" [VARIABLES] extension can be used to normalize the unique ID value to upper or lower case.
无论唯一ID是如何确定的，唯一ID都必须与重复跟踪列表的内容进行区分大小写的匹配。要在使用“：uniqueid”参数时实现不区分大小写的行为，可以使用“variables”[variables]扩展添加的“set”命令将唯一ID值规范化为大写或小写。
The "duplicate" test MUST track a unique ID value independent of its source. This means that all values in the duplicate-tracking list should be used for duplicate testing, regardless of whether they were obtained from the Message-ID header field, from an arbitrary header specified using the ":header" argument, or explicitly from the ":uniqueid" argument. The following three examples are equivalent and match the same entry in the duplicate-tracking list:
“重复”测试必须跟踪独立于其源的唯一ID值。这意味着，重复跟踪列表中的所有值都应用于重复测试，而不管它们是从消息ID头字段、使用“：header”参数指定的任意头还是从“：uniqueid”参数显式获得的。以下三个示例是等效的，并与重复跟踪列表中的相同条目相匹配：
require "duplicate";
if duplicate {
discard;
}
require "duplicate";
if duplicate {
discard;
}
require "duplicate";
if duplicate :header "message-id" {
discard;
}
require "duplicate";
if duplicate :header "message-id" {
discard;
}
require ["duplicate", "variables"];
if header :matches "message-id" "*" {
if duplicate :uniqueid "${0}" {
discard;
}
}
require ["duplicate", "variables"];
if header :matches "message-id" "*" {
if duplicate :uniqueid "${0}" {
discard;
}
}
The ":handle" argument can be used to override this default behavior. The ":handle" argument separates a "duplicate" test from other "duplicate" tests with a different or omitted ":handle" argument. Using the ":handle" argument, unrelated "duplicate" tests can be prevented from interfering with each other: a message is only recognized as a duplicate when the tracked unique ID was seen before in an earlier script execution by a "duplicate" test with the same ":handle" argument.
“：handle”参数可用于覆盖此默认行为。“：handle”参数使用不同或省略的“：handle”参数将“重复”测试与其他“重复”测试分开。使用“：handle”参数，可以防止不相关的“重复”测试相互干扰：只有在先前的脚本执行中，通过使用相同“：handle”参数的“重复”测试看到跟踪的唯一ID时，消息才会被识别为重复。
NOTE: The necessary mechanism to track duplicate messages is very similar to the mechanism that is needed for tracking duplicate responses for the "vacation" action [VACATION]. One way to implement the necessary mechanism for the "duplicate" test is therefore to store a hash of the tracked unique ID and, if provided, the ":handle" argument.
注意：跟踪重复消息的必要机制与跟踪“休假”操作[休假]的重复响应所需的机制非常相似。因此，实现“复制”测试所需机制的一种方法是存储跟踪的唯一ID的散列，如果提供了“：handle”参数。
Implementations SHOULD let entries in the tracking list expire after a short period of time. The user can explicitly control the length of this expiration time by means of the ":seconds" argument, which accepts an integer value specifying the timeout value in seconds. If the ":seconds" argument is omitted, an appropriate default value MUST be used. A default expiration time of around 7 days is usually appropriate. Sites SHOULD impose a maximum limit on the expiration time. If that limit is exceeded by the ":seconds" argument, the maximum value MUST be silently substituted; exceeding the limit MUST NOT produce an error. If the ":seconds" argument is zero, the "duplicate" test MUST yield "false" unconditionally.
实现应该让跟踪列表中的条目在短时间后过期。用户可以通过“：seconds”参数显式控制该过期时间的长度，该参数接受一个整数值，该整数值以秒为单位指定超时值。如果省略“：seconds”参数，则必须使用适当的默认值。通常情况下，大约7天的默认到期时间是合适的。营业点应对到期时间施加最大限制。如果“：seconds”参数超出了该限制，则必须以静默方式替换最大值；超过限制不得产生错误。如果“：seconds”参数为零，“replicate”测试必须无条件地产生“false”。
When the ":last" argument is omitted, the expiration time for entries in the duplicate-tracking list MUST be measured relative to the moment at which the entry was first created (i.e., at the end of the successful script execution during which the "duplicate" test returned "false" for a message with that particular unique ID value). This means that subsequent duplicate messages have no influence on the time at which the entry in the duplicate-tracking list finally expires.
当省略“：last”参数时，必须相对于第一次创建条目的时刻（即，在成功执行脚本结束时，“duplicate”测试对具有特定唯一ID值的消息返回“false”）来测量复制跟踪列表中条目的过期时间。这意味着后续的重复消息对重复跟踪列表中的条目最终过期的时间没有影响。
In contrast, when the ":last" argument is specified, the expiration time MUST be measured relative to the last script execution during which the "duplicate" test was used to check the entry's unique ID value. This effectively means that the entry in the duplicate-tracking list will not expire while duplicate messages with the corresponding unique ID keep being delivered within intervals smaller than the expiration time.
相反，当指定“：last”参数时，必须相对于最后一次脚本执行测量过期时间，在此期间，使用“复制”测试检查条目的唯一ID值。这实际上意味着，重复跟踪列表中的条目将不会过期，而具有相应唯一ID的重复消息将在小于过期时间的间隔内继续传递。
It is possible to write Sieve scripts where, during a single execution, more than one "duplicate" test is evaluated with the same unique ID value and ":handle" argument but different ":seconds" or ":last" arguments. The resulting behavior is left undefined by this specification, so such constructs should be avoided. Implementations MAY choose to use the ":seconds" and ":last" arguments from the "duplicate" test that was evaluated last.
可以编写筛选脚本，其中，在单个执行过程中，使用相同的唯一ID值和“：handle”参数但不同的“：seconds”或“：last”参数对多个“重复”测试进行评估。此规范未定义结果行为，因此应避免此类构造。实现可以选择使用上次评估的“重复”测试中的“：seconds”和“：last”参数。
The "duplicate" test does not support either the "index" [DATE-INDEX] or "mime" [SIEVE-MIME] extensions directly, meaning that none of the ":index", ":mime", or associated arguments are added to the "duplicate" test when these extensions are active. The ":uniqueid" argument can be used in combination with the "variables" [VARIABLES] extension to achieve the same result indirectly.
“复制”测试不直接支持“index”[DATE-index]或“mime”[SIEVE-mime]扩展，这意味着当这些扩展处于活动状态时，“：index”、“：mime”或相关参数都不会添加到“复制”测试中。“：uniqueid”参数可以与“variables”[variables]扩展结合使用，间接获得相同的结果。
Normally, Sieve scripts are executed at final delivery. However, with the "imapsieve" [IMAPSIEVE] extension, Sieve scripts are invoked when the IMAP [IMAP] server performs operations on the message store (e.g., when messages are uploaded, flagged, or moved to another location). The "duplicate" test is devised for use at final delivery, and the semantics in the "imapsieve" context are left undefined. Therefore, implementations SHOULD NOT allow the "duplicate" test to be used in the context of "imapsieve".
通常，筛选脚本在最终交付时执行。但是，使用“IMAPSIEV”[IMAPSIEV]扩展，当IMAP[IMAP]服务器对消息存储执行操作时（例如，当消息上载、标记或移动到另一个位置时），会调用筛选脚本。“复制”测试是为在最终交付时使用而设计的，“imapsieve”上下文中的语义没有定义。因此，实现不应允许在“imapsieve”上下文中使用“重复”测试。
A Sieve implementation that defines the "duplicate" test command will advertise the capability string "duplicate".
定义“duplicate”测试命令的Sieve实现将公布功能字符串“duplicate”。
In this basic example, message duplicates are detected by tracking the Message-ID header field. Duplicate deliveries are stored in a special folder contained in the user's Trash folder. If the folder does not exist, it is created automatically using the "mailbox" [MAILBOX] extension. This way, the user has a chance to recover messages when necessary. Messages that are not recognized as duplicates are stored in the user's inbox as normal.
在这个基本示例中，通过跟踪消息ID头字段来检测消息重复。重复交付存储在用户垃圾箱文件夹中的特殊文件夹中。如果文件夹不存在，将使用“邮箱”[mailbox]扩展名自动创建该文件夹。这样，用户就有机会在必要时恢复消息。未被识别为重复的邮件将正常存储在用户的收件箱中。
require ["duplicate", "fileinto", "mailbox"];
要求[“复制”、“文件导入”、“邮箱”]；
if duplicate {
fileinto :create "Trash/Duplicate";
}
if duplicate {
fileinto :create "Trash/Duplicate";
}
This example shows a more complex use of the "duplicate" test. The user gets network alerts from a set of remote automated monitoring systems. Several notifications can be received about the same event from different monitoring systems. The Message-ID header field of these messages is different, because these are all distinct messages from different senders. To avoid being notified more than a single time about the same event, the user writes the following script:
这个例子展示了“复制”测试的更复杂的用法。用户从一组远程自动监控系统获取网络警报。可以从不同的监控系统收到关于同一事件的多个通知。这些消息的消息ID标头字段不同，因为它们都是来自不同发件人的不同消息。为避免同一事件被多次通知，用户编写以下脚本：
require ["duplicate", "variables", "imap4flags", "fileinto"];
需要[“复制”、“变量”、“imap4flags”、“文件导入”]；
if header :matches "subject" "ALERT: *" {
if duplicate :seconds 60 :uniqueid "${1}" {
setflag "\\seen";
}
fileinto "Alerts";
}
if header :matches "subject" "ALERT: *" {
if duplicate :seconds 60 :uniqueid "${1}" {
setflag "\\seen";
}
fileinto "Alerts";
}
The subjects of the notification message are structured with a predictable pattern that includes a description of the event. In the script above, the "duplicate" test is used to detect duplicate alert events. The message subject is matched against a pattern, and the event description is extracted using the "variables" [VARIABLES] extension. If a message with that event in the subject was received before, but more than a minute ago, it is not detected as a duplicate due to the specified ":seconds" argument. In the event of a duplicate, the message is marked as "seen" using the "imap4flags" [IMAP4FLAGS] extension. All alert messages are put into the "Alerts" mailbox, irrespective of whether those messages are duplicates or not.
通知消息的主题以可预测的模式构建，其中包括事件的描述。在上面的脚本中，“复制”测试用于检测重复的警报事件。根据模式匹配消息主题，并使用“variables”[variables]扩展提取事件描述。如果主题中包含该事件的消息是在一分钟前收到的，则由于指定的“：seconds”参数，不会将其检测为重复消息。如果消息重复，则使用“imap4flags”[imap4flags]扩展名将消息标记为“已看到”。所有警报消息都会放入“警报”邮箱，无论这些消息是否重复。
This example shows how the "duplicate" test can be used to limit the frequency of notifications sent using the "enotify" [NOTIFY] extension. Consider the following scenario: a mail user receives Extensible Messaging and Presence Protocol (XMPP) notifications [NOTIFY-XMPP] about new mail through Sieve, but sometimes a single contact sends many messages in a short period of time. Now the user wants to prevent being notified of all of those messages. The user wants to be notified about messages from each person at most once per 30 minutes and writes the following script:
此示例显示如何使用“复制”测试来限制使用“enotify”[NOTIFY]扩展发送通知的频率。考虑以下情况：邮件用户通过筛选器接收关于新邮件的可扩展消息和存在协议（XMPP）通知[NoTIFY-XMPP]，但有时单个联系人在短时间内发送许多消息。现在，用户希望防止收到所有这些消息的通知。用户希望每30分钟最多收到一次来自每个人的消息通知，并编写以下脚本：
require ["variables", "envelope", "enotify", "duplicate"];
要求[“变量”、“信封”、“enotify”、“重复”]；
if envelope :matches "from" "*" { set "sender" "${1}"; }
if header :matches "subject" "*" { set "subject" "${1}"; }
if envelope :matches "from" "*" { set "sender" "${1}"; }
if header :matches "subject" "*" { set "subject" "${1}"; }
if not duplicate :seconds 1800 :uniqueid "${sender}"
{
notify :message "[SIEVE] ${sender}: ${subject}"
"xmpp:user@im.example.com";
}
if not duplicate :seconds 1800 :uniqueid "${sender}"
{
notify :message "[SIEVE] ${sender}: ${subject}"
"xmpp:user@im.example.com";
}
The example shown above uses the message envelope sender rather than the Message-ID header field as the unique ID for duplicate tracking.
上面显示的示例使用message envelope sender而不是message ID header字段作为重复跟踪的唯一ID。
The example can be extended to allow more messages from the same sender in close succession as long as the discussed subject is different. This can be achieved as follows:
只要讨论的主题不同，该示例可以扩展为允许同一发件人连续发送更多消息。这可以通过以下方式实现：
require ["variables", "envelope", "enotify", "duplicate"];
要求[“变量”、“信封”、“enotify”、“重复”]；
if envelope :matches "from" "*" { set "sender" "${1}"; }
if header :matches "subject" "*" { set "subject" "${1}"; }
if envelope :matches "from" "*" { set "sender" "${1}"; }
if header :matches "subject" "*" { set "subject" "${1}"; }
# account for 'Re:' prefix
if string :comparator "i;ascii-casemap"
:matches "${subject}" "Re:*"
{
set "subject" "${1}";
}
if not duplicate :seconds 1800
:uniqueid "${sender} ${subject}"
{
notify :message "[SIEVE] ${sender}: ${subject}"
"xmpp:user@im.example.com";
}
# account for 'Re:' prefix
if string :comparator "i;ascii-casemap"
:matches "${subject}" "Re:*"
{
set "subject" "${1}";
}
if not duplicate :seconds 1800
:uniqueid "${sender} ${subject}"
{
notify :message "[SIEVE] ${sender}: ${subject}"
"xmpp:user@im.example.com";
}
This uses a combination of the message envelope sender and the subject of the message as the unique ID for duplicate tracking.
这使用消息信封发送者和消息主题的组合作为重复跟踪的唯一ID。
For this example, the mail user uses the "duplicate" test for two separate applications: for discarding duplicate events from a notification system and for marking certain follow-up messages in a software support mailing as "seen" using the "imap4flags" [IMAP4FLAGS] extension.
对于本例，邮件用户对两个单独的应用程序使用“重复”测试：用于从通知系统中丢弃重复事件，以及使用“imap4flags”[imap4flags]扩展将软件支持邮件中的某些后续消息标记为“已看到”。
The two "duplicate" tests in the following example each use a different header to identify messages. However, these "X-Event-ID" and "X-Ticket-ID" headers can have similar values in this case (e.g., both based on a time stamp), meaning that one "duplicate" test can erroneously detect duplicates based on ID values tracked by the other. Therefore, the user wants to prevent the second "duplicate" test from matching ID values tracked by the first "duplicate" test and vice versa. This is achieved by specifying different ":handle" arguments for these tests.
下面示例中的两个“重复”测试都使用不同的头来标识消息。然而，在这种情况下，这些“X-Event-ID”和“X-Ticket-ID”头可以具有类似的值（例如，两者都基于时间戳），这意味着一个“重复”测试可以基于另一个跟踪的ID值错误地检测重复。因此，用户希望防止第二个“重复”测试与第一个“重复”测试跟踪的ID值匹配，反之亦然。这是通过为这些测试指定不同的“：handle”参数来实现的。
require ["duplicate", "imap4flags"];
要求[“重复”，“imap4flags”]；
if duplicate :header "X-Event-ID" :handle "notifier" {
discard;
}
if allof (
duplicate :header "X-Ticket-ID" :handle "support",
address "to" "support@example.com",
header :contains "subject" "fileserver")
{
setflag "\\seen";
}
if duplicate :header "X-Event-ID" :handle "notifier" {
discard;
}
if allof (
duplicate :header "X-Ticket-ID" :handle "support",
address "to" "support@example.com",
header :contains "subject" "fileserver")
{
setflag "\\seen";
}
A flood of unique messages could cause the duplicate-tracking list to grow indefinitely. Therefore, implementations SHOULD limit the number of entries in the duplicate-tracking list. When limiting the number of entries, implementations SHOULD discard the oldest ones first.
大量的独特消息可能会导致重复跟踪列表无限期增长。因此，实现应该限制重复跟踪列表中的条目数。在限制条目数量时，实现应该首先放弃最旧的条目。
Scripts using the "duplicate" test evaluation should be aware that message IDs are not necessarily unique, either through the fault of benign generators or attackers injecting a message with the properties used by the duplicate Sieve filter at some point prior to
使用“重复”测试评估的脚本应该意识到，消息ID不一定是唯一的，这可能是由于良性生成器的故障，也可能是由于攻击者在测试之前的某个时间注入了具有重复筛选过滤器所用属性的消息
the Sieve filter. Therefore, scripts are well advised to be conservative with respect to actions taken when duplicate messages are identified only by message ID.
过滤网。因此，当仅通过消息ID识别重复消息时，建议脚本对所采取的操作保持保守。
The list of unique IDs used for duplicate tracking can include privacy-sensitive information, such as message ID values, content of subject lines, and content extracted from message bodies. Implementations SHOULD protect that information by obscuring it through hashing (see the note at the end of Section 3.2) and/or by storing it with a level of access control equivalent to that of the messages themselves.
用于重复跟踪的唯一ID列表可以包括隐私敏感信息，例如消息ID值、主题行的内容以及从消息正文中提取的内容。实现应该通过散列（参见第3.2节末尾的注释）和/或通过与消息本身的访问控制级别相当的访问控制级别来保护该信息。
These measures will not prevent an entity that has access to the duplicate-tracking list from querying whether messages with certain unique ID values were received. As this operation is the essence of the "duplicate" test, this cannot be prevented and may violate the expectations of the user. For example, a user who deletes a message from the server may expect that no record of it remains on the server, but that will not be true if its message ID is persisted on the server in the duplicate-tracking list.
这些措施不会阻止有权访问重复跟踪列表的实体查询是否收到具有特定唯一ID值的邮件。由于此操作是“重复”测试的本质，因此无法防止，并且可能违反用户的期望。例如，从服务器上删除邮件的用户可能希望该邮件的任何记录都不会保留在服务器上，但如果其邮件ID在服务器上的重复跟踪列表中保持不变，则情况就不是这样了。
It's notable, however, that server logs will often store the information present on the duplicate-tracking list anyway and probably would expose plaintext message IDs for a much longer period than this mechanism would. Users of email services that intentionally delete such logs with the intent of limiting traceability should be made aware that use of the duplicate-tracking mechanism re-exposes this information for the duration of the expiry interval. Therefore, a shorter default expiry interval may be appropriate in those situations.
然而，值得注意的是，服务器日志通常会存储重复跟踪列表上的信息，并且可能会在比这种机制更长的时间内公开明文消息ID。有意删除此类日志以限制可追溯性的电子邮件服务用户应了解，使用重复跟踪机制会在到期时间间隔内重新暴露此信息。因此，在这些情况下，缩短默认到期时间间隔可能是合适的。
The following template specifies the IANA registration of the Sieve extension specified in this document:
以下模板规定了本文件中规定的筛网扩展的IANA注册：
To: iana@iana.org Subject: Registration of new Sieve extension
致：iana@iana.org主题：新筛网扩展的注册
Capability name: duplicate Description: Adds test 'duplicate' that can be used to test whether a particular message is a duplicate, i.e., whether a copy of it was seen before by the delivery agent that is executing the Sieve script. RFC number: RFC 7352 Contact address: Sieve mailing list <sieve@ietf.org>
功能名称：重复描述：添加可用于测试特定消息是否重复的测试“duplicate”，即，执行筛选脚本的传递代理之前是否看到了该消息的副本。RFC号码：RFC 7352联系地址：SIVE邮件列表<sieve@ietf.org>
This information has been added to the list of Sieve extensions given on <http://www.iana.org/assignments/sieve-extensions>.
此信息已添加到上给出的筛网扩展列表中<http://www.iana.org/assignments/sieve-extensions>.
Thanks to Brian Carpenter, Cyrus Daboo, Arnt Gulbrandsen, Tony Hansen, Kristin Hubner, Barry Leiba, Alexey Melnikov, Subramanian Moonesamy, Tom Petch, Hector Santos, Robert Sparks, Aaron Stone, and Stefan Winter for reviews and suggestions. Special thanks to Ned Freed for his guidance and support.
感谢Brian Carpenter、Cyrus Daboo、Arnt Gulbrandsen、Tony Hansen、Kristin Hubner、Barry Leiba、Alexey Melnikov、Subramanian Moonesamy、Tom Petch、Hector Santos、Robert Sparks、Aaron Stone和Stefan Winter的评论和建议。特别感谢Ned Freed的指导和支持。
[DATE-INDEX] Freed, N., "Sieve Email Filtering: Date and Index Extensions", RFC 5260, July 2008.
[DATE-INDEX]Freed，N.，“筛选电子邮件过滤：日期和索引扩展”，RFC 52602008年7月。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[IMAIL]Resnick，P.，Ed.“互联网信息格式”，RFC5322，2008年10月。
[IMAPSIEVE] Leiba, B., "Support for Internet Message Access Protocol (IMAP) Events in Sieve", RFC 6785, November 2012.
[IMAPSIEVE]Leiba，B.“在Sieve中对互联网消息访问协议（IMAP）事件的支持”，RFC 6785，2012年11月。
[INCLUDE] Daboo, C. and A. Stone, "Sieve Email Filtering: Include Extension", RFC 6609, May 2012.
[包括]Daboo，C.和A.Stone，“筛选电子邮件过滤：包括扩展”，RFC 6609，2012年5月。
[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月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[筛]Guenther，P.和T.Showalter，“筛：电子邮件过滤语言”，RFC 52282008年1月。
[SIEVE-MIME] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, October 2009.
[SIEVE-MIME]Hansen，T.和C.Daboo，“SIEVE电子邮件过滤：MIME部分测试、迭代、提取、替换和封装”，RFC 57032009年10月。
[VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[VARIABLES]Homme，K.，“筛选电子邮件过滤：变量扩展”，RFC 52292008年1月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAP4FLAGS] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008.
[IMAP4FLAGS]Melnikov，A.，“筛选电子邮件过滤：IMAP4FLAGS扩展”，RFC 5232，2008年1月。
[MAILBOX] Melnikov, A., "The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata", RFC 5490, March 2009.
[邮箱]Melnikov，A.，“筛选邮件过滤语言——检查邮箱状态和访问邮箱元数据的扩展”，RFC 54902009年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月。
[NOTIFY-XMPP] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009.
[NOTIFY-XMPP]Saint Andre，P.和A.Melnikov，“筛选通知机制：可扩展消息和状态协议（XMPP）”，RFC 5437，2009年1月。
[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[假期]Showalter，T.和N.Freed，“筛选电子邮件过滤：假期延长”，RFC 5230，2008年1月。
Author's Address
作者地址
Stephan Bosch Enschede NL
斯蒂芬·博什·恩斯切德NL
EMail: stephan@rename-it.nl
EMail: stephan@rename-it.nl