[PROPOSAL] Sieve for shared mailboxes

[Ken Murchison]

Stephen L. Ulmer wrote:

> On 8 Jul 2003, Ken Murchison stated:
> 
> 
>>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.
>>
>>Thoughts?
> 
> 
> Random thoughts (not necessarily well-formed):
> 
> What does it mean to "fileinto" a different folder?  Something already
> decided to post the message *here*.  The case is a little different
> for an INBOX.

Not sure what you mean.  Do you mean what happens if the script for the 
shared mailbox does fileinto somewhere else?  In this case, we'd use the 
appropriate ACL to determine if "anonymous" can append the message.  If 
none of the actions in the script succeed, then the implicit keep will 
file the message into the mailbox specified by the original delivery 
address (ACL permitting).

> 
> Do we allow delivering to any folder to which the deliver process has
> permissions, or just to some subtree?

Totally dependent on ACL (no different than it is now).


> 
> If the poster has permission on the original folder but not on the
> target folder at the end of the script, how does the poster know that
> rejection is based on the result of the script?  Changing the contents
> of the message could allow it to be "delivered" (by it being filed
> someplace else).

A script failure should always result in the implicit keep (same 
functionality as with no script at all).


> 
> Can the child be annotated to "dis-inherit" the script?

Yes.  We would probably need a dummy script name which says "do not run 
ANY script".  Actually an empty script would do the same thing.


> 
> If a child is also annotated, is the script replaced, or is it included
> in some way?

Replaced.  Only the "closest" script to the mailbox is run.


> 
> If the message is fileinto'd another folder, is the script for that
> folder run?  What if it fileinto's back to the original?

The script is only run at delivery time, NOT any time a message is 
copied/appended into a folder.  Same semantics as with user scripts.


> 
> Are ACLs inherited by branches of a tree?  Should the script
> inheritance behavior be analogous?

ACLs are inherited.  The /sieve annotation inheritance would be the same.

> 
> How is the behavior of the script defined for future sieve extensions?
> Should this be addressed now, in case future extensions don't make
> sense in the context of a shared folder?

This proposal makes no assumptions about the contents/semantics of the 
script -- that is up to the script writer.  This proposal is only for 
allowing fine grained control over which sieve script should be run upon 
delivery to a shared mailbox.


> 
> Let's turn the question inside out: Why are INBOXes currently special,
> other than they can have scripts associated with them?

Actually, users have sieve scripts, NOT INBOXes.  My idea follows the 
same logic that the "null" user (that address used to post directly to 
shared mailboxes) can also have sieve scripts.  We just use a mailbox 
annotation to determine which script to run.

> 
> Sorry this is so scattered.


No problem, these are good questions.  I hope I answered them well enough.

-- 
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