Subject: Re: [lemonade] IMAP-SIEVE

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 11:20:43 -0500

As a user, I like it.

On 7/31/07 5:21 AM, "Stephan Bosch" <[email-masked]> wrote:

> Eric Burger wrote:
>> Any comments on IMAP sieve?
>> 
>> http://tools.ietf.org/html/draft-ietf-lemonade-imap-sieve-03
>>  
> I don't know whether this is the correct time and place to post this
> suggestion, but I'll do it anyway. I apologize if the suggested
> functionality is not within the scope of this proposed IMAP extension
> (or lemonade for that matter).
> 
> IMAPSieve currently only suggests running sieve scripts when certain
> IMAP commands are executed, apart from running a sieve script upon
> delivery. What I currently miss in the Sieve world is the ability for a
> client to simply run a sieve script on a folder when requested by the
> user (i.e. by issueing a new IMAP command). Many mail clients that
> support some form of filtering also include functionality to apply the
> currently defined filters on a specific folder or a set of messages.
> This is especially useful when the current filterset has misdelivered a
> large number of messages to a specific folter; the user can fix this by
> updating the filters accordingly and applying the filters to the folder
> in question. Of course the mail client could do this using a sequence of
> IMAP commands, but this does not test the new Sieve script on the server.
> 
> Just a thought...
> 
> Regards,
> 
> --
> Stephan Bosch
> [email-masked]
> 
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Eric Burger <[email-masked]>
Date: Wed, 01 Aug 2007 11:20:43 -0500

As a user, I like it.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Aug 2007 15:14:40 -0700

At 2:21 PM +0200 7/31/07, Stephan Bosch wrote:

>  IMAPSieve currently only suggests running sieve scripts when 
> certain IMAP commands are executed, apart from running a sieve 
> script upon delivery. What I currently miss in the Sieve world is 
> the ability for a client to simply run a sieve script on a folder 
> when requested by the user (i.e. by issueing a new IMAP command). 
> Many mail clients that support some form of filtering also include 
> functionality to apply the currently defined filters on a specific 
> folder or a set of messages. This is especially useful when the 
> current filterset has misdelivered a large number of messages to a 
> specific folter; the user can fix this by updating the filters 
> accordingly and applying the filters to the folder in question. Of 
> course the mail client could do this using a sequence of IMAP 
> commands, but this does not test the new Sieve script on the server.

This would be useful.  Perhaps the way to proceed would be to write a 
new draft that is an extension to IMAP and IMAPSieve that executes a 
specified Sieve script (specified by its metadata item) on a set of 
messages?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Two things are infinite: the universe and human stupidity;
and I'm not even sure about the universe.
                                        --Albert Einstein

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Aug 2007 15:40:11 -0700

As promised (or threatened), here is a proposal for modifying the 
IMAP-Sieve draft to accomodate per-client scripts:

In Section 2.3.1:

OLD:
    When an applicable event occurs on an IMAP mailbox, if there is an
    IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that
    entry is used.  If there is not, but there is an IMAP metadata entry
    named "/IMAPSieve/Script" for the server, that entry is used
    (providing a way to define a gobal script for all mailboxes on a
    server).  If neither entry exists, then no script will be invoked.

NEW:
    When an applicable event occurs on an IMAP mailbox, all IMAP
    metadata entries below the "/IMAPSieve/Script/client/" hierarchy
    for the mailbox are run.  If no per-client scripts exist, the
    implementation checks for an IMAP metadata entry named
    "/IMAPSieve/Script" first on the mailbox, and second on the
    server.  If one is found, it is used.  This provides for
    per-client scripts on each mailbox, with a generic per-mailbox
    script, and a global script for all mailboxes on a server as
    defaults.  If none exist, then no script is invoked.

    The entry name below ""/IMAPSieve/Script/client/" SHOULD be
    named <client-id>.<script-id>.  For example, "Eudora.FC2302".

----------

OLD:
    Only one Sieve script may be defined per mailbox, eliminating the
    complexity and possible ambiguity involved with coordinating the
    results of multiple scripts.  Any sub-filtering is done in the Sieve
    script.  For example, if it's only necessary to deal with flag
    changes, but not with new messages appended or copied, the Sieve
    script will still be invoked for all events, and the script is
    responsible for checking the event type.

NEW:
    Multiple Sieve script may be defined per mailbox, allowing each
    client to create a small scripts to serve the user, with freedom
    to modify or delete its script at any time.

    Any sub-filtering is done in the Sieve script.  For example, if
    it's only necessary to deal with flag changes, but not with new
    messages appended or copied, the Sieve script will still be
    invoked for all events, and the script is responsible for
    checking the event type.

----------

In multiple sections, the text "The implementation MAY then expunge 
the original message" should be replaced with "After all Sieve 
scripts have run, the implementation MAY then expunge the original 
message".  This allows each Sieve script to operate on the message. 
One or more of the scripts may mark the message as \deleted, and 
after all have run, the message MAY be expunged.

----------

I also suggest adding a new section, called something such as 
"Automatic Deletion of Old Scripts":

    Implementations MAY keep track of the modification date of each
    script under the "/IMAPSieve/Script/client/" hierarchy of each
    mailbox.  Any script that is older than an implementation-defined
    period MAY be removed.  The expiration period SHOULD be at least
    ninety days.  This allows implementations to prune scripts
    created by clients no longer in use.

    Clients SHOULD refresh their scripts at least every eighty days.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Performance is easier to add than clarity.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Aug 2007 15:43:21 -0700

