[PROPOSAL] Sieve for shared mailboxes
ken at oceana.com
Tue Jul 8 11:34:02 EDT 2003
Cyrus Daboo wrote:
> Hi Ken,
> --On Tuesday, July 8, 2003 9:59 AM -0400 Ken Murchison <ken at oceana.com>
> | 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
> 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
More information about the Info-cyrus