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

[Bron Gondwana]

Roughly:

a) nobody else wants to do it.
b) if you write a patch (or get someone to) and it doesn't break other
   stuff or cause massive maintenance headaches or backwards compatibility
   problems, we'll include it.
c) you can do whatever you want with your own copy of course.

Bron ( or as they say in the parlance: patches welcome )

On Wed, Sep 19, 2012, at 12:02 PM, mailing list subscriber wrote:
> 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.
-- 
  Bron Gondwana
  brong at fastmail.fm