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)<vanmeeu...@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?yesLet 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"?noWhere 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. pleasesee the patch in the links I have mentioned. it would just run a rulebefore the user rules kicks in, then the user bytecode would dowhatever 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
<<attachment: dilyan_palauzov.vcf>>
