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

From: Stephan Bosch <[email-masked]>
Date: Sun, 07 Apr 2013 18:48:13 +0200

Hi,

I made a new version of the "duplicate" draft. It should address the 
comments by Ned, Kristin and Alexey. I added the example I gave to Alexey.

This resulted in quite a bit of restructuring in the description of the 
new test command, so it is best to review at least that section entirely.

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?

Regards,

Stephan.

Subject: New Version Notification for draft-bosch-sieve-duplicate-02.txt
From: [email-masked]
To: [email-masked]
Date: Sun, 07 Apr 2013 09:07:43 -0700

A new version of I-D, draft-bosch-sieve-duplicate-02.txt
has been successfully submitted by Stephan Bosch and posted to the
IETF repository.

Filename:	 draft-bosch-sieve-duplicate
Revision:	 02
Title:		 Sieve Email Filtering: Detecting Duplicate Deliveries
Creation date:	 2013-04-07
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-bosch-sieve-duplicate-02.txt
Status:          http://datatracker.ietf.org/doc/draft-bosch-sieve-duplicate
Htmlized:        http://tools.ietf.org/html/draft-bosch-sieve-duplicate-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-bosch-sieve-duplicate-02

Abstract:
   This document defines a new test command "duplicate" for the "Sieve"
   email filtering language.  This test adds the ability to detect
   duplicate message deliveries.  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 or other parts of the message.

The IETF Secretariat

---

From: [email-masked]
Date: Sun, 07 Apr 2013 15:23:38 -0700 (PDT)

> 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.

Thoughts?

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 10 Apr 2013 13:53:08 +0200

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?
 >
 > 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?

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 10 Apr 2013 13:56:26 +0200

Op 4/10/2013 1:53 PM, Stephan Bosch schreef:
> (lots of garbled mess)

Ok, sorry for the mess, this is the last time I use the Thunderbird 
Edit->Rewrap feature.

Regards,

Stephan.

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 10 Apr 2013 22:50:21 +0200

On 4/7/2013 6:48 PM, Stephan Bosch wrote:
> This resulted in quite a bit of restructuring in the description of 
> the new test command, so it is best to review at least that section 
> entirely.

One other thing: we recently defined this great new Sieve use-case 
called IMAPSieve. Is there any application imaginable for the duplicate 
test in this context, i.e. do we want to allow it there? Either way, I 
think we should state its applicability explicitly.

Regards,

Stephan.

---

From: [email-masked]
Date: Thu, 25 Apr 2013 14:44:27 -0700 (PDT)

> think we should state its applicability explicitly.

I think there are legitimate use-cases, but it's also incredibly easy to misuse
in this context.

The basic problem is that moving messages around in IMAP doesn't carry with it
any sort of inherent special semantic and people move messages around for all
sorts of reasons (or for no real reason at all). This is quite unlike message
delivery.

So, for example, you could define a Sieve in IMAP to prevent, say, the
inclusion of a second copy of the same message in a given folder. But bad
things are going to happen if, say, you forget the filter is there and move
some of the messages out and back in a couple of times.

We'd have to extend the semantics of the extension substantiantially to take
care of this, and even if we were to do that actually using it would be
very tricky indeed.

Since I see the main benefit of this extension as how simple it makes
duplicate checks in Sieve, this usage makes me very nervous, so nervous
that I could certainly accept a "NOT RECOMMENDED" label for this case.

				Ned