Currently, the drafts says (in Section 2.3.1):

    This specifies the mechanism for "activating" a script for a given
    mailbox (or for all mailboxes), but does not specify a mechanism for
    creating, storing, or validating the script.  Implementations MAY use
    [Manage] to acomplish this, using the PUTSCRIPT command to store the
    script without using the SETACTIVE command to activate it.  In any
    case, the script name that is specified in the /IMAPSieve/Script
    metadata entry is in a form that depends upon how the server handles
    the storing of Sieve scripts.

The problem with this is that the exact name is not specified nor 
standardized, so it isn't clear what clients should do, and it is 
also unclear how the scripts are to be managed.

In Chicago there were discussions about storing the script itself in 
a metadata entry, rather than, or in addition to, the script name. 
Presumably this requires the server to validate the script on 
storage, and reject invalid scripts immediately.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The fewer episodes of a TV show one has seen, the greater the chance
that one has already viewed the episode one is watching.
                                                   --Randall Gellens

---

From: Barry Leiba <[email-masked]>
Date: Fri, 17 Aug 2007 10:13:16 -0400

> IMAP commands are executed

Actually, that's not quite true.  IMAPSieve defines events that are 
triggered by IMAP commands.  Maybe I should make the text say that more 
clearly.

> What I currently miss in the Sieve world is the ability for a 
> user (i.e. by issueing a new IMAP command).

I think Randy has the right answer here: write a draft that extends IMAP 
and IMAPSieve... it creates a new IMAP command that generates an new 
IMAPSieve event.

Barry

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 11:27:13 +0300

Questions/comments:

What is the execution order of the scripts (last modification date/alphabetical/etc)? I am asking this because one script might move an email while another might notify it - which one happens first...

What if there are two scripts and: both want to send a notification, and to the same/different addresses? Which will be sent? Both?

The original text refers to these problems as: " complexity and possible ambiguity involved with coordinating the results of multiple scripts".
Should these problems be elaborated in more detail and - hopefully - provide a standardized behavior?
Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Randall Gellens [mailto:[email-masked]] 
>Sent: 14 August, 2007 01:40
>To: [email-masked]
>Cc: Barry Leiba
>Subject: [lemonade] IMAP-SIEVE: Per-Client Sieve Script
>
>As promised (or threatened), here is a proposal for modifying 
>the IMAP-Sieve draft to accomodate per-client scripts:
>
>In Section 2.3.1:
>
>OLD:
>In multiple sections, the text "The implementation MAY then 
>expunge the original message" should be replaced with "After 
>all Sieve scripts have run, the implementation MAY then 
>expunge the original message".  This allows each Sieve script 
>to operate on the message. 
>One or more of the scripts may mark the message as \deleted, 
>and after all have run, the message MAY be expunged.
>
>----------
>

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 11:32:46 +0300

One more question if I may:
How do You identify (uniquely) which script belongs to which client? I mean if we can't do this and clients keep overwriting each others' scripts (because they don't know which one belongs to them), we did not achieve anything, did we?

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Aug 2007 12:14:51 -0700

At 11:27 AM +0300 8/30/07, <[email-masked]> wrote:

>  Questions/comments:
>
>  What is the execution order of the scripts (last modification 
> date/alphabetical/etc)? I am asking this because one script might 
> move an email while another might notify it - which one happens 
> first...

My suggested text included:

>  After all Sieve scripts have run, the implementation MAY then 
> expunge the original message

This way, the message will remain in the folder while all scripts 
run, so multiple scripts may move it, resulting in the message 
effectively being copied.  As for modifications, existing text in the 
document says modifications don't show up to the script, so in effect 
they likewise take effect after all scripts have run.

>
>  What if there are two scripts and: both want to send a 
> notification, and to the same/different addresses? Which will be 
> sent? Both?

Yes.  Each scripts needs to operate independently.  Separately, as an 
optimization, an implementation could coalesce multiple notifications 
to the same address into a single notification.

>
>  The original text refers to these problems as: " complexity and 
> possible ambiguity involved with coordinating the results of 
> multiple scripts".

I have attempted to provide a standardized behavior.  If you feel 
more detail is needed, or that there is still ambiguity, please point 
out where.

At 11:32 AM +0300 8/30/07, <[email-masked]> wrote:

>  How do You identify (uniquely) which script belongs to which 
> client? I mean if we can't do this and clients keep overwriting 
> each others' scripts (because they don't know which one belongs to 
> them), we did not achieve anything, did we?

My suggested text included:

>     named <client-id>.<script-id>.  For example, "Eudora.FC2302".

Hence, each client is assigned a <client-id> through an IANA 
registry, perhaps an existing one, or a new one can be created.  Each 
client is free to choose a <script-id> of its own creation.  I was 
thinking that any identifier for the device could be used, but even a 
random number with a reasonable range would suffice.  There was never 
any intention of allowing clients to "keep overwriting each others' 
scripts (because they don't know which one belongs to them)" -- 
instead, the idea is to err on the side of possible extra scripts, 
perhaps because a client has forgotten its identifier.  Those 
obsolete scripts would eventually be reaped by the server, as 
described in my suggested text.

-------------- Randomly-selected tag: ---------------
The number of licorice gumballs you get out of a gumball machine
increases in direct proportion to how much you hate licorice.