Hi, Any news on this thread? Thanks.
On Tue, Aug 7, 2012 at 11:07 AM, mailing list subscriber <mailinglist...@gmail.com> wrote: > On Mon, Jul 30, 2012 at 2:58 PM, Jeroen van Meeuwen > <vanmeeu...@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.
