[要約] RFC 7352は、Sieveメールフィルタリングにおいて重複配信を検出するための方法を提案しています。このRFCの目的は、メールサーバーでの重複配信を防ぐための標準化された手法を提供することです。
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
Sieveメールフィルタリング：重複した配信の検出
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 [SIEVE]で定義されているSieveフィルタリング言語の拡張について説明しています。 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).
配信の重複は、メーリングリストに登録されることの一般的な副作用です。たとえば、リストのメンバーがユーザーとメーリングリスト自体の両方に返信することにした場合、ユーザーは多くの場合、メッセージのコピーを直接受け取り、別のコピーをメーリングリストから受け取ります。また、ユーザーがサブスクライブしている複数のメーリングリストに誰かがクロスポストした場合、ユーザーはそれらの各リストからコピーを受け取る可能性があります。別のシナリオでは、ユーザーはいくつかのリダイレクトされたメールアドレスを持ち、すべてメインメールアカウントを指しています。ユーザーの連絡先の1人が複数のアドレスにメッセージを送信した場合、ユーザーは1つ以上のコピーを受信する可能性があります。 「重複」拡張機能を使用すると、ユーザーはそのような重複を検出して処理する手段があります（たとえば、それらを破棄するか、「表示済み」としてマークするか、またはそれらを特別なフォルダーに配置します）。
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.
重複メッセージは通常、メッセージごとに一意である必要があるMessage-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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
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.
表記法の表記法は、[SIEVE]のセクション1.1と同じです。これには、アクションの定義とタグ付き引数の構文の「使用法：」ラベルの使用が含まれます。
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を使用して、以前のSieve実行中に「重複」テストによって表示されたメッセージを追跡します。基本的な形式では、テストはメッセージのMessage-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.
副次的な影響として、「重複」テストでは、Sieveの実行が正常に完了すると、一意のIDが内部の重複追跡リストに追加されます。特定の一意のIDが初めて表示されたときは、メッセージは重複せず、一意のIDが追跡リストに追加されます。今後のSieve実行で追跡リストに一意の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が追加されると、Sieveスクリプト内のすべての「重複」テストで、同じメッセージの次の配信試行で誤って「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.
ただし、追跡リストの最終的な変更をSieveスクリプトの実行が成功するまで延期することには問題がないわけではありません。追跡リストが更新される前に重複メッセージが並行して配信されると、競合状態が発生する可能性があります。この方法では、「重複」テストによって重複メッセージが見落とされる可能性があります。より複雑な実装では、ロックメカニズムを使用してこの問題を回避できます。しかし、どの実装が選択されたかに関係なく、「重複」テストが誤って「真」をもたらす状況は防止されなければなりません（MUST）。
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.
「重複」テストでは、Sieveスクリプトの以前の実行で検出された一意のID値の重複のみをチェックする必要があります。現在のSieveスクリプト実行の早い段階で検出されたID値を潜在的な重複と見なしてはなりません。つまり、 "include" [INCLUDE]拡張を使用してインクルードされたスクリプトにあるものを含め、Sieveスクリプト実行のすべての "重複"テストは、引数が同一の場合、常に同じ結果を生成する必要があります。
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で要求されているように、Message-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はメッセージのMessage-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.
「：header」引数のヘッダー名パラメーターの構文規則は、RFC 5228 [SIEVE]のセクション2.4.2.2で指定されています。実装は、無効なヘッダー名に対してエラーをトリガーしてはならないことに注意してください。代わりに、この場合、「重複」テストは無条件に「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 [SIEVE]のセクション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 [SIEVE]のセクション2.7.2を参照）。変換できない場合、値は変更されません。
o Trim leading and trailing whitespace from the header value (see Section 2.2 of RFC 5228 [SIEVE]).
o ヘッダー値から先頭と末尾の空白を削除します（RFC 5228 [SIEVE]のセクション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」引数なしの基本的な「複製」テストで使用されるMessage-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値が使用できないため、このテストでは重複追跡リストは変更されません。 "：header"または "：uniqueid"引数なしの基本的な "duplicate"テストのMessage-IDヘッダーフィールドに関しても、同じルールが適用されます。これは、ヘッダーフィールドが欠落しているか、複数回発生する可能性があるためです。
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値を追跡する必要があります。つまり、重複追跡リストのすべての値は、Message-IDヘッダーフィールドから取得されたか、「：header」引数を使用して指定された任意のヘッダーから取得されたか、または「 ：uniqueid "引数。次の3つの例は同等であり、重複追跡リストの同じエントリに一致します。
require "duplicate";
if duplicate {
discard;
}
require "duplicate";
if duplicate :header "message-id" {
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」引数が異なるか省略されている他の「duplicate」テストから「duplicate」テストを分離します。 「：handle」引数を使用すると、関連のない「重複」テストが互いに干渉するのを防ぐことができます。追跡された一意のIDが以前の「重複」テストによる以前のスクリプト実行で以前に見られた場合、メッセージは重複としてのみ認識されます同じ "：handle"引数。
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.
注：重複メッセージを追跡するために必要なメカニズムは、「休暇」アクション[休暇]の重複応答を追跡するために必要なメカニズムと非常に似ています。したがって、「重複」テストに必要なメカニズムを実装する1つの方法は、追跡された一意の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.
実装では、追跡リストのエントリが短時間で期限切れになるようにする必要があります（SHOULD）。ユーザーは、タイムアウト値を秒単位で指定する整数値を受け入れる "：seconds"引数を使用して、この有効期限の長さを明示的に制御できます。 「：seconds」引数を省略する場合は、適切なデフォルト値を使用する必要があります。通常、デフォルトの有効期限は約7日です。サイトは有効期限に最大制限を課すべきです（SHOULD）。その制限が "：seconds"引数によって超過された場合、最大値は黙って置き換えられなければなりません（MUST）。制限を超えてもエラーが発生してはなりません。 「：seconds」引数がゼロの場合、「重複」テストは無条件に「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」引数が省略されている場合、重複追跡リスト内のエントリの有効期限は、エントリが最初に作成されたとき（つまり、「重複」テストは、特定の一意の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"引数を異なる複数の "重複"テストを評価するSieveスクリプトを作成することが可能です。結果の動作はこの仕様では定義されていないため、このような構成は避けてください。実装は、最後に評価された「重複」テストからの「：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.
"duplicate"テストは、 "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".
通常、Sieveスクリプトは最終配信時に実行されます。ただし、「imapsieve」[IMAPSIEVE]拡張機能を使用すると、IMAP [IMAP]サーバーがメッセージストアで操作を実行すると（たとえば、メッセージがアップロード、フラグ設定、または別の場所に移動された場合）、Sieveスクリプトが呼び出されます。 「重複」テストは、最終的な配信で使用するために考案されたものであり、「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.
この基本的な例では、Message-IDヘッダーフィールドを追跡することにより、メッセージの重複が検出されます。重複した配信は、ユーザーのゴミ箱フォルダに含まれる特別なフォルダに保存されます。フォルダが存在しない場合は、「メールボックス」[メールボックス]拡張子を使用して自動的に作成されます。このようにして、ユーザーは必要に応じてメッセージを回復することができます。重複として認識されないメッセージは、通常どおりユーザーの受信トレイに保存されます。
require ["duplicate", "fileinto", "mailbox"];
require ["duplicate"、 "fileinto"、 "mailbox"];
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:
この例は、「複製」テストのより複雑な使用法を示しています。ユーザーは、一連のリモート自動監視システムからネットワークアラートを受け取ります。異なる監視システムから同じイベントに関するいくつかの通知を受け取ることができます。これらはすべて異なる送信者からの個別のメッセージであるため、これらのメッセージのMessage-IDヘッダーフィールドは異なります。同じイベントに関する複数回の通知を受け取らないように、ユーザーは次のスクリプトを記述します。
require ["duplicate", "variables", "imap4flags", "fileinto"];
require ["duplicate"、 "variables"、 "imap4flags"、 "fileinto"];
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.
通知メッセージの件名は、イベントの説明を含む予測可能なパターンで構成されています。上記のスクリプトでは、「重複」テストを使用して、重複したアラートイベントを検出しています。メッセージの件名はパターンと照合され、イベントの説明は「変数」[変数]拡張を使用して抽出されます。件名にそのイベントが含まれるメッセージが以前に受信されてから1分以上経過している場合、指定された "：seconds"引数により、そのメッセージは重複として検出されません。重複した場合、メッセージは「imap4flags」[IMAP4FLAGS]拡張を使用して「seen」としてマークされます。すべてのアラートメッセージは、それらが重複しているかどうかに関係なく、「アラート」メールボックスに入れられます。
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]拡張を使用して送信される通知の頻度を制限する方法を示しています。次のシナリオを検討してください。メールユーザーがSieveを介して新着メールに関するExtensible Messaging and Presence Protocol（XMPP）通知[NOTIFY-XMPP]を受信しますが、単一の連絡先が短時間に多くのメッセージを送信する場合があります。ここで、ユーザーはこれらすべてのメッセージの通知を受け取らないようにしたいと考えています。ユーザーは、各ユーザーからのメッセージについて最大30分に1回の通知を受け取りたいと考えており、次のスクリプトを記述します。
require ["variables", "envelope", "enotify", "duplicate"];
require ["variables"、 "envelope"、 "enotify"、 "duplicate"];
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";
}
The example shown above uses the message envelope sender rather than the Message-ID header field as the unique ID for duplicate tracking.
上記の例では、重複追跡の一意のIDとして、Message-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"];
require ["variables"、 "envelope"、 "enotify"、 "duplicate"];
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";
}
This uses a combination of the message envelope sender and the
subject of the message as the unique ID for duplicate tracking.
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.
この例では、メールユーザーは2つの異なるアプリケーションに対して「重複」テストを使用します。通知システムからの重複イベントを破棄し、ソフトウェアサポートの特定のフォローアップメッセージを「imap4flags」を使用して「seen」としてマークします[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.
次の例の2つの「重複」テストは、それぞれ異なるヘッダーを使用してメッセージを識別します。ただし、これらの「X-Event-ID」ヘッダーと「X-Ticket-ID」ヘッダーは、この場合同様の値（たとえば、両方ともタイムスタンプに基づく）を持つ可能性があります。つまり、1つの「重複」テストでは、他によって追跡されるID値。したがって、ユーザーは、2番目の「重複」テストが最初の「重複」テストで追跡されたID値と一致しないようにしたいと考えています。逆も同様です。これは、これらのテストに異なる "：handle"引数を指定することで実現されます。
require ["duplicate", "imap4flags"];
require ["duplicate"、 "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";
}
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.
一意のメッセージが殺到すると、重複追跡リストが無制限に大きくなる可能性があります。したがって、実装では、重複追跡リストのエントリ数を制限する必要があります（SHOULD）。エントリ数を制限する場合、実装は最も古いエントリを最初に破棄する必要があります（SHOULD）。
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 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が必ずしも一意であるとは限らないことに注意してください。無害なジェネレーターまたは攻撃者が、Sieveフィルターの前のある時点で重複Sieveフィルターで使用されるプロパティを使用してメッセージを挿入したためです。したがって、重複するメッセージがメッセージ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節の最後の注を参照）によって情報を覆い隠すことによって、および/またはメッセージ自体と同等のアクセス制御のレベルで情報を格納することによって、その情報を保護する必要があります（SHOULD）。
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:
次のテンプレートは、このドキュメントで指定されているSieve拡張のIANA登録を指定しています。
To: iana@iana.org Subject: Registration of new Sieve extension
宛先：iana@iana.org件名：新しいSieve拡張の登録
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説明：特定のメッセージが重複しているかどうか、つまり、Sieveスクリプトを実行している配信エージェントによってメッセージのコピーが以前に見られたかどうかをテストするために使用できるテスト「duplicate」を追加します。 RFC番号：RFC 7352連絡先アドレス：Sieveメーリングリスト<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>にあるSieve拡張のリストに追加されました。
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。、「Sieve Email Filtering：Date and Index Extensions」、RFC 5260、2008年7月。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[画像] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、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.
[INCLUDE] Daboo、C。およびA. Stone、「Sieve Email Filtering：Include Extension」、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.
[SIEVE] Guenther、P。およびT. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年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 Email Filtering：MIME Part Tests、Iteration、Extraction、Replacement、and Enclosure」、RFC 5703、2009年10月。
[VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[変数] Homme、K。、「Sieve Email Filtering：Variables Extension」、RFC 5229、2008年1月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[IMAP4FLAGS] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008.
[IMAP4FLAGS] Melnikov、A。、「Sieve Email Filtering：Imap4flags Extension」、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。、「The Sieve Mail-Filtering Language-Extensions for Checking Mailbox Status and Accessing Mailbox Metadata」、RFC 5490、2009年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、「Sieve Email Filtering：Extension for Notifications」、RFC 5435、2009年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、「Sieve Notification Mechanism：Extensible Messaging and Presence Protocol（XMPP）」、RFC 5437、2009年1月。
[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[VACATION] Showalter、T。およびN. Freed、「Sieve Email Filtering：Vacation Extension」、RFC 5230、2008年1月。
Author's Address
著者のアドレス
Stephan Bosch Enschede NL
ステファンボッシュエンスヘーデNL
EMail: stephan@rename-it.nl