Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02

From: Ned Freed <[email-masked]>
Date: Sat, 01 Feb 2014 10:09:59 -0800 (PST)

Having thought about this a bit more, it occurs to me that a common thread that
underlies at least some of the discussion here isn't the need to provide deep
background on the general workings of sieve, but rather that correct use of
this extension depends on an understanding of the inherently asynchronous
nature of email. In particular, you cannot depend on a message from a list
arriving before or after an individual copy, and you cannot depend on alerts
from multiple sources arriving in a particular order.

Arnt pointed out the list/individual copy issue earlier, and Robert's example
where some alerts have critical information attached and others don't touches
on the latter issue. And generally it would be easy for users to mistakenly
assume that they can depend on message ordering.

As a rule I object to reiterating or summarizing technical material in other
specifications, mostly because it tends to lose something in the translation.
But this is, AFAIK, a new issue: We've defined mechanisms like vacation before
that maintain state across messages, but this is the first sieve mechanisms
that exposes such a mechanism directly to the end user.

My suggestion would be to add an example of how *not* to use duplicate. The
obvious one would be a usage that attempts to block individual cc's of
list mail. (Such an example can be found in the earlier discussion.)

Beyond that, I'm still at a loss as to what, if anything, needs to be added.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 01 Feb 2014 16:52:06 -0800

Hi Ned,

> Beyond that, I'm still at a loss as to what, if anything, needs to be

I think the current spec does the best that it can do to address a common 
problem at delivery time, but as noted in this thread, that may not be 
enough to cover more complex situations. What we could do in the future is 
go a step further and improve handling of duplicates post delivery - i.e. 
within the mail store (IMAP).

So perhaps what is needed is a complementary specification that adds 
improved duplicate handling to IMAP. The obvious use case is to have IMAP 
flag changes  applies across duplicate messages. This covers the common 
case of receiving the same message directly and via a list and wanting to 
"process" it (from the human perspective) only once. I suspect there are a 
lot of awkward scenarios that would need to be handled (e.g. what if a flag 
change is done when the first message arrives - should that change 
automatically apply when the duplicate is delivered). However, this might 
be worthwhile to consider - though it certainly should not block sieve 
duplicate from proceeding.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Feb 2014 09:12:22 -0800 (PST)

> duplicate from proceeding.

I don't quite see what duplicating flag changes would accomplish - it seems to
me that you really need to actually consolidate the two copies of the message 
in some way - but I am in complete agreement that some kinds of duplicate
elimination can only be made to work at the store level. And that's far beyond
the purview of hte present draft.

Whether or not that's implementable/deployable is another matter, of course.

				Ned