doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7352.txt b/doc/rfc/rfc7352.txt
new file mode 100644
index 0000000..8cbd2a7
--- /dev/null
+++ b/doc/rfc/rfc7352.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+Bosch                        Standards Track                    [Page 1]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+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
+
+   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.
+
+   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).
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 2]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   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.
+
+2.  Conventions Used in This Document
+
+   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.
+
+3.  Test "duplicate"
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+Bosch                        Standards Track                    [Page 3]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 4]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+3.1.  Arguments ":header" and ":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:
+
+   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  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  When the ":uniqueid" argument is used, the unique ID is the string
+      parameter that is specified with the argument.
+
+   The ":header" and ":uniqueid" arguments are mutually exclusive;
+   specifying both for a single "duplicate" test command MUST trigger an
+   error.
+
+   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.
+
+   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:
+
+   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  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  Trim leading and trailing whitespace from the header value (see
+      Section 2.2 of RFC 5228 [SIEVE]).
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 5]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 6]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+3.2.  Argument ":handle"
+
+   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:
+
+   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.
+
+      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.
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 7]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+3.3.  Arguments ":seconds" and ":last"
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 8]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+3.4.  Interaction with Other Sieve Extensions
+
+   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.
+
+   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".
+
+4.  Sieve Capability Strings
+
+   A Sieve implementation that defines the "duplicate" test command will
+   advertise the capability string "duplicate".
+
+5.  Examples
+
+5.1.  Example 1
+
+   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.
+
+   require ["duplicate", "fileinto", "mailbox"];
+
+   if duplicate {
+     fileinto :create "Trash/Duplicate";
+   }
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                    [Page 9]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+5.2.  Example 2
+
+   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:
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                   [Page 10]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+5.3.  Example 3
+
+   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:
+
+   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.
+
+   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"];
+
+   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";
+   }
+
+
+
+
+Bosch                        Standards Track                   [Page 11]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   This uses a combination of the message envelope sender and the
+   subject of the message as the unique ID for duplicate tracking.
+
+5.4.  Example 4
+
+   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.
+
+   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.
+
+   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";
+   }
+
+6.  Security Considerations
+
+   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
+
+
+
+
+
+Bosch                        Standards Track                   [Page 12]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+7.  IANA Considerations
+
+   The following template specifies the IANA registration of the Sieve
+   extension specified in this document:
+
+      To: iana@iana.org
+      Subject: Registration of new Sieve extension
+
+      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>
+
+
+
+
+Bosch                        Standards Track                   [Page 13]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+   This information has been added to the list of Sieve extensions given
+   on <http://www.iana.org/assignments/sieve-extensions>.
+
+8.  Acknowledgements
+
+   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.
+
+9.  References
+
+9.1.  Normative References
+
+   [DATE-INDEX]
+              Freed, N., "Sieve Email Filtering: Date and Index
+              Extensions", RFC 5260, July 2008.
+
+   [IMAIL]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [IMAPSIEVE]
+              Leiba, B., "Support for Internet Message Access Protocol
+              (IMAP) Events in Sieve", RFC 6785, November 2012.
+
+   [INCLUDE]  Daboo, C. and A. Stone, "Sieve Email Filtering: Include
+              Extension", RFC 6609, May 2012.
+
+   [KEYWORDS]
+              Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SIEVE]    Guenther, P. and T. Showalter, "Sieve: An Email Filtering
+              Language", RFC 5228, January 2008.
+
+   [SIEVE-MIME]
+              Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
+              Tests, Iteration, Extraction, Replacement, and Enclosure",
+              RFC 5703, October 2009.
+
+   [VARIABLES]
+              Homme, K., "Sieve Email Filtering: Variables Extension",
+              RFC 5229, January 2008.
+
+
+
+
+
+
+
+Bosch                        Standards Track                   [Page 14]
+
+RFC 7352          Sieve: Detecting Duplicate Deliveries   September 2014
+
+
+9.2.  Informative References
+
+   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+              VERSION 4rev1", RFC 3501, March 2003.
+
+   [IMAP4FLAGS]
+              Melnikov, A., "Sieve Email Filtering: Imap4flags
+              Extension", RFC 5232, January 2008.
+
+   [MAILBOX]  Melnikov, A., "The Sieve Mail-Filtering Language --
+              Extensions for Checking Mailbox Status and Accessing
+              Mailbox Metadata", RFC 5490, March 2009.
+
+   [NOTIFY]   Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
+              "Sieve Email Filtering: Extension for Notifications",
+              RFC 5435, January 2009.
+
+   [NOTIFY-XMPP]
+              Saint-Andre, P. and A. Melnikov, "Sieve Notification
+              Mechanism: Extensible Messaging and Presence Protocol
+              (XMPP)", RFC 5437, January 2009.
+
+   [VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:
+              Vacation Extension", RFC 5230, January 2008.
+
+Author's Address
+
+   Stephan Bosch
+   Enschede
+   NL
+
+   EMail: stephan@rename-it.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bosch                        Standards Track                   [Page 15]
+