Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt

Stephan Bosch <> Wed, 10 April 2013 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD37121F940F for <>; Wed, 10 Apr 2013 04:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.503
X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IU6AuzTJJcWU for <>; Wed, 10 Apr 2013 04:53:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C4CC121F9410 for <>; Wed, 10 Apr 2013 04:53:27 -0700 (PDT)
Received: from ([]:50259) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1UPtac-0005ke-SQ; Wed, 10 Apr 2013 13:53:25 +0200
Message-ID: <>
Date: Wed, 10 Apr 2013 13:53:08 +0200
From: Stephan Bosch <>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Ned Freed <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------000007020208050003040803"
X-RenameIT-MailScanner-SpamScore: -2.3 (--)
X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00, HTML_MESSAGE autolearn=ham version=3.3.1
Cc: Sieve mailing list <>
Subject: Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIEVE Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2013 11:53:34 -0000

Op 4/8/2013 12:23 AM, Ned Freed schreef:
>> There is one thing I  thought of and haven't addressed so far. My
 >> current implementation makes a new entry in the duplicate tracking
 >> list irrespective of whether one exists already, overwriting the
 >> old one and thereby resetting the expiry time to whatever is
 >> configured using ":seconds". This will make example 3 in the draft
 >> yield unexpected results; if duplicates arrive within the expiry
 >> time, the total expiry time is in effect extended. The semantic
 >> difference here is that the expiry time is either measured relative
 >> to the initial message or relative to the last duplicate. This
 >> means that the 30 minutes in the example can stretch indefinitely
 >> if duplicates keep arriving before the expiry deadline. So, for the
 >> scenario of example 3, such behavior is quite obviously wrong.
 >> However, would there be an application for having the expiry time
 >> be relative to the last message received with the specified ID
 >> rather than the initial one? How would we accommodate for that?
 > I should have given this more consideration.
 > The difference between timeouts "relative to first" and "relatve to
 > last" seems significant enough to me to provide a means to control
 > it. It's certainly easy enough for me to accomodate in my
 > implementation.

I agree.

> In fact since the default  should be "relative to first" we can simply
 > reuse the existing :last parameter in use elsewhere.

Would we make allowing the presence of :last dependent on :seconds (much 
like :index) ?

Alternatives I can think of:

:refresh, :update, :renew - with the semantic interpretation that the 
entry in the tracking list is being updated/refreshed/renewed.

Anyone else suggestions?