Sieve Plugin (`sieve`)

Configuration

To use Sieve, you will first need to make sure you are using Dovecot LDA or LMTP Server for delivering incoming mail to users' mailboxes.

Then, you need to enable the Sieve plugin in your configuration:

protocol lda {
  mail_plugins {
    sieve = yes
  }
}

protocol lmtp {
  mail_plugins {
    sieve = yes
  }
}

Script storage

Sieve scripts are retrieved from a script storage. This can currently be the local filesystem, an LDAP database or any dict storage. Depending on the storage implementation, its type and its configuration, storages can contain one script, several scripts identified by name, and a series of scripts in a well-defined order to be executed in sequence.

Script storages are configured in a named sieve_script block:

sieve_script personal {
  path = ~/.dovecot.sieve
}

The storage name (personal in the example) is used internally within configurations, as an identifier for logging, and as an identifier for command line tools. It also allows updating a storage that was defined earlier - by repeating the sieve_script block and adding additional configuration settings - or it allows userdb to override storage settings for specific users.

Script storage types

Sieve scripts can be evaluated at various stages in message delivery and for stored messages. The type of the Sieve script storage determines where it is applicable, how the storage is accessed and how the retrieved Sieve script is evaluated.

The type of the Sieve script storage is configured using the sieve_script_type setting. The following types are currently recognized (others are defined by the sieve-imapsieve plugin plugin):

`personal`

The personal storage serves as the user's main personal storage. Although more than a single personal storage can be defined, only the first one listed in the configuration is used.

The LDA Sieve plugin uses the personal storage to find the active script for Sieve filtering at delivery. If the storage supports storing more than a single script (e.g. the file storage does), personal scripts can also be retrieved by name. The Sieve include extension will then use this storage for retrieving :personal scripts and the ManageSieve service will be able to store the user's scripts there.

If the storage supports storing more than a single script, only one of those scripts will be the active script used at delivery. The active script can be managed by the user through the ManageSieve service. If the personal storage has no active script, the default script will be executed if configured.

If no personal storage is defined explicitly, auto-detection will be attempted. This is currently only trying the [[link,sieve_storage_file,file storage driver], which looks for a ~/.dovecot.sieve script file or a directory at ~/sieve/ containing script files. In the latter case ~/.dovecot.sieve is expected to be a symbolic link pointing to the active script file. If auto-detection also finds no personal storage, Sieve processing will be skipped and no default script is executed.

`after`

An after storage is the source of one script or several scripts that are to be executed after the user's personal script. If the storage supports storing more than a single script, these scripts will be executed in a well-defined order defined by the storage driver. Multiple after storages can be configured and each storage will be accessed in sequence to retrieve scripts for execution after the personal script. The storages will be accessed in the order these storages are defined in the configuration, unless the order is overridden by the sieve_script_precedence setting.

This is usually a global script, so be sure to pre-compile the specified script manually in that case using the sievec command line tool, as explained by sievec(1).`

`before`

A before storage behaves identical to an after storage, except the contained script or scripts are run before user's personal script (instead of after).

`default`

The default storage yields the sieve script that gets executed only if the user's personal Sieve script does not exist. Although more than a single default storage can be defined, only the first one listed in the configuration is used.

If sieve_script_name is set for this script storage, the default script can be seen and accessed by this name through ManageSieve (and doveadm sieve). See below (Sieve visible default script).

This is usually a global script, so be sure to pre-compile the specified script manually in that case using the sievec command line tool, as explained by sievec(1).`

`discard`

The discard storage yields the sieve script that gets executed for any message that is about to be discarded; i.e., it is not delivered anywhere by the normal Sieve execution. Although more than a single discard storage can be defined, only the first one listed in the configuration is used. The discard storage is currently only applicable for message delivery.

The script from the discard storage is only executed when the "implicit keep" is canceled, by e.g. the "discard" action, and no actions that deliver the message are executed. Delivery in this case means both local delivery to a mailbox and redirection to a remote recipient. This "discard script" can prevent discarding the message, by executing alternative actions. If the discard script does nothing, the message is still discarded as it would be when no discard script is configured.

`global`

A global storage is the source of :global include scripts for the Sieve include extension. Scripts are accessed by name, so if the storage yields only one script, a name must be defined for it; either implicitly by the storage driver or explicitly using sieve_script_name. Multiple global storages can be configured and each storage will be queried in sequence to retrieve the requested script by name. The storages will be queried in the order these storages are defined in the configuration until the script is found. The order can be overridden by the sieve_script_precedence setting.

Script storage drivers

Sieve script storages are implemented as a storage driver. The default file storage driver uses the local filesystem. It can use a single script file or a directory containing several Sieve script files with a symbolic link pointing to the active script.

More complex setups can use other storage drivers such as ldap or dict to fetch Sieve scripts from LDAP databases or dict storages, respectively.

The storage driver is configured using the sieve_script_driver setting. If not explicitly configured for a sieve_script block, the storage driver is file and the default directory is ~/sieve/ with a symbolic link at ~/.dovecot.sieve pointing to the active script file in that directory.

Common Settings

All Sieve script storages support the following common settings:

`sieve_script`

Default	[None]
Value	Named List Filter
See Also	Script storage

Creates a new Sieve script storage to the list of script storages. The filter name refers to the sieve_script_storage setting.

Example:

sieve_script personal {
  [...]
}

`sieve_script_bin_path`

Default	`personal`
Value	string
See Also	Script storage

Points to the directory where the compiled binaries for this script location are stored. This directory is created automatically if possible.

If this setting is not configured, the behavior depends on the storage driver. For the file storage driver, the binaries are for example stored in the same directory as the corresponding sieve scripts.

Don't specify the same directory for multiple script storages (e.g. with different types), as this will result in undefined behavior. For one, the same script name could point to different scripts for different storages, leading to a conflict, because the storages will try to use the same binary file. Multiple mail users can share a single script directory if the associated script storage configuration is identical between users and all users share the same system credentials (uid, gid). All users will then use the same scripts for that storage type.

`sieve_script_cause`

Default	`delivery`
Value	Boolean List
See Also	Script storage

The causes for executing Sieve scripts from this storage. This is currently only relevant for the IMAPSieve plugin. For standard Sieve execution at message delivery the cause is "delivery". Other causes can be append, copy and flag.

`sieve_script_driver`

Default	`file`
Value	string
See Also	Script storage

The Sieve script storage driver to use. See Script storage drivers.

`sieve_script_name`

Default	`personal`
Value	string
See Also	Script storage

The (default) name of a Sieve script retrieved from this storage. If the name of the Sieve script cannot be derived somehow from the storage (e.g. from a file name) and the storage for a single script is specified, this option is required (e.g. for dict locations that must point to a particular script).

If the name of the script is derived from the storage, the value of the sieve_script_name setting overrides that name. If the Sieve interpreter explicitly queries for a specific name (e.g. to let the Sieve Sieve include extension retrieve a script from the global script storage), this setting has no effect.

For the Sieve script storage with type default, the name is required to make the default script visible in ManageSieve. See 'Sieve visible default script'

`sieve_script_precedence`

Default	`infinite`
Value	unsigned integer
See Also	Script storage

The precedence of this Sieve storage in the configuration. Normally, script storages with matching type and cause are accessed in the order these are specified in the configuration. This setting can be used to configure an explicit order. Storages will be accessed with lower precedence first.

`sieve_script_storage`

Default	[None]
Value	string
See Also	Script storage

The identifier of the Sieve script storage. This is used only in configurations and by command line tools - it's not visible to the user. The sieve_script filter refers to this setting.

`sieve_script_type`

Default	`personal`
Value	string
See Also	Script storage types

The type of the configured Sieve script storage. See Script storage types.

File storage driver

The file script storage driver is used to retrieve Sieve scripts from the file system. This is the default type if the sieve_script_driver setting is omitted.

The path configured using the sieve_script_path setting can either point to a directory or to a regular file. If the path points to a directory, a script called name is retrieved by reading a file from that directory with the file name name.sieve.

When a script storage with type personal is using the file driver and thesieve_script_path points to a directory, a symbolic link points to the currently active script (the script executed at delivery). The active script can be modified by the user through ManageSieve and by the administrator using doveadm sieve activate. The location of this symbolic link can be configured using the sieve_script_active_path setting.

When a script storage with type before or after is using the file driver and sieve_script_path points to a directory, all files in that directory with a .sieve extension are part of the sequence. The sequence order of the scripts in that directory is determined by the file names, using a normal 8-bit per-octet comparison.

Unless overridden using the sieve_script_bin_path setting, compiled binaries for scripts retrieved from a file script storage are by default stored in the same directory as where the script file was found if possible.

Configuration

The file storage driver supports all settings described in Common Settings. Additionally, the following settings apply to this driver:

`sieve_script_active_path`

Default	`~/.dovecot.sieve`
Value	string
See Also	File storage driver

When ManageSieve server is used, one script in the storage can be active; i.e., evaluated at delivery.

This setting only applies when sieve_script_driver = file. For that storage driver, the active script in the storage directory is pointed to by a symbolic link.

This setting configures where this symbolic link is located. If the sieve_script_path setting points to a regular file, this setting has no effect (and ManageSieve cannot be used).

`sieve_script_path`

Default	`~/sieve`
Value	string
See Also	File storage driver

A file system path pointing to a Sieve script file or a directory containing one or more Sieve script files with names structured as <script-name>.sieve. This setting only applies when sieve_script_driver = file

`sieve_script_name`

If the sieve_script_name setting is not configured and the Sieve script is not retrieved by name (e.g. using the include extension or by ManageSieve), the name defaults to the file name without the .sieve suffix.

`sieve_script_bin_path`

If the sieve_script_bin_path setting is not configured, the binaries are stored in the same directory as the corresponding sieve scripts by default.

Example

sieve_script personal {
  driver = file
  path = ~/sieve
  active_path = ~/.dovecot.sieve
}

sieve_script default {
  type = default
  name = default
  driver = file
  path = /etc/dovecot/sieve/default/
}

Dict storage driver

To retrieve a Sieve script from a dictionary database, two lookups are performed.

First, the name of the Sieve script is queried from the dict path /priv/sieve/name/<name>. If the Sieve script exists, this yields a data ID which in turn points to the actual script text. The script text is subsequently queried from the dict path /priv/sieve/data/<dict-id>.

The second query is only necessary when no compiled binary is available or when the script has changed and needs to be recompiled. The data ID is used to detect changes in the dict's underlying database. Changing a Sieve script in the database must be done by first making a new script data item with a new data ID. Then, the mapping from name to data ID must be changed to point to the new script text, thereby changing the data ID returned from the name lookup, i.e. the first query mentioned above. Script binaries compiled from Sieve scripts contained in a dict database record the data ID. While the data ID contained in the binary is identical to the one returned from the dict lookup, the binary is assumed up-to-date. When the returned data ID is different, the new script text is retrieved using the second query and compiled into a new binary containing the updated data ID.

Configuration

The dict storage driver supports all settings described in Common Settings.

`sieve_script_name`

If the sieve_script_name setting is not configured and the Sieve script is not retrieved by name (e.g. using the include extension or by ManageSieve), the name defaults to default.

`sieve_script_bin_path`

By default, compiled binaries are not stored at all for Sieve scripts retrieved from a dict database. Thus, the Sieve binaries will be compiled each time they are called.

To improve performance, sieve_script_bin_path should be specified to cache the compiled binaries on the local filesystem. For Example:

sieve_script personal {
  driver = dict
  name = keep

  bin_path = ~/.sieve-bin
  # or
  #bin_path=/var/sieve-scripts/%{user}

  dict file {
    path = /etc/dovecot/sieve.dict
  }
}

TIP

Sieve uses the ID number as its cache index and to detect the need to compile. Therefore, if a script is changed, then its ID must also be changed for it to be reloaded.

Examples

Flat File Driver

To retrieve the Sieve script named "keep" from the dict file /etc/dovecot/sieve.dict:

dovecot.conf/etc/dovecot/sieve.dict

# Only the "keep" script will be used.
sieve_script personal {
  driver = dict
  name = keep
  dict file {
    path = /etc/dovecot/sieve.dict
  }
}

priv/sieve/name/keep
1
priv/sieve/name/discard
2
priv/sieve/data/1
keep;
priv/sieve/data/2
discard;

A more advanced example using the same config as above: notify an external email address when new mail has arrived.

Note that the script all needs to be on one line.

/etc/dovecot/sieve.dict

priv/sieve/name/notify
5
priv/sieve/data/5
require ["enotify", "variables"]; if header :matches "From" "*" { set "from" "${1}";} notify :importance "3" :message "New email from ${from}" "mailto:other@domain.com?body=New%20email%20has%20arrived.";

Using a SQL Driver

For greater flexibility, it's possible to use a SQL driver for your dict scripts.

First, set up a configuration file (such as /etc/dovecot/dict-sieve-sql.conf.inc) with your database configuration. This should consist of the following parts:

First, set up a configuration file (such as /etc/dovecot/dict-sieve-sql.conf) with your database configuration. Next, create a dict proxy service (in dovecot.conf). Finally, configure Sieve to check the dict to lookup up a script called "active" in the database:

/etc/dovecot/dict-sieve-sql.conf.incdovecot.conf

# The name mapping that yields the ID of the Sieve script

# The name of the script, as per the "sieve" config parameter
dict_map priv/sieve/name/$script_name {
  # The database table
  sql_table = user_sieve_scripts

  # The username field in the table to query
  username_field = username

  # The field which contains the return value of the script ID
  value_field id {
  }

  # The script name field in the table to query
  key_field script_name {
    pattern = $script_name
  }
}

# The name mapping that yields the script content from ID

# The ID, obtained from above
dict_map priv/sieve/data/$id {
  # The database table
  sql_table = user_sieve_scripts

  # The username field in the table to query
  username_field = username

  # The field which contains the script
  value_field script_data {
  }

  # The id field in the table to query
  fields id {
    id = $id
  }
}

dict_server {
  dict sieve {
    driver = sql
    sql_driver = pgsql

    pgsql localhost {
      parameters {
        dbname = dovecot
        user = dovecot
        password = password
      }
    }

    !include /etc/dovecot/dict-sieve-sql.conf.inc
  }
}

# dict lookup
sieve_script personal {
  driver = dict
  name = active
  dict proxy {
    name = sieve
  }
}

As with the flat file, the database query will need to return the Sieve script all in one line, otherwise the subsequent lines will be ignored.

INFO

You might need to configure the dict proxy permissions.

LDAP storage driver

The ldap storage driver is used to retrieve Sieve scripts from an LDAP database. To retrieve a Sieve script from the LDAP database, at most two lookups are performed.

First, the LDAP entry containing the Sieve script is searched using the specified LDAP search filter. If the LDAP entry changed since it was last retrieved (or it was never retrieved before), the attribute containing the actual Sieve script is retrieved in a second lookup. In the first lookup, a special attribute is read and checked for changes. Usually, this is the modifyTimestamp attribute, but an alternative can be configured.

Depending on how Pigeonhole was configured and compiled (refer to INSTALL file for more information), LDAP support may only be available when a plugin called sieve_storage_ldap is loaded.

Configuration

The ldap storage driver supports all settings described in Common Settings. The following settings apply to this script storage driver:

`ldap_auth_dn`

Default	[None]
Value	string

Specify the Distinguished Name (the username used to login to the LDAP server).

Leave it commented out to bind anonymously (useful with passdb_ldap_bind = yes).

Example: ldap_auth_dn = uid=dov-read,dc=example,dc=com,dc=.

`ldap_auth_dn_password`

Default	[None]
Value	string

Password for LDAP server. Used if ldap_auth_dn is specified.

`ldap_auth_sasl_authz_id`

Default	[None]
Value	string

SASL authorization ID, ie. the ldap_auth_dn_password is for this "master user", but the ldap_auth_dn is still the logged in user. Normally you want to keep this empty.

`ldap_auth_sasl_mechanisms`

Default	[None]
Value	Boolean List

List of SASL mechanism names to use.

`ldap_auth_sasl_realm`

Default	[None]
Value	string

SASL realm to use.

`ldap_base`

Default	[None]
Value	string

LDAP base.

Settings variables can be used.

Example: ldap_base = dc=mail, dc=example, dc=org

`ldap_debug_level`

Default	[None]
Value	unsigned integer

LDAP library debug level as specified by LDAP_DEBUG_* in ldap_log.h.

Value -1 means everything.

You may need to recompile OpenLDAP with debugging enabled to get enough output.

`ldap_deref`

Default	`never`
Value	string
Allowed Values	`neversearchingfindingalways`

Specify dereference which is set as an LDAP option.

`ldap_scope`

Default	`subtree`
Value	string
Allowed Values	`baseonelevelsubtree`

This specifies the search scope.

`ldap_starttls`

Default	`no`
Value	boolean

Set to yes to use TLS to connect to the LDAP server.

`ldap_uris`

Default	[None]
Value	string

LDAP URIs to use.

Configure this setting to specify what LDAP server(s) to connect to.

The URIs are in syntax protocol://host:port.

Example: ldap_uris = ldaps://secure.domain.org

`ldap_version`

Default	`3`
Value	unsigned integer

LDAP protocol version to use. Likely 2 or 3.

`sieve_script_ldap_filter`

Default	[None]
Value	string
See Also	LDAP storage driver

The LDAP search filter that is used to find the entry containing the Sieve script.

These variables can be used:

Variable	Description
`%{user}`	username
`%{user \| username}`	user part in user@domain, same as `%{user}` if there's no domain
`%{user \| domain}`	domain part in user@domain, empty if user there's no domain
`%{home}`	user's home directory
`%{name}`	name of the Sieve script

`sieve_script_ldap_modified_attribute`

Default	[None]
Value	string
See Also	LDAP storage driver

The name of the attribute used to detect modifications to the LDAP entry.

`sieve_script_ldap_script_attribute`

Default	[None]
Value	string
See Also	LDAP storage driver

The name of the attribute containing the Sieve script.

`sieve_script_name`

If the sieve_script_name setting is not configured and the Sieve script is not retrieved by name (e.g. using the include extension or by ManageSieve), the name defaults to default.

`sieve_script_bin_path`

By default, compiled binaries are not stored at all for Sieve scripts retrieved from LDAP. Thus, the Sieve binaries will be compiled each time they are called.

To improve performance, sieve_script_bin_path should be specified to cache the compiled binaries on the local filesystem. For Example:

sieve_script personal {
  driver = ldap
  name = keep

  bin_path = ~/.sieve-bin
  # or
  #bin_path = /var/sieve-scripts/%{user}

  # LDAP settings:
  ...
}

TIP

Sieve uses the LDAP entry configured using sieve_script_ldap_modified_attribute to detect the need to compile. Therefore, if a script is changed, then this entry must also be changed for it to be reloaded. Depending on which LDAP entry is configured, this can happen implicitly by the LDAP database itself (which is normally the case for the default modifyTimestamp entry).

Example

If support for the ldap script storage driver is compiled as a plugin, it needs to be added to the sieve_plugins setting before it can be used, e.g.:

sieve_plugins {
  sieve_storage_ldap = yes
}

dovecot.conf

sieve_script personal {
  driver = ldap
  bin_path = ~/.sieve-bin/

  # Don't use privileged LDAP credentials here as these may likely leak. Only
  # search and read access is required.

  # Space separated list of LDAP URIs to use.
  ldap_uris = ldap://localhost

  # Distinguished Name - the username used to login to the LDAP server.
  # Leave it commented out to bind anonymously.
  ldap_auth_dn = cn=sieve,ou=Programs,dc=example,dc=org

  # Password for LDAP server, if dn is specified.
  ldap_auth_dnpassword = secret

  # LDAP base
  ldap_base = dc=mail,dc=example,dc=org

  # Dereference: never, searching, finding, always
  ldap_deref = never

  # Search scope: base, onelevel, subtree
  ldap_scope = subtree

  # Filter for user lookup. Some variables can be used:
  #   %{user}      - username
  #   %{user | username}      - user part in user@domain, same as %{user} if there's no domain
  #   %{user | domain}      - domain part in user@domain, empty if there's no domain
  #   %{name} - name of the Sieve script
  ldap_filter = (&(objectClass=posixAccount)(uid=%{user}))

  # Attribute containing the Sieve script
  ldap_script_attribute = mailSieveRuleSource

  # Attribute used for modification tracking
  ldap_modified_attribute = modifyTimestamp
}

Settings

`managesieve_client_workarounds`

Default	[None]
Value	Boolean List
Advanced Setting; this should not normally be changed.

Enables various workarounds for ManageSieve clients. Currently there are none.

`managesieve_implementation_string`

Default	`Dovecot Pigeonhole`
Value	string
Advanced Setting; this should not normally be changed.

Sets the ManageSieve implementation string returned by the IMPLEMENTATION capability.

`managesieve_logout_format`

Default	`bytes=%{input}/%{output}`
Value	String without variables

Specifies the string pattern used to compose the logout message of an authenticated session. The following substitutions are available:

Variable Name	Description
`%{input}`	Total number of bytes read from client
`%{output}`	Total number of bytes sent to client
`%{put_count}`	Number of scripts uploaded by client using PUTSCRIPT command
`%{put_bytes}`	Number of bytes with script data sent by client using PUTSCRIPT command
`%{get_count}`	Number of scripts downloaded by client using GETSCRIPT command
`%{get_bytes}`	Number of bytes with script data sent to client using GETSCRIPT command
`%{check_count}`	Number of scripts checked by client using CHECKSCRIPT command
`%{check_bytes}`	Number of bytes with script data sent by client using CHECKSCRIPT command
`%{deleted_count}`	Number of scripts deleted by client using DELETESCRIPT command
`%{renamed_count}`	Number of scripts renamed by client using RENAMESCRIPT command
`%{session}`	The client session ID

`managesieve_max_compile_errors`

Default	`5`
Value	unsigned integer
Advanced Setting; this should not normally be changed.

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

`managesieve_max_line_length`

Default	`64k`
Value	size
Advanced Setting; this should not normally be changed.

The maximum ManageSieve command line length in bytes.

Since long command lines are very unlikely with ManageSieve, changing this will generally not be useful.

`managesieve_notify_capability`

Default	`<dynamically determined>`
Value	Boolean List
Advanced Setting; this should not normally be changed.

NOTIFY capabilities reported by the ManageSieve service before authentication.

This does normally not need to be configured. If left unassigned, these will be assigned dynamically according to what the Sieve interpreter is configured to support using the global sieve_extensions setting (after login this may differ depending on the settings applicable to the authenticated user).

`managesieve_sieve_capability`

Default	`<dynamically determined>`
Value	Boolean List
Advanced Setting; this should not normally be changed.

SIEVE capabilities reported by the ManageSieve service before authentication.

`recipient_delimiter`

Default	`+`
Value	string

The separator between the :user and :detail address parts.

`sieve_duplicate_default_period`

Default	`14d`
Value	time
See Also	Sieve duplicate extension
Advanced Setting; this should not normally be changed.

Default period after which tracked values are purged from the duplicate tracking database.

`sieve_duplicate_max_period`

Default	`7d`
Value	time
See Also	Sieve duplicate extension
Advanced Setting; this should not normally be changed.

Maximum period after which tracked values are purged from the duplicate tracking database.

`sieve_editheader_header_forbid_add`

Default	[None]
Value	string
See Also	Sieve editheader extension

A space-separated list of headers that cannot be added to the message header.

Addition of the Subject: header cannot be prohibited, as required by the RFC specification. Therefore, adding this header to this setting has no effect.

`sieve_editheader_header_forbid_delete`

Default	[None]
Value	string
See Also	Sieve editheader extension

A space-separated list of headers that cannot be deleted from the message header.

Deleting the Received: and Auto-Submitted: fields is always forbidden, while removing the Subject: header cannot be prohibited, as required by the RFC specification. Therefore, adding one of these headers to this setting has no effect.

`sieve_editheader_max_header_size`

Default	`2k`
Value	size
See Also	Sieve editheader extension

The maximum size in bytes of a header field value passed to the addheader command.

The minimum value for this setting is 1024 bytes.

`sieve_extensions`

Default	`<see description>`
Value	Boolean List

The Sieve language extensions available to users.

By default, all supported extensions are available, except for deprecated extensions, extensions that add the ability to change messages, extensions that require explicit configuration, or extensions that are still under development.

Some system administrators may want to disable certain Sieve extensions or enable those that are not available by default.

Supported extensions are listed at Sieve extensions.

Example:

# Enable the vacation-seconds extension in addition to all
# extensions enabled by default.
sieve_extensions {
  vacation-seconds = yes
}

`sieve_global_extensions`

Default	`sieve_extensions`
Value	Boolean List

Which Sieve language extensions are only available in global scripts.

This can be used to restrict the use of certain Sieve extensions to administrator control, for instance when these extensions can cause security concerns.

This setting has higher precedence than sieve_extensions, meaning that the extensions enabled with this setting are never available to the user's personal script no matter what is specified for the sieve_extensions setting.

The syntax of this setting is identical to sieve_extensions, with the difference that extensions are enabled or disabled for exclusive use in global scripts.

Currently, no extensions are marked as such by default.

`sieve_implicit_extensions`

Default	[None]
Value	string

WARNING

Do not use this setting unless you really need to!

The Sieve language extensions implicitly available to users.

The extensions listed in this setting do not need to be enabled explicitly using the Sieve "require" command.

This behavior directly violates the Sieve standard, but can be necessary for compatibility with some existing implementations of Sieve (notably jSieve).

The syntax and semantics of this setting are otherwise identical to sieve_extensions.

`sieve_include_max_includes`

Default	`255`
Value	unsigned integer
See Also	Sieve include extension
Advanced Setting; this should not normally be changed.

The maximum number of scripts that may be included. This is the total number of scripts involved in the include tree.

`sieve_include_max_nesting_depth`

Default	`10`
Value	unsigned integer
See Also	Sieve include extension
Advanced Setting; this should not normally be changed.

The maximum nesting depth for the include tree.

`sieve_max_actions`

Default	`32`
Value	unsigned integer

The maximum number of actions that can be performed during a single script execution.

If set to 0, no limit on the total number of actions is enforced.

`sieve_max_cpu_time`

Default	`30s`
Value	time

The maximum amount of CPU time that a Sieve script is allowed to use while executing. If the execution exceeds this resource limit, the script ends with an error, causing the implicit "keep" action to be executed.

This limit is not only enforced for a single script execution, but also cumulatively for the last executions within a configurable timeout (see sieve_resource_usage_timeout).

`sieve_max_redirects`

Default	`4`
Value	unsigned integer

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

0 means redirect is prohibited.

`sieve_max_script_size`

Default	`1M`
Value	size
Advanced Setting; this should not normally be changed.

The maximum size of a Sieve script. The compiler will refuse to compile any script larger than this limit.

If set to 0, no limit on the script size is enforced.

`sieve_notify_mailto_envelope_from`

Default	[None]
Value	string
See Also	`sieve_redirect_envelope_from` Sieve notifications extensions

Defines the source of the notification sender address for e-mail notifications.

`sieve_plugins`

Default	[None]
Value	Boolean List

The Pigeonhole Sieve interpreter can have plugins of its own.

Using this setting, the used plugins can be specified.

Check Sieve plugins for available plugins.

`sieve_quota_script_count`

Default	[None]
Value	unsigned integer

The maximum number of personal Sieve scripts a single user can have.

Default is 0, which is unlimited.

`sieve_quota_storage_size`

Default	[None]
Value	unsigned integer

The maximum amount of disk storage a single user's scripts may occupy.

Default is 0, which is unlimited.

`sieve_redirect_envelope_from`

Default	`sender`
Value	string

Specifies what envelope sender address is used for redirected messages.

Normally, the Sieve redirect command copies the sender address for the redirected message from the processed message So, the redirected message appears to originate from the original sender.

The following options are supported for this setting:

Option	Description
`sender`	The sender address is used
`recipient`	The final recipient address is used
`orig_recipient`	The original recipient is used
`user_email`	The user's primary address is used. This is configured with the `sieve_user_email` setting. If that setting is not configured, `user_email` is equal to `sender`.
`postmaster`	The `postmaster_address` configured for LDA/LMTP.
`<user@domain>`	Redirected messages are always sent from `user@domain`. The angle brackets are mandatory. The null `<>` address is also supported.

When the envelope sender of the processed message is the null address <>, the envelope sender of the redirected message is also always <>, irrespective of what is configured for this setting.

`sieve_resource_usage_timeout`

Default	`1h`
Value	time

To prevent abuse, the Sieve interpreter can record resource usage of a Sieve script execution in the compiled binary if it is significant. Currently, this happens when CPU system + user time exceeds 1.5 seconds for one execution. Such high resource usage is summed over time in the binary and once that cumulative resource usage exceeds the limits (sieve_max_cpu_time), the Sieve script is disabled in the binary for future execution, even if an individual execution exceeded no limits.

If the last time high resource usage was recorded is older than sieve_resource_usage_timeout, the resource usage in the binary is reset. This means that the Sieve script is only disabled when the limits are cumulatively exceeded within this timeout. With the default configuration this means that the Sieve script is only disabled when the total CPU time of Sieve executions that lasted more than 1.5 seconds exceeds 30 seconds in the last hour.

A disabled Sieve script can be reactivated by the user by uploading a new version of the Sieve script after the excessive resource usage times out. An administrator can force reactivation by forcing a script compile (e.g. using the sievec command line tool).

`sieve_script`

Default	[None]
Value	Named List Filter
See Also	Script storage

Creates a new Sieve script storage to the list of script storages. The filter name refers to the sieve_script_storage setting.

Example:

sieve_script personal {
  [...]
}

`sieve_script_active_path`

Default	`~/.dovecot.sieve`
Value	string
See Also	File storage driver

When ManageSieve server is used, one script in the storage can be active; i.e., evaluated at delivery.

This setting only applies when sieve_script_driver = file. For that storage driver, the active script in the storage directory is pointed to by a symbolic link.

This setting configures where this symbolic link is located. If the sieve_script_path setting points to a regular file, this setting has no effect (and ManageSieve cannot be used).

`sieve_script_bin_path`

Default	`personal`
Value	string
See Also	Script storage

Points to the directory where the compiled binaries for this script location are stored. This directory is created automatically if possible.

`sieve_script_cause`

Default	`delivery`
Value	Boolean List
See Also	Script storage

`sieve_script_driver`

Default	`file`
Value	string
See Also	Script storage

The Sieve script storage driver to use. See Script storage drivers.

`sieve_script_ldap_filter`

Default	[None]
Value	string
See Also	LDAP storage driver

The LDAP search filter that is used to find the entry containing the Sieve script.

These variables can be used:

Variable	Description
`%{user}`	username
`%{user \| username}`	user part in user@domain, same as `%{user}` if there's no domain
`%{user \| domain}`	domain part in user@domain, empty if user there's no domain
`%{home}`	user's home directory
`%{name}`	name of the Sieve script

`sieve_script_ldap_modified_attribute`

Default	[None]
Value	string
See Also	LDAP storage driver

The name of the attribute used to detect modifications to the LDAP entry.

`sieve_script_ldap_script_attribute`

Default	[None]
Value	string
See Also	LDAP storage driver

The name of the attribute containing the Sieve script.

`sieve_script_name`

Default	`personal`
Value	string
See Also	Script storage

For the Sieve script storage with type default, the name is required to make the default script visible in ManageSieve. See 'Sieve visible default script'

`sieve_script_path`

Default	`~/sieve`
Value	string
See Also	File storage driver

`sieve_script_precedence`

Default	`infinite`
Value	unsigned integer
See Also	Script storage

`sieve_script_storage`

Default	[None]
Value	string
See Also	Script storage

The identifier of the Sieve script storage. This is used only in configurations and by command line tools - it's not visible to the user. The sieve_script filter refers to this setting.

`sieve_script_type`

Default	`personal`
Value	string
See Also	Script storage types

The type of the configured Sieve script storage. See Script storage types.

`sieve_spamtest_score_max_header`

Default	[None]
Value	string
See Also	Sieve spamtest extension

Value format: <header-field> [ ":" <regexp> ]

Some spam scanners include the maximum score value in one of their status headers. Using this setting, this maximum can be extracted from the message itself instead of specifying the maximum manually using the setting sieve_spamtest_score_max_value.

The syntax is identical to the sieve_spamtest_status_header setting. This setting cannot be used together with sieve_spamtest_score_max_value.

`sieve_spamtest_score_max_value`

Default	[None]
Value	string
See Also	Sieve spamtest extension

This statically specifies the maximum value a numeric spam score can have. This setting cannot be used together with sieve_spamtest_score_max_header. This setting can specify a fractional score with a decimal point.

`sieve_spamtest_status_header`

Default	[None]
Value	string
See Also	Sieve spamtest extension

Value format: <header-field> [ ":" <regexp> ]

This specifies the header field that contains the result information of the spam scanner and it may express the syntax of the content of the header.

If no matching header is found in the message, the spamtest command will match against 0.

This is a structured setting. The first part specifies the header field name. Optionally, a POSIX regular expression follows the header field name, separated by a colon. Any white space directly following the colon is not part of the regular expression. If the regular expression is omitted, any header content is accepted and the full header value is used. When a regular expression is used, it must specify one match value (inside brackets) that yields the desired spam scanner result.

If the header does not match the regular expression or if no value match is found, the spamtest test will match against 0 during Sieve script execution.

`sieve_spamtest_status_type`

Default	[None]
Value	string
Allowed Values	`scorestrlentext`
See Also	Sieve spamtest extension

This specifies the type of status result that the spam/virus scanner produces.

This can either be a numeric score (score), a string of identical characters (strlen), e.g. '*******', or a textual description (text), e.g. 'Spam' or 'Not Spam' (see sieve_spamtest_text_value).

`sieve_spamtest_text_value`

Default	[None]
Value	String List
See Also	Sieve spamtest extension

When the sieve_spamtest_status_type setting is set to text, this setting specifies what values the spamtest test will match against to obtain the score value. For each recognized numeric score value this string list setting yields the text to match against. Score values between 0 and 10 are recognized.

Example:

sieve_spamtest_status_header = X-Spam-Verdict
sieve_spamtest_status_type = text
sieve_spamtest_text_value {
  1 = Not Spam
  10 = Spam
}

`sieve_trace_addresses`

Default	`no`
Value	boolean
See Also	Sieve trace debugging

Enables showing byte code addresses in the trace output, rather than only the source line numbers.

`sieve_trace_debug`

Default	`no`
Value	boolean
See Also	Sieve trace debugging

Enables highly verbose debugging messages that are usually only useful for developers.

`sieve_trace_dir`

Default	[None]
Value	string
See Also	Sieve trace debugging

The directory where trace files are written.

Trace debugging is disabled if this setting is not configured or if the directory does not exist.

If the path is relative or it starts with ~/ it is interpreted relative to the current user's home directory.

`sieve_trace_level`

Default	[None]
Value	string
See Also	Sieve trace debugging

The verbosity level of the trace messages. Trace debugging is disabled if this setting is not configured. Options are:

Option	Description
`actions`	Only print executed action commands, like keep, fileinto, reject, and redirect.
`commands`	Print any executed command, excluding test commands.
`tests`	Print all executed commands and performed tests.
`matching`	Print all executed commands, performed tests and the values matched in those tests.

`sieve_user_email`

Default	[None]
Value	string

The primary e-mail address for the user.

This is used as a default when no other appropriate address is available for sending messages.

If this setting is not configured, either the postmaster or null <> address is used as a sender, depending on the action involved.

This setting is important when there is no message envelope to extract addresses from, such as when the script is executed in IMAP.

`sieve_user_log_path`

Default	[None]
Value	string

The path to the file where the user log file is written.

A default location is used if this setting is not explicitly configured:

If the main user's personal Sieve script storage (as configured with sieve_script uses the File storage driver, the logfile is set to <filename>.log by default.
If the script is not stored as a file, the default user log file is ~/.dovecot.sieve.log.

`sieve_vacation_check_recipient`

Default	`yes`
Value	boolean
See Also	Sieve vacation extension

This setting determines whether the checks for implicit delivery are performed. If this is skipped, this means that the vacation command does not verify that the message is explicitly addressed at the recipient.

Use this option with caution. Specifying no will violate the Sieve standards and can cause vacation replies to be sent for messages not directly addressed at the recipient.

`sieve_vacation_default_period`

Default	`7d`
Value	time
See Also	Sieve vacation extension

Specifies the default period that is used when no :days or :seconds tag is specified.

The configured value must lie between sieve_vacation_min_period and sieve_vacation_max_period.

`sieve_vacation_max_period`

Default	`60d`
Value	time
See Also	Sieve vacation extension

Specifies the maximum period that can be specified for the :days tag of the vacation command.

The configured value must be larger than sieve_vacation_min_period.

A value of 0 has a special meaning: it indicates that there is no upper limit.

`sieve_vacation_min_period`

Default	`1d`
Value	time
See Also	Sieve vacation extension

Specifies the minimum period that can be specified for the :days and :seconds tags of the vacation command.

A minimum of 0 indicates that users are allowed to make the Sieve interpreter send a vacation response message for every incoming message that meets the other reply criteria (refer to RFC 5230). A value of zero is not recommended.

`sieve_vacation_send_from_recipient`

Default	`no`
Value	boolean
See Also	Sieve vacation extension

This setting determines whether vacation messages are sent with the SMTP MAIL FROM envelope address set to the recipient address of the Sieve script owner.

Normally this is set to <>, which is the default as recommended in the specification. This is meant to prevent mail loops. However, there are situations for which a valid sender address is required and this setting can be used to accommodate for those.

`sieve_vacation_use_original_recipient`

Default	`no`
Value	boolean
See Also	Sieve vacation extension

This specifies whether the original envelope recipient should be used in the check for implicit delivery.

The vacation command checks headers of the incoming message, such as To: and Cc: for the address of the recipient, to verify that the message is explicitly addressed at the recipient. If the recipient address is not found, the vacation action will not trigger a response to prevent sending a reply when it is not appropriate.

Normally only the final recipient address is used in this check. This setting allows including the original recipient specified in the SMTP session if available.

This is useful to handle mail accounts with aliases. Use this option with caution: if you are using aliases that point to more than a single account, as senders can get multiple vacation responses for a single message.

Use the LDA -a option or the LMTP/LDA lda_original_recipient_header setting to make the original SMTP recipient available to Sieve.

`sieve_variables_max_scope_count`

Default	`255`
Value	unsigned integer
See Also	Sieve vacation extension
Advanced Setting; this should not normally be changed.

The maximum number of variables that can be declared in a scope.

There are currently two variable scopes: the normal script scope and the global scope created by the Sieve include extension.

The minimum value for this setting is 128.

`sieve_variables_max_value_size`

Default	`4k`
Value	size
See Also	Sieve variables extension
Advanced Setting; this should not normally be changed.

The maximum allowed size for the value of a variable. If exceeded at runtime, the value is always truncated to the configured maximum.

The minimum value for this setting is 4000 bytes.

`sieve_virustest_score_max_header`

Default	[None]
Value	string
See Also	Sieve virustest extension

Value Format: <header-field> [ ":" <regexp> ]

The syntax is identical to sieve_virustest_status_header. This setting cannot be used together with sieve_virustest_score_max_value.

`sieve_virustest_score_max_value`

Default	[None]
Value	string
See Also	Sieve virustest extension

This statically specifies the maximum value a numeric spam score can have. This setting cannot be used together with sieve_virustest_score_max_header. This setting can specify a fractional score with a decimal point.

`sieve_virustest_status_header`

Default	[None]
Value	string
See Also	Sieve virustest extension

Value Format: <header-field> [ ":" <regexp> ]

This specifies the header field that contains the result information of the spam scanner and it may express the syntax of the content of the header.

If no matching header is found in the message, the spamtest command will match against 0.

If the header does not match the regular expression or if no value match is found, the spamtest test will match against 0 during Sieve script execution.

`sieve_virustest_status_type`

Default	[None]
Value	string
Allowed Values	`scorestrlentext`
See Also	Sieve virustest extension

This specifies the type of status result that the spam/virus scanner produces.

`sieve_virustest_text_value`

Default	[None]
Value	String List
See Also	Sieve virustest extension

When the sieve_virustest_status_type setting is set to text, this setting specifies what values the spamtest test will match against to obtain the score value. For each recognized numeric score value this string list setting yields the text to match against. Score values between 0 and 10 are recognized.

Example:

sieve_virustest_status_header = X-VirusCheck
sieve_virustest_status_type = text
sieve_virustest_text_value {
  1 = Clean
  2 = Presumed Clean
  3 = Not sure
  4 = Almost Certain
  5 = Definitely
}

Extension-specific Configuration

Sieve language extensions may have specific configuration.

See Sieve extensions for a list of extensions and links to their configuration pages.

Per-user Sieve script location

By default, the Dovecot Sieve plugin looks for the user's Sieve script file in the user's home directory (~/.dovecot.sieve). This requires that the Home Directories for Virtual Users is set for the user.

If you want to store the script elsewhere, you can override the default by configuring a personal script storage. This can be done in two ways:

Define the full sieve_script block in dovecot configuration.
Return the user-specific settings as a extra fields from userdb: Extra Fields.

For example, to use a Sieve script file named <username>.sieve in /var/sieve-scripts, use:

sieve_script personal {
  path = /var/sieve-scripts/%{user}.sieve
}

You may use templates like %{user}, as shown in the example. See Settings variables.

A relative path (or just a filename) will be interpreted to point under the user's home directory.

Executing Multiple Scripts Sequentially

The Dovecot Sieve plugin allows executing multiple Sieve scripts sequentially. The extra scripts can be executed before and after the user's private script. For example, this allows executing global Sieve policies before the user's script. See the before and after Sieve storage types for details on how to configure the execution sequence.

The script execution ends when the currently executing script in the sequence does not yield a "keep" result: when the script terminates, the next script is only executed if an implicit or explicit "keep" is in effect. Thus, to end all script execution, a script must not execute keep and it must cancel the implicit keep, e.g. by executing discard; stop;.

This means that the command keep; has different semantics when used in a sequence of scripts. For normal Sieve execution, keep; is equivalent to fileinto "INBOX";, because both cause the message to be stored in INBOX.

However, in sequential script execution, it only controls whether the next script is executed. Storing the message into INBOX (the default folder) is not done until the last script in the sequence executes (implicit) keep.

To force storing the message into INBOX earlier in the sequence, the fileinto command can be used (with :copy or together with keep;).

Apart from the keep action, all actions triggered in a script in the sequence are executed before continuing to the next script. This means that when a script in the sequence encounters an error, actions from earlier executed scripts are not affected. The sequence is broken however, meaning that the script execution of the offending script is aborted and no further scripts are executed. An implicit keep is executed in stead.

Just as for executing a single script the normal way, the Dovecot Sieve plugin takes care never to duplicate deliveries, forwards or responses. When vacation actions are executed multiple times in different scripts, the usual error is not triggered: the subsequent duplicate vacation actions are simply discarded.

For example:

# Global scripts executed before the user's personal script.
#   E.g. handling messages marked as dangerous
sieve_script before1 {
  type = before
  path = /var/lib/dovecot/sieve/discard-viruses.sieve
}

# Domain-level scripts retrieved from LDAP
sieve_script before2 {
  type = before
  name = ldap-domain
  driver = ldap
  # ldap settings here: ...
}

# User-specific scripts executed before the user's personal script.
#   E.g. a vacation script managed through a non-ManageSieve GUI.
sieve_script before3 {
  type = before
  path = /var/vmail/%{user | domain}/%{user | username}/sieve-before
}

# User-specific scripts executed after the user's personal script.
# (if keep is still in effect)
#   E.g. user-specific default mail filing rules
sieve_script after1 {
  type = after
  path = /var/vmail/%{user | domain}/%{user | username}/sieve-after
}

# Global scripts executed after the user's personal script
# (if keep is still in effect)
#   E.g. default mail filing rules.
sieve_script after2 {
  type = after
  path = /var/lib/dovecot/sieve/after.d/
}

TIP

Be sure to manually pre-compile the scripts specified by before and after Sieve storage types by using the sievec tool.

Visible Default Script

The default Sieve storage type specifies the location of a default script that is executed when the user has no active personal script.

Normally, this default script is invisible to the user; i.e., it is not listed in ManageSieve server.

To give the user the ability to see and read the default script, it is possible to make it visible under a specific configurable name using sieve_script_name in the sieve_script block of the default storage setting. The default storage needs to point to a valid script location as well for this to work: if the default script does not exist at the indicated location, it is not shown.

ManageSieve will magically list the default script under that name, even though it does not actually exist in the user's normal personal script storage. This way, the ManageSieve client can see that it exists and it can retrieve its contents. If no normal script is active, the default is always listed as active. The user can replace the default with a custom script, by uploading it under the default script's name. If that custom script is ever deleted, the default script will reappear from the shadows implicitly.

This way, ManageSieve clients will not need any special handling for this feature. If the name of the default script is equal to the name the client uses for the main script, it will initially see and read the default script when the user account is freshly created. The user can edit the script, and when the edited script is saved through the ManageSieve client, it will override the default script. If the user ever wants to revert to the default, the user only needs to delete the edited script and the default will reappear.

sieve_script personal {
  path = ~/sieve
  active_path = ~/.dovecot.sieve
}

sieve_script default {
  type = default
  name = roundcube
  path = /var/lib/dovecot/sieve/default.sieve
}

Trace Debugging

Trace debugging provides detailed insight in the operations performed by the Sieve script. Messages about what the Sieve script is doing are written to the specified directory.

WARNING

On a busy server, this functionality can quickly fill up the trace directory with a lot of trace files. Enable this only temporarily and as selective as possible; e.g., enable this only for a few users by returning the settings below from userdb as userdb: Extra Fields rather than enabling these for everyone.

Settings

These settings apply to both the Sieve plugin and imap-sieve plugin.

`sieve_trace_addresses`

Default	`no`
Value	boolean
See Also	Sieve trace debugging

Enables showing byte code addresses in the trace output, rather than only the source line numbers.

`sieve_trace_debug`

Default	`no`
Value	boolean
See Also	Sieve trace debugging

Enables highly verbose debugging messages that are usually only useful for developers.

`sieve_trace_dir`

Default	[None]
Value	string
See Also	Sieve trace debugging

The directory where trace files are written.

Trace debugging is disabled if this setting is not configured or if the directory does not exist.

If the path is relative or it starts with ~/ it is interpreted relative to the current user's home directory.

`sieve_trace_level`

Default	[None]
Value	string
See Also	Sieve trace debugging

The verbosity level of the trace messages. Trace debugging is disabled if this setting is not configured. Options are:

Option	Description
`actions`	Only print executed action commands, like keep, fileinto, reject, and redirect.
`commands`	Print any executed command, excluding test commands.
`tests`	Print all executed commands and performed tests.
`matching`	Print all executed commands, performed tests and the values matched in those tests.

Databases

Mechanisms

Users

Extensions

Sieve Plugin (sieve) ​

Configuration ​

Script storage ​

Script storage types ​

personal ​

after ​

before ​

default ​

discard ​

global ​

Script storage drivers ​

Common Settings ​

sieve_script

sieve_script_bin_path

sieve_script_cause

sieve_script_driver

sieve_script_name

sieve_script_precedence

sieve_script_storage

sieve_script_type

File storage driver ​

Configuration ​

sieve_script_active_path

sieve_script_path

sieve_script_name ​

sieve_script_bin_path ​

Example ​

Dict storage driver ​

Configuration ​

sieve_script_name ​

sieve_script_bin_path ​

Examples ​

Flat File Driver ​

Using a SQL Driver ​

LDAP storage driver ​

Configuration ​

ldap_auth_dn

ldap_auth_dn_password

ldap_auth_sasl_authz_id

ldap_auth_sasl_mechanisms

ldap_auth_sasl_realm

ldap_base

ldap_debug_level

ldap_deref

ldap_scope

ldap_starttls

ldap_uris

ldap_version

sieve_script_ldap_filter

sieve_script_ldap_modified_attribute

sieve_script_ldap_script_attribute

sieve_script_name ​

sieve_script_bin_path ​

Example ​

Settings ​

managesieve_client_workarounds

managesieve_implementation_string

managesieve_logout_format

managesieve_max_compile_errors

managesieve_max_line_length

managesieve_notify_capability

managesieve_sieve_capability

recipient_delimiter

sieve_duplicate_default_period

sieve_duplicate_max_period

sieve_editheader_header_forbid_add

sieve_editheader_header_forbid_delete

sieve_editheader_max_header_size

sieve_extensions

sieve_global_extensions

sieve_implicit_extensions

sieve_include_max_includes

sieve_include_max_nesting_depth

sieve_max_actions

sieve_max_cpu_time

sieve_max_redirects

Sieve Plugin (`sieve`)

Configuration

Script storage

Script storage types

`personal`

`after`

`before`

`default`

`discard`

`global`

Script storage drivers

Common Settings

`sieve_script`

`sieve_script_bin_path`

`sieve_script_cause`

`sieve_script_driver`

`sieve_script_name`

`sieve_script_precedence`

`sieve_script_storage`

`sieve_script_type`

File storage driver

Configuration

`sieve_script_active_path`

`sieve_script_path`

`sieve_script_name`

`sieve_script_bin_path`

Example

Dict storage driver

Configuration

`sieve_script_name`

`sieve_script_bin_path`

Examples

Flat File Driver

Using a SQL Driver

LDAP storage driver

Configuration

`ldap_auth_dn`

`ldap_auth_dn_password`

`ldap_auth_sasl_authz_id`

`ldap_auth_sasl_mechanisms`

`ldap_auth_sasl_realm`

`ldap_base`

`ldap_debug_level`

`ldap_deref`

`ldap_scope`

`ldap_starttls`

`ldap_uris`

`ldap_version`

`sieve_script_ldap_filter`

`sieve_script_ldap_modified_attribute`

`sieve_script_ldap_script_attribute`

`sieve_script_name`

`sieve_script_bin_path`

Example

Settings

`managesieve_client_workarounds`

`managesieve_implementation_string`

`managesieve_logout_format`

`managesieve_max_compile_errors`

`managesieve_max_line_length`

`managesieve_notify_capability`

`managesieve_sieve_capability`

`recipient_delimiter`

`sieve_duplicate_default_period`

`sieve_duplicate_max_period`

`sieve_editheader_header_forbid_add`

`sieve_editheader_header_forbid_delete`

`sieve_editheader_max_header_size`

`sieve_extensions`

`sieve_global_extensions`

`sieve_implicit_extensions`

`sieve_include_max_includes`

`sieve_include_max_nesting_depth`

`sieve_max_actions`

`sieve_max_cpu_time`

`sieve_max_redirects`

`sieve_max_script_size`

`sieve_notify_mailto_envelope_from`

`sieve_plugins`

`sieve_quota_script_count`