dovecot-2.2-pigeonhole: doc: Removed obsolete vnd.dovecot.duplic...
pigeonhole at rename-it.nl
pigeonhole at rename-it.nl
Wed Sep 23 19:54:49 UTC 2015
details: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/44fa661402b7
changeset: 2101:44fa661402b7
user: Stephan Bosch <stephan at rename-it.nl>
date: Wed Sep 23 21:54:39 2015 +0200
description:
doc: Removed obsolete vnd.dovecot.duplicate specification sources.
diffstat:
doc/rfc/xml/reference.IMAP4FLAGS.xml | 15 -
doc/rfc/xml/reference.MAILBOX.xml | 15 -
doc/rfc/xml/reference.VACATION.xml | 17 -
doc/rfc/xml/spec-bosch-sieve-duplicate.xml | 260 -----------------------------
4 files changed, 0 insertions(+), 307 deletions(-)
diffs (truncated from 323 to 300 lines):
diff -r b189a305d045 -r 44fa661402b7 doc/rfc/xml/reference.IMAP4FLAGS.xml
--- a/doc/rfc/xml/reference.IMAP4FLAGS.xml Wed Sep 23 21:50:10 2015 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,15 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-
-<reference anchor='IMAP4FLAGS'>
-
-<front>
-<title>Sieve Email Filtering: Imap4flags Extension</title>
-<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
-<organization /></author>
-<date year='2008' month='January' />
-<abstract>
-<t>Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.</t><t> This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]</t></abstract></front>
-
-<seriesInfo name='RFC' value='5232' />
-<format type='TXT' octets='21964' target='http://www.rfc-editor.org/rfc/rfc5232.txt' />
-</reference>
diff -r b189a305d045 -r 44fa661402b7 doc/rfc/xml/reference.MAILBOX.xml
--- a/doc/rfc/xml/reference.MAILBOX.xml Wed Sep 23 21:50:10 2015 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,15 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-
-<reference anchor='MAILBOX'>
-
-<front>
-<title>The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata</title>
-<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
-<organization /></author>
-<date year='2009' month='March' />
-<abstract>
-<t>This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]</t></abstract></front>
-
-<seriesInfo name='RFC' value='5490' />
-<format type='TXT' octets='16065' target='http://www.rfc-editor.org/rfc/rfc5490.txt' />
-</reference>
diff -r b189a305d045 -r 44fa661402b7 doc/rfc/xml/reference.VACATION.xml
--- a/doc/rfc/xml/reference.VACATION.xml Wed Sep 23 21:50:10 2015 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,17 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-
-<reference anchor='VACATION'>
-
-<front>
-<title>Sieve Email Filtering: Vacation Extension</title>
-<author initials='T.' surname='Showalter' fullname='T. Showalter'>
-<organization /></author>
-<author initials='N.' surname='Freed' fullname='N. Freed'>
-<organization /></author>
-<date year='2008' month='January' />
-<abstract>
-<t>This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]</t></abstract></front>
-
-<seriesInfo name='RFC' value='5230' />
-<format type='TXT' octets='29822' target='http://www.rfc-editor.org/rfc/rfc5230.txt' />
-</reference>
diff -r b189a305d045 -r 44fa661402b7 doc/rfc/xml/spec-bosch-sieve-duplicate.xml
--- a/doc/rfc/xml/spec-bosch-sieve-duplicate.xml Wed Sep 23 21:50:10 2015 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,260 +0,0 @@
-<?xml version="1.0" encoding="US-ASCII"?>
-
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
-
-<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-<!-- used by XSLT processors -->
-<?rfc strict="yes" ?>
-<?rfc toc="yes"?>
-<?rfc tocdepth="4"?>
-<?rfc symrefs="yes"?>
-<?rfc sortrefs="yes" ?>
-<?rfc compact="yes" ?>
-<?rfc subcompact="no" ?>
-<?rfc private="Pigeonhole Project" ?>
-
-<rfc category="info" docName="spec-bosch-sieve-duplicate">
-<!-- ***** FRONT MATTER ***** -->
-
-<front>
-<title abbrev="Sieve: Detecting Duplicate Deliveries">
-Sieve Email Filtering: Detecting Duplicate Deliveries
-</title>
-
-<author fullname="Stephan Bosch" initials="S." surname="Bosch">
- <organization/>
- <address>
- <postal>
- <street></street>
- <city>Enschede</city>
- <country>NL</country>
- </postal>
- <email>stephan at rename-it.nl</email>
- </address>
-</author>
-
-<date/>
-
-<area>General</area>
-<workgroup>Pigeonhole Project</workgroup>
-<keyword>sieve</keyword>
-<keyword>duplicate deliveries</keyword>
-
-<abstract>
-<t>This document defines a new vendor-defined test command "duplicate" for the
-"Sieve" email filtering language. It can be used to test whether a particular
-string value is a duplicate, i.e. whether it was seen before by the delivery
-agent that is executing the Sieve script. The main application for this new test
-is detecting duplicate message deliveries commonly caused by mailing list
-subscriptions or redirected mail addresses.</t>
-</abstract>
-</front>
-
-<middle>
-
-<section title="Introduction">
-<t>This is an extension to the Sieve filtering language defined by
-<xref target="SIEVE">RFC 5228</xref>. It adds a test to determine whether a
-certain string value 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.</t>
-
-<t>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 get a copy of the message
-directly and through mailing list. Also, if someone cross-posts over several
-mailing lists to which the user is subscribed, the user will 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
-receive more than a single copy. Using the "vnd.dovecot.duplicate" extension,
-users have the means to detect and handle such duplicates, e.g. by discarding
-them or putting them in a special folder.</t>
-
-<t>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 (weaker) criteria for defining what makes
-a message a duplicate, for example based on the subject line. Also, other
-applications of this new test command are possible, as long as the tracked
-value is a string.</t>
-
-<t>This extension is specific to the Pigeonhole Sieve implementation for the
-Dovecot Secure IMAP server. It will therefore most likely not be supported by
-web interfaces and GUI-based Sieve editors.</t>
-</section>
-
-<section title="Conventions Used in This Document">
-<t>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 <xref target="KEYWORDS"/>.</t>
-<t>Conventions for notations are as in <xref target="SIEVE"/> Section 1.1,
-including use of the "Usage:" label for the definition of action and tagged
-arguments syntax.</t>
-</section>
-
-<section title="Test "duplicate"">
-<?rfc needLines="4" ?>
-<figure>
-<artwork><![CDATA[
-Usage: "duplicate" [":seconds" <timeout: number>]
- [":header" <header-name: string> /
- ":value" <value: string>]
- [":handle" <handle: string>]
-]]></artwork>
-</figure>
-
-<t>The "duplicate" test keeps track of which values were seen before by this
-test in an earlier execution of this Sieve script. In its basic form, the tested
-value is the content of the Message-ID header of the message. This way, this
-test can be used to detect duplicate deliveries of the same message. It can also
-detect duplicate deliveries based on other message header fields if requested
-and it can even use a user-provided string value, e.g. as composed from text
-extracted from the message using the "variables" <xref target="VARIABLES"/>
-extension.</t>
-
-<t>The "duplicate" test evaluates to "true" when the provided value was seen
-before in an earlier Sieve execution for a previous message delivery. If the
-value was not seen earlier, the test evaluates to "false".</t>
-
-<t>As a side-effect, the "duplicate" test adds the evaluated value to an
-internal duplicate tracking list, so that the test will evaluate to "true" the
-next time the Sieve script is executed and the same value is encountered.
-Note that the "duplicate" test MUST only check for duplicates amongst values
-encountered in previous executions of the Sieve script; it MUST NOT consider
-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"
-<xref target="INCLUDE"/> extension, MUST yield the same result if the arguments
-are identical.</t>
-
-<t>Implementations MUST prevent adding values to the internal duplicate tracking
-list when the Sieve script execution fails. For example, this can be implemented
-by deferring the definitive modification of the tracking list to the end of the
-Sieve script execution. If failed script executions would add values to the
-duplicate tracking list, all "duplicate" tests would erroneously yield "true"
-for the next delivery attempt of the same message, which can -- depending on the
-action taken for a duplicate -- easily lead to discarding the message without
-further notice.</t>
-
-<t>Implementations SHOULD limit the number of values (and thereby messages) that
-are tracked. Also, implementations SHOULD let entries in the value 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. If the ":seconds"
-argument is omitted, an appropriate default MUST be used. Sites SHOULD impose a
-maximum limit on the expiration time. If that limit is exceeded, the maximum
-value MUST silently be substituted; exceeding the limit MUST NOT produce an
-error.</t>
-
-<t>By default, the tracked value is the content of the message's Message-ID
-header field. For more advanced purposes, the content of another header can be
-chosen for tracking by specifying the ":header" argument. The tracked string
-value can also be specified explicitly using the ":value" argument. The
-":header" and ":value" arguments are mutually exclusive and specifying both for
-a single "duplicate" test command MUST trigger an error at compile time. If the
-value is extracted from a header, i.e. when the ":value" argument is not used,
-leading and trailing whitespace (see Section 2.2 of
-<xref target="SIEVE">RFC 5228</xref>) MUST first be trimmed from the value
-before performing the actual duplicate verification.</t>
-
-<t>Using the ":handle" argument, the duplicate test can be employed for multiple
-independent purposes. Only when the tracked value was seen before in an earlier
-script execution by a "duplicate" test with the same ":handle" argument, it is
-recognized as a duplicate.
-</t>
-
-<t>NOTE: The necessary mechanism to track duplicate messages is very similar to
-the mechanism that is needed for tracking duplicate responses for the "vacation"
-<xref target="VACATION"/> action. One way to implement the necessary mechanism
-for the "duplicate" test is therefore to store a hash of the tracked value and,
-if provided, the ":handle" argument.</t>
-</section>
-
-<section title="Sieve Capability Strings">
-<t>A Sieve implementation that defines the "duplicate" test command
-will advertise the capability string "vnd.dovecot.duplicate".
-</t>
-</section>
-
-<section title="Examples">
-<t>In the following basic example, message duplicates are detected by tracking
-the Message-ID header. 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" <xref target="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.
-</t>
-
-<?rfc needLines="7" ?>
-<figure>
-<artwork><![CDATA[
-require ["vnd.dovecot.duplicate", "fileinto", "mailbox"];
-
-if duplicate {
- fileinto :create "Trash/Duplicate";
-}
-]]></artwork>
-</figure>
-
-<t>The next example shows a more complex use of the "duplicate" test. The user
-gets network alerts from a set of remote automated monitoring systems. Multiple
-notifications can be received about the same event from different monitoring
-systems. The Message-ID of these messages is different, because these are all
-distinct messages from different senders. To avoid being notified multiple times
-about the same event the user writes the following script:</t>
-
-<?rfc needLines="9" ?>
-<figure>
-<artwork><![CDATA[
-require ["vnd.dovecot.duplicate", "variables", "imap4flags",
- "fileinto"];
-
-if header :matches "subject" "ALERT: *" {
- if duplicate :seconds 60 :value "${1}" {
- setflag "\\seen";
- }
- fileinto "Alerts";
-}
-]]></artwork>
-</figure>
-
-<t>The subjects of the notification message are structured with a predictable
-pattern which 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" <xref target="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 the
-event of a duplicate, the message is marked as seen using the "imap4flags"
-<xref target="IMAP4FLAGS"/> extension. All alert messages are put into the
-"Alerts" mailbox irrespective of whether those messages are duplicates or not.
-</t>
-
-</section>
-
-<section anchor="Security" title="Security Considerations">
-<t>A flood of unique messages could cause the list of tracked values to
-grow indefinitely. Implementations therefore SHOULD implement limits on the
-number and lifespan of entries in that list.</t>
More information about the dovecot-cvs
mailing list