forwarding to the proper list address since your reply came with a Reply-To header

---------- Forwarded message ---------- From: mailing list subscriber mailinglists35@gmail.com Date: Tue, Jul 24, 2012 at 10:24 AM Subject: Re: official dev team position regarding multiple times requested feature (global sieve) To: awilliam@opengroupware.us

On Mon, Jul 23, 2012 at 11:47 PM, Adam Tauno Williams awilliam@opengroupware.us wrote:

On Mon, 2012-07-23 at 23:26 +0300, mailing list subscriber wrote:

...

With above figure in mind, I'm looking at the history of request for ability to have a forced, default, site-wide sieve script that the user or any other sieve client is unable to alter (I'll just pick most relevant):

Indeed, this would be terribly useful.

...

2004, with reference to 2001: http://goo.gl/Gbo0k 2006: A submitted patch http://www.irbs.net/internet/info-cyrus/0612/0231.html 2007: A very good synthesis: http://goo.gl/Lo33b 2010: sieve include implemented in v.2.3.0, still fails to meet above requirements

But you fail to reference an open bug?!

The page at http://cyrusimap.web.cmu.edu/mediawiki/index.php/Report_A_Bug says: "If you are absolutely positive you have discovered a bug[...]". This might be misleading since this is a feature request and not a bug.

Leaving the technical details of the proper way to report this I'm still curios if the developers are actually AWARE of these repeated requests.

...

With all due respect, what is the development's team position regarding this feature and how do the development team see a solution that meets both requirements?

I find "SIEVE scripts assigned to folders are not executed" https://bugzilla.cyrusimap.org/show_bug.cgi?id=3617

"People forget to cancel their vacation message" https://bugzilla.cyrusimap.org/show_bug.cgi?id=2985 NOTE: this is really a UI issue, IMO, multiple web clients solve this by generating intelligent scripts.

That's another problem with the poor IT guy trying to assemble bricks from different vendors: when he finally is heard, the answer is "uhm, the feature you requested fail beyond the scope of my brick. I'm sorry, I can't do that", even when there is a proposed patch available!

If you read carefully all my referenced links you'll find one that is listing other imap servers that support it. From what I've tested, at least one implementation has done this as a global pre-user execution of a script (dovecot)

I don't see any bugs about a default-user-sieve-script. *BUT* imapd.conf does offer this option [IMPLEMENTED]: autocreate_sieve_script: <none> The full path of a file that contains a sieve script. This script automatically becomes a user’s initial default sieve filter script. When this option is not defined, no default sieve filter is created. The file must be readable by the cyrus daemon.

Of course, the user can override this.

Unfortunately that feature only addresses PROVISIONING of data, which is quite unuseful since cyrus mail admins do this with the auto-* uoa.gr patches (that's another pain that devs refused to include for a long time) - What it lacks is the ability to handle CHANGE (change of default script, or alter existing user scripts).