official dev team position regarding multiple times requested feature (global sieve)

[Jeroen van Meeuwen (Kolab Systems)]

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 
active/de-active.

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 
Cyrus IMAP;

- 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[1] here, that relate to but are not 
entirely in the same realm.

Kind regards,

Jeroen van Meeuwen

[1] https://wiki.kolab.org/KEP:14

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08