official dev team position regarding multiple times requested feature (global sieve)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Jul 24 03:59:09 EDT 2012
On 2012-07-23 22:26, mailing list subscriber wrote:
> With all due respect, what is the development's team position
> regarding this feature and how do the development team see a solution
> that meets both requirements?
Users will most likely continue to require write access to a script
that allows them to set what level of spam is to be filtered to a
different folder then one's INBOX, which addresses are on a whitelist,
and whether or not the vacation or out of office responses is
If an organization wishes to enforce a particular script (with or
without particular settings, and with or without allowing the user some
level of editing), then it is (now) mostly some or the other management
solution on top of the Cyrus IMAP deployment that takes care of this
level of management.
I'm curious to learn what exactly would be the set of requirements that
would enable a mandatory Sieve script feature to be integrated into
- Would setting a mandatory script implicitly disallow users to write
additional(?), new scripts? Would this be Yet Another Setting? Would
Cyrus IMAP magically adjust any user-uploaded scripts to conform with
the mandatory script policy?
- Would a script (if it were read-only for the user) read settings from
a location not Cyrus IMAP, such as the proverbial boolean "Yes I am
out-of-office" and/or "my vacation lasts until $x"?
- How many Sieve editing clients would remain compatible / could become
compatible with such Sieve semantics? Please allow me to shamelessly
plug some thoughts from Kolab here, that relate to but are not
entirely in the same realm.
Jeroen van Meeuwen
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
pgp: 9342 BF08
More information about the Cyrus-devel