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

[mailing list subscriber]

Hi,
Any news on this thread?
Thanks.

On Tue, Aug 7, 2012 at 11:07 AM, mailing list subscriber
<mailinglists35 at gmail.com> wrote:
> On Mon, Jul 30, 2012 at 2:58 PM, Jeroen van Meeuwen
> <vanmeeuwen at kolabsys.com> wrote:
>
> [...]
>
>>
>>
>> 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
>>
>
> yes
> this script would execute on behalf of the recipient as if it were the
> users' script, then rules from users' script would follow, if any.
>
>>
>> - A setting will control whether or not the users themselves are allowed to
>> write additional, new scripts, for example:
>>
>> sieve_mandatory_notexclusive: boolean
>>
>
> did not think that far, though.
>
> [...]
>
>>> > - 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?
>>
>
> I am sorry but despite my moderate understanding of english language I
> cannot parse your question.
>
>>
>>
>>> > - 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.
>>
>
> I am not a developer, so it's hard for me to help you model this. I
> probably wrongly asked for HOW cyrus to handle this instead of asking
> cyrus just to handle this.
> But I think that I and everyone else referenced in the OP have managed
> to describe how this would appear to function to us, the end users.
> I can't help you develop the black box, but I think I have clearly
> described what do I expect the box to have as input and what to
> produce at the output.
> I will say it again, as poor or good as my english as not my primarily
> language can permit:
>
> INPUT:
> emails with subject [SPAM] enter cyrus system
>
> OUTPUT:
> emails with subject [SPAM] ends up in each users Spam folder.
>
> "Subject [SPAM]" can also be header or any other criteria.
>
> Current practice of provisioning each users sieve rules has the main
> disadvantage that when you modify (for example you have a second
> content filter which inserts headers) you cannot modify all users
> scripts without destroying their personalized script, that's why I
> suggested a script that would simply have its rules parsed and
> executed in the name of the user without exposing it's content via the
> sieve protocol to client tools such as squirrelmail,roundcube or
> thunderbird out of office addons. so the client would continue to
> manage the scrips as before.
>
> I hope it is now a bit clearer.