[PROPOSAL] Sieve for shared mailboxes
ken at oceana.com
Tue Jul 8 11:08:06 EDT 2003
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
>>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.
> 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
More information about the Info-cyrus