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

[Дилян Палаузов]

Hello,

as far as I understand, the use case for the requested feature is to 
have default spam filter rules (action fileinto or reject), that are 
canceled, when the user's script make a different fileinto/reject. 
Something like:

Execute the :global default script, which contains only 
fileinto/reject/ereject/keep/stop action (no vacation, redirect). 
Remember the outcome of the script execution, without executing it

Execute the :private default script.
If it executes, fileinto/reject/ereject, then then the fileinto from the 
:global default script is canceled.
If it executes, keep, then the action from the :global default script is 
executed

In any case, the :global default script is not supposed to include 
scripts with specific names, from the :personal space, but rather to be 
executed before the :personal default script.

> If you read carefully all my referenced links you'll find one that is   listing other imap servers that support it.

Which other servers support this feature?  Do they just consider the 
:private default script appended to the :global default script, without 
sticking to particular names, and it is site administrators' 
responsibility, not to write strange things (vacation) in the :global 
default script.

Със здраве
   Дилян

On 30.07.2012 13:58, Jeroen van Meeuwen wrote:
> On Tuesday, July 24, 2012 11:30:20 AM mailing list subscriber wrote:
>
> Dear mailing list subscriber,
>
> Apologies for taking as long as I did to get back to this.
>
>> On Tue, Jul 24, 2012 at 10:59 AM, Jeroen van Meeuwen (Kolab Systems)
>
>> <vanmeeuwen at kolabsys.com> wrote:
>
>> > 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?
>
>>
>
>> no
>
>>
>
>> > Would this be Yet Another Setting?
>
>>
>
>> yes
>
>>
>
> Let me summarize what is then the idea, if I understand correctly:
>
> - A setting will control what script is mandatory, globally, if any, for
> example:
>
> sieve_mandatory_script: /path/to/sieve/script
>
> - A setting will control whether or not the users themselves are allowed
> to write additional, new scripts, for example:
>
> sieve_mandatory_notexclusive: boolean
>
>> > Would Cyrus
>
>> > IMAP magically adjust any user-uploaded scripts to conform with the
>
>> > mandatory script policy?
>
>>
>
>> no
>
>>
>
>> > - 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"?
>
>>
>
>> no
>
>>
>
> Where would the mandatory, read-only, invisible sieve script get
> vacation/out-of-office/spam settings from, then?
>
>> > - 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.
>
>>
>
>> 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.
>
> Right, the model that the reference listed is to have a "MASTER.siv" -
> which would be the system-controlled one, that includes other system
> controlled scripts, and includes user scripts as
> available/enabled/necessary.
>
> I suppose enabling/disabling vacation is then the toggling of an include
> :global vacation.siv, prior to which (in a :personal MASTER.siv
> (invisible, read-only) included :personal vacation.siv?) settings are
> set? How would we treat the client's expectation of marking as the
> active scripts, any of the scripts that are visible?
>
> I'm sorry, but I'm having a hard time modeling this so that we add
> option value rather than take any away, while I'm trying to map this to
> some model that would not invalidate Sieve client compatibility.
>
> Kind regards,
>
> Jeroen van Meeuwen
>
> --
>
> Systems Architect, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
>
> m: +44 74 2516 3817
>
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dilyan_palauzov.vcf
Type: text/x-vcard
Size: 380 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120730/8db5e198/attachment.vcf