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

mailing list subscriber mailinglists35 at gmail.com
Tue Jul 24 04:32:41 EDT 2012

Sorry got this reply only to you because I did not notice your
Reply-To: header. you might want to have it disabled when sending
messages to mailing lists so people can properly reply to the list.

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

On Mon, Jul 23, 2012 at 11:47 PM, Adam Tauno Williams
<awilliam at 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

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

>> 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

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).

More information about the Cyrus-devel mailing list