Op 4/25/2013 11:44 PM, Ned Freed wrote:
>> 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.
>
> 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.
Yes, I agree with that.
BTW, any further comments on the document as it is now? More thoughts on
the ':last' issue?
No, not really. I think this draft is sufficiently mature at this point
that we should try and get it on track to become an RFC.
Barry and/or Pete, would it make sense to progress this through the appsawg?
I'd be happy to do the sheparding work.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve