Extend require line for dovecot.sieve-files

Maybe someone can give me a hand here: Due to the fact that the sieverules-plugin of roundcube allows more complex filtering solutions than ISPConfig we found the require-line which is written by ispconfig insufficient:

Code:

require ["fileinto", "regex", "vacation"];

Because some of our users are utilizing the copy-function for instance the require line would read:

Code:

require ["fileinto","regex","vacation","copy"];

As far as I'm concerned the require line is written statically to the dovecot.sieve-file. In which file is this directive defined so we can simply add more sieve-filter-features?

MTA is up and running and ISPConfig is not reporting any problems except with local delivery which I am working on now.
I edited /usr/local/ispconfig/interface/web/mail/mail_user_edit.php and replaced all references to disabledeliver with disablelda and changed the table in the mysql database like xabbu said but I am not sure if I translated from German correctly!

These are the sieve specific settings in Dovecot v.2

##
## Settings for the Sieve interpreter
##

# Do not forget to enable the Sieve plugin in 15-lda.conf and 20-lmtp.conf
# by adding it to the respective mail_plugins= settings.

# A path to a global sieve script file, which gets executed ONLY
# if user's private Sieve script doesn't exist. Be sure to
# pre-compile this script manually using the sievec command line
# tool.
#sieve_global_path = /var/lib/dovecot/sieve/default.sieve

# Directory for ersonal include scripts for the include extension.
sieve_dir = ~/sieve

# Directory for :global include scripts for the include extension.
#sieve_global_dir =

# Which Sieve language extensions are available to users. By default,
# all supported extensions are available, except for deprecated
# extensions or those that are still under development. Some system
# administrators may want to disable certain Sieve extensions or
# enable those that are not available by default. This setting can
# use '+' and '-' to specify differences relative to the default.
# For example `sieve_extensions = +imapflags' will enable the
# deprecated imapflags extension in addition to all extensions
# enabled by default.
#sieve_extensions = +notify +imapflags

# The separator that is expected between the :user and :detail
# address parts introduced by the subaddress extension. This may
# also be a sequence of characters (e.g. '--'). The current
# implementation looks for the separator from the left of the
# localpart and uses the first one encountered. The :user part is
# left of the separator and the :detail part is right. This setting
# is also used by Dovecot's LMTP service.
#recipient_delimiter = +

# The maximum size of a Sieve script. The compiler will refuse to
# compile any script larger than this limit.
#sieve_max_script_size = 1M

# The maximum number of actions that can be performed during a single
# script execution.
#sieve_max_actions = 32

# The maximum number of redirect actions that can be performed during
# a single script execution.
#sieve_max_redirects = 4

# The maximum number of personal Sieve scripts a single user can have.
# (Currently only relevant for ManageSieve)
#sieve_quota_max_scripts = 0

# The maximum amount of disk storage a single user's scripts may occupy.
# (Currently only relevant for ManageSieve)
#sieve_quota_max_storage = 0
}

These are the managesieve specific settings in Dovecot v.2

##
## ManageSieve specific settings
##

# Service definitions

service managesieve-login {
#inet_listener sieve {
# port = 4190
#}

#inet_listener sieve_deprecated {
# port = 2000
#}

# Number of connections to handle before starting a new process. Typically
# the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
# is faster. <doc/wiki/LoginProcess.txt>
#service_count = 1

# Number of processes to always keep waiting for more connections.
#process_min_avail = 0

# If you set service_count=0, you probably need to grow this.
#vsz_limit = 64M
}

protocol sieve {
# Maximum ManageSieve command line length in bytes. ManageSieve usually does
# not involve overly long command lines, so this setting will not normally need
# adjustment
#managesieve_max_line_length = 65536

# Maximum number of ManageSieve connections allowed for a user from each IP address.
# NOTE: The username is compared case-sensitively.
#mail_max_userip_connections = 10

# Space separated list of plugins to load (none known to be useful so far). Do NOT
# try to load IMAP plugins here.
#mail_plugins =

# MANAGESIEVE logout format string:
# %i - total number of bytes read from client
# %o - total number of bytes sent to client
#managesieve_logout_format = bytes=%i/%o

# To fool ManageSieve clients that are focused on CMU's timesieved you can specify
# the IMPLEMENTATION capability that the dovecot reports to clients.
# For example: 'Cyrus timsieved v2.2.13'
#managesieve_implementation_string = Dovecot Pigeonhole

# Explicitly specify the SIEVE and NOTIFY capability reported by the server before
# login. If left unassigned these will be reported dynamically according to what
# the Sieve interpreter supports by default (after login this may differ depending
# on the user).
#managesieve_sieve_capability =
#managesieve_notify_capability =

# The maximum number of compile errors that are returned to the client upon script
# upload or script verification.
#managesieve_max_compile_errors = 5

Ultimately I would like the sieve scripts of each client to be stored in their own folder with a quota limit and be able to manage their own webmail client folders and themes manageable entirely from the ISPConfig interface but I am still learning about the sieve protocol so it will take me a while.

You should have no problem with that because isp_sieverules does not care about how managesieve is run. As far as I'm concerned also managesieve (run as a daemon) utilizes *.sieve files (or am I wrong here?).

So all isp_sieverules does is to catch the script BEFORE it is actually written and pass it on to ISPConfig. The via the api-functions it is integrated. So it does not matter if its a daemon or whatever. You should have not problems actually.

As far as I'm concerned also managesieve (run as a daemon) utilizes *.sieve files (or am I wrong here?).

Click to expand...

No you are right - previously when I tried the managesieve plugin for roundcube I had to install pidgeonhole and it was a headache because my libtool was broken - I gave it up in the end. Like yourself and others here I am really only interested in adding functionality to ISPConfig 3 without having to install everything but the kitchen sink

So all isp_sieverules does is to catch the script BEFORE it is actually written and pass it on to ISPConfig. The via the api-functions it is integrated. So it does not matter if its a daemon or whatever. You should have not problems actually.

Click to expand...

Haven't gotten that far yet - I modified ISPConfig installer slightly to allow me to use Dovecot v2 out of the box (mainly just the SQL file to change the table "disabledeliver" to "disablelda" in dbispconfig and also changed all php references to "disabledeliver" in the installer to read as "disablelda".