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

[mailing list subscriber]

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.