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
