Re: [sieve] Fwd: New Version Notification for draft-bosch-sieve-duplicate-02.txt Mon, 08 April 2013 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A53CB21F902D for <>; Sun, 7 Apr 2013 19:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HdoBuJDicSsJ for <>; Sun, 7 Apr 2013 19:09:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 37F7121F902C for <>; Sun, 7 Apr 2013 19:09:54 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 7 Apr 2013 19:04:51 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for; Sun, 7 Apr 2013 19:04:45 -0700 (PDT)
Message-id: <>
Date: Sun, 07 Apr 2013 15:23:38 -0700 (PDT)
In-reply-to: "Your message dated Sun, 07 Apr 2013 18:48:13 +0200" <>
References: <> <>
To: Stephan Bosch <>
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: Mon, 08 Apr 2013 02:09:54 -0000

> 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. In fact since the default
should be "relative to first" we can simply reuse the existing :last parameter
in use elsewhere.