[PROPOSAL] Sieve for shared mailboxes

[Ken Murchison]

Cyrus Daboo wrote:

> Hi Ken,
> 
> --On Tuesday, July 8, 2003 9:59 AM -0400 Ken Murchison <ken at oceana.com> 
> wrote:
> 
> | In the past, people have requested the ability to run sieve scripts when
> | messages are posted directly to shared mailboxes (via +detail
> | addressing).  I have suggested that this would be possible by associating
> | a script with the 'postuser' (typically "bb" or ""), but this was deemed
> | unacceptable as people wanted more fine grained control over which
> | mailboxes would have the script run.
> |
> | Now that Cyrus 2.2 has support for mailbox annotations, I believe that we
> | can provide the functionality that people desire.  I propose the
> | following:
> |
> | We will create a new "/vendor/cmu/cyrus-imapd/sieve" shared annotation
> | which can only be set by an admin.  Whenever a message is posted directly
> | to a shared mailbox, the script specified by the /sieve annotation (if
> | any) will be run.
> |
> | Question: Should the annotation be inherited by child mailboxes?  This
> | would allow the same script to be run on an entire hierarchy by only
> | setting one annotation.
> 
> Inheritance may be wanted (I suspect a lot of people will want that 
> given that I know a lot of people have requested various mailbox 
> inheritance behaviours in Mulberry). I think you will need to add 
> another annotation to turn on or off inheritance for all children: 
> "/vendor/cmu/cyrus-imapd/sieve-inherit" with values "true" or "false". 

Yes.  There needs to be a mechanism for disabling inheritance.


> The server would have to manage the inheritance behaviour itself since 
> ANNOTATEMORE does not have inheritance built-in (this does beg the 
> question as to whether ANNOTATEMORE should have inheritance built-in but 
> that will add a lot of complexity). The question is whether to make 
> inheritance the default or not.

Yeah, we're already managing inheritance internally for a 
/vendor/cmu/cyrus-imapd/expire annotation.  I don't think that adding it 
to the spec is necessary.


> Also note that this has to also work by adding a script to a \NoSelect 
> mailbox (i.e. one that is a 'directory' rather than a message container) 
> - but ANNOTATEMORE requires that to be supported.

Correct.  Did you see Rob's message on imapext concerning this?

> 
> Does a SIEVE fileinto constitute a 'post' operation that would trigger 
> an attached script? If so, then you need to make sure loops are prevented.

I hadn't anticipated fileinto triggering the script (no different than 
user scripts).
> 


> What about IMAP APPEND? Does that trigger the script? It really ought to 
> as well.

I hadn't anticipated this.  What would be the need/advantage of this?


> 
> Will you extend ManageSIEVE to allow setting scripts on mailboxes via 
> that protocol?

We would probably have to do something.  This is also necesary for your 
Sieve Include extension.  These scripts would be treated as /global.

> 
> Should a script attached to INBOX actually be the users primary 
> (delivery) SIEVE script? If so setting that script via IMAP ANNTATEMORE 
> should have the same effect as doing so via ManageSIEVE.
> 

True.  I hadn't thought about that.  This might be worth exploring.

Since Rob is on vacation, I haven't discussed any of this with him.
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp