official dev team position regarding multiple times requested feature (global sieve)
mailing list subscriber
mailinglists35 at gmail.com
Tue Jul 24 04:30:20 EDT 2012
On Tue, Jul 24, 2012 at 10:59 AM, Jeroen van Meeuwen (Kolab Systems)
<vanmeeuwen at kolabsys.com> wrote:
> 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
> 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
> - 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.
script would be completely invisible to the clients/end user. please
see the patch in the links I have mentioned. it would just run a rule
before the user rules kicks in, then the user bytecode would do
whatever they want on the same message.
More information about the Cyrus-devel