This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 1 and 44 (spanning 43 versions)
Revision 1 as of 2008-04-03 22:49:53
Size: 11724
Comment: Started ManageSieve page
Revision 44 as of 2010-09-07 14:16:30
Size: 1219
Comment: Moved contact information to main page.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from ManageSieve
Line 2: Line 3:
ManageSieve service is used to manage a user's [[LDA/Sieve|Sieve]] script collection. It has the following advantages over doing it directly via filesystem:
Line 3: Line 5:
[[TableOfContents]]  * No need to let users log in via FTP/SFTP/etc, which could be difficult especially with virtual users.
 * ManageSieve is a [[http://tools.ietf.org/html/rfc5804|standard protocol]], so users can manage their scripts using (hopefully) user-friendly ManageSieve clients. Many webmails already include a ManageSieve client.
 * Scripts are compiled before they are installed, which guarantees that the uploaded script is valid. This prevents a user from inadvertently installing a broken Sieve script.
Line 5: Line 9:
== Introduction == Dovecot's ManageSieve support is distributed in a separate package from the [[http://pigeonhole.dovecot.org/|Pigeonhole project]]. There exists also an alternative [[http://gitorious.org/pysieved/pages/Home|pysieved]] ManageSieve server that works with Dovecot.
Line 7: Line 11:
The [:LDA/Sieve:Sieve plugin] for Dovecot's '''''[:LDA:deliver]''''' LDA expects a user's Sieve script to reside somewhere in the user's directory (~/.dovecot.sieve by default). If the user is to be able to change his sieve script, he needs shell or FTP access to his home directory, which is not always desirable. This is especially applicable to mail servers with virtual users. As a solution, the ManageSieve protocol was proposed to manage sieve scripts on the server without the need for direct file system access by the users. Additionally, the Sieve scripts are compiled before they are installed, making sure that the uploaded script is valid. This prevents a user from inadvertently installing a broken Sieve script. The protocol specification still has a draft status, but it is already supported by quite a few (web)mail clients. Dovecot now supports ManageSieve by means of an external patch and package. Alternatively, an external python-based daemon called [http://woozle.org/~neale/src/pysieved/ pysieved] written by Neale Pickett can be used, but this page only describes the native Dovecot implementation.

== Versions and Downloading ==

The ManageSieve daemon is available for both Dovecot v1.0 and v1.1. There is an important architectural difference between the two implementations however. The v1.0 version is a very large patch that includes another copy of the CMU Sieve library as used by deliver's [:LDA/Sieve:Sieve plugin]. In contrast, the v1.1 version is largely implemented as an external package with a small patch to enable ManageSieve service support in Dovecot itself. The v1.1 implementation no longer includes another copy of the CMU Sieve library: it uses the Sieve plugin package for compilation against the Sieve library. With the advent of Dovecot v2.0, the small patch that is now still necessary for Dovecot v1.1 is likely to disappear completely, as Dovecot will then 1include support for custom services.

The latest versions of the ManageSieve implementation for Dovecot can be downloaded from the following locations:
  * Dovecot v1.0: http://www.rename-it.nl/dovecot/1.0/
   Patch filenames look as follows: '''{{{dovecot-1.0.}}}'''{{{X}}}'''{{{-MANAGESIEVE-v}}}'''{{{<version>}}}'''{{{.diff.gz}}}'''
  * Dovecot v1.1: http://www.rename-it.nl/dovecot/1.1/
   Patch filenames look as follows: '''{{{dovecot-1.1.}}}'''{{{X}}}'''{{{-managesieve-}}}'''{{{<version>}}}'''{{{.diff.gz}}}'''
   
   Package filenames look as follows: '''{{{dovecot-1.1-managesieve-}}}'''{{{<version>}}}'''{{{.tar.gz}}}'''
The releases are signed with public key 0x3DFBB4F4 which can be found at wwwkeys.pgp.net.

== Compiling ==

=== v1.0 ===

You first need to apply the downloaded {{{.diff.gz}}} patch to your {{{dovecot-1.0}}} soure tree. This is achieved by executing the following command line inside the source tree ('{{{../patchfile.diff.gz}}}' must be substituted with the location of the patch file you downloaded):

{{{
gzip -dc ../pathfile.diff.gz | patch -p1
}}}

After applying this patch, the usual {{{./configure}}}, {{{make}}}, {{{make install}}} sequence is not enough. First the {{{automake}}}/{{{autoconf}}} structure needs to be rebuilt to include the ManageSieve sources in the compilation process. This requires {{{autotools}}} to be installed on your system. When you downloaded using Mercurial you have script called {{{autogen.sh}}} in your source tree. And you should proceed as specified [:CompilingSource:here]. Otherwise execute the following command inside the dovecot source tree:

{{{
autoreconf -i
}}}

Afterwards, you can continue the usual [:CompilingSource:build process].

=== v1.1 ===

The ManageSieve implementation for v1.1 consists of a patch in {{{.diff.gz}}} format and a separate {{{.tar.gz}}} package. You first need to patch and compile the Dovecot sources. Applying the patch is achieved by executing the following command line inside the dovecot source tree ('{{{../patchfile.diff.gz}}}' must be substituted with the location of the patch file you downloaded):

{{{
gzip -dc ../pathfile.diff.gz | patch -p1
}}}

Once patched, you can compile Dovecot using the usual [:CompilingSource:build process]. So, unlike the v1.0 implementation, you do not need {{{autotools}}}.

Another prerequisite for compiling the ManageSieve service is a compiled dovecot-sieve-1.1 source tree. Compiling the Sieve plugin is described [:LDA/Sieve:here].

Now that you have both a compiled dovecot and a compiled dovecot-sieve source tree, you can continue building the ManageSieve service. Note that the service will compile against an unpatched dovecot tree, but keep in mind that dovecot will not know about the existence of ManageSieve without the patch. Unpack the {{{.tar.gz}}} package somewhere and execute the following command sequence inside the unpacked source direcory:

{{{
./configure --with-dovecot=<dovecot source tree> --with-dovecot-sieve=<dovecot-sieve source tree>
make
sudo make install
}}}

The parameters to {{{./configure}}} represent the following:

 * --with-dovecot=<path>
   Path to the compiled dovecot-1.1 tree


 * --with-dovecot-sieve=<path>
   Path to the compiled dovecot-sieve-1.1 tree

== Configuring ==

Along with all other binaries that dovecot uses, the managesieve and managesieve-login binaries are installed during {{{make install}}}. The only thing you need to do to activate the ManageSieve support in dovecot is to add {{{managesieve}}} to the {{{protocols=}}} configuration line in your dovecot.conf. The managesieve daemon will listen on port 2000 by default. As the implementation of the managesieve daemon is largely based on the original IMAP implementation, it is very similar in terms of configuration. In addition to most [:MainConfig:mail daemon config settings], the managesieve daemon accepts a few more. The following settings can be configured in the {{{protocol managesieve}}} section:

 listen = *:2000:: IP or host address where to listen in for connections.

 login_executable = /usr/libexec/dovecot/managesieve-login:: Login executable location.

 mail_executable = /usr/libexec/dovecot/managesieve:: managesieve executable location. See mail_executable for IMAP for examples how this could be changed.
 
 managesieve_max_line_length = 65536:: Maximum managesieve command line length in bytes. This setting is directly borrowed from IMAP. But, since long command lines are very unlikely with MANAGESIEVE, changing this will not be very useful.

 sieve=~/.dovecot.sieve:: Specifies the location of the symlink pointing to the active script in the sieve storage directory. This must match the [:LDA/Sieve#location:sieve setting used by deliver]. Variable substitution with % is recognized.
  
 sieve_storage=~/sieve:: This specifies the path to the directory where the uploaded scripts must be stored. In terms of '%' variable substitution it is identical to dovecot's {{{mail_location}}} setting used by the mail protocol daemons.

 mail_location =:: If, for some inobvious reason, the sieve_storage remains unset, the managesieve daemon uses the specification of the mail_location to find out where to store the sieve files. However, this is provided only for backwards compatibility and you should always use the sieve_storage setting in stead.

 managesieve_implementation_string = dovecot:: To fool ManageSieve clients that are focused on CMU's timesieved you can specify the IMPLEMENTATION capability that the dovecot reports to clients (e.g. '{{{Cyrus timsieved v2.2.13}}}').

Scripts are stored at the location specified by the {{{sieve_storage}}} config setting. The active sieve script is managed as a symbolic link pointing to the active script in the sieve storage direcotory. The location of this symlink can be specified with the {{{sieve}}} config setting. Make sure this setting is identical to what [:LDA:deliver] is using for the [:LDA/Sieve:Sieve plugin]. The default location is {{{~/.dovecot.sieve}}}. Note that if a file starting with '.' is placed inside a Maildir, it will be recognized as a folder, so try to avoid that.

The current version of the managesieve daemon places the script storage directory in the mail folder as specified by the {{{mail_location}}} config setting if no sieve_storage is specified. Actually, it is placed in the {{{CONTROL=}}} directory of {{{mail_location}}} if specified, otherwise the {{{sieve}}} directory is placed in the root of the mail location. In a mail or mail control directory, scripts are always stored in a {{{sieve}}} subdirectory. Note that for some mail storage types (e.g. mbox) this script directory is listed as a mail folder, so be sure to put the sieve scripts somewhere else if you can.

A storage location specified by {{{sieve_storage}}} is always generated automatically if it does not exist (as far as the system permits the user to do so; no root privileges are used). This is similar to the behavior of the mail daemons. Note that when {{{mail_location}}} is used to specify the script storage location, only the {{{sieve}}} subdirectory is generated automatically.

The following provides an example configuration for ManageSieve in dovecot.conf. Only sections relevant to ManageSieve are shown. Refer to dovecot-example.conf in your patched dovecot tree for a full example with comments, but don't forget to add {{{managesieve}}} to the {{{protocols}}} setting if you use it.

{{{
# Start imap, pop3 and managesieve services
protocols = imap pop3 managesieve

protocol managesieve {
  # Specify an alternative address:port the daemon must listen on
  # (default: *:2000)
  #listen = localhost:2000

  sieve=~/.dovecot.sieve
  sieve_storage=~/sieve
}
}}}

=== Proxying ===

Like Dovecot's imapd, the ManageSieve login daemon supports proxying to multiple backend servers. Although the underlying code is copied from the imapd sources for the most part, it has some ManageSieve-specifics that have not seen much testing. The [:PasswordDatabase/ExtraFields/Proxy:proxy configuration wiki page] for POP3 and IMAP should apply to ManageSieve as well.

== Known Issues ==

 *Although this ManageSieve server should comply with the draft specification of the ManageSieve protocol, quite a few clients don't. This is particularly true for the TLS support. However, now that Cyrus' Timsieved has changed its behaviour towards protocol compliance, all those clients will follow eventually.


 The following clients are known to have TLS issues:
   

  Thunderbird Sieve add-on:: (author is working on it)
   
  KMail + kio_sieve::


 Unfortunately, there is no reliable way to provide a workaround for this problem. We will have to wait for the authors of these clients to make the proper adjustments.
 *Other client issues:
  SquirrelMail/AvelSieve:: For some users the avelsieve client stores scripts but fails to retrieve them later. This problem is somehow hard to reproduce at my end. Someone suggested that it might be TLS-related.
 *The current implementation of the daemon does not have quota enforcement as recommended in the specification. So keep in mind that malicious users could fill your file system with loads of spurious scriptfiles.
 *The ANONYMOUS authentication mechanism is currently not supported and explicitly denied.

== Contact Info ==

 * Author: Stephan Bosch, stephan@rename-it.nl
 * IRC: Freenode, #dovecot, S[r]us
 * Please use the Dovecot [http://www.dovecot.org/mailinglists.html mailing list] for questions about the ManageSieve service. You don't have to subscribe to it.
 * [[Pigeonhole|Download and Installation]]
 * [[Pigeonhole/ManageSieve/Configuration|Configuration]]
 * [[Pigeonhole/ManageSieve/Troubleshooting|Troubleshooting]]
 * [[Pigeonhole/ManageSieve/Clients|Client Issues]]

Dovecot ManageSieve Server

ManageSieve service is used to manage a user's Sieve script collection. It has the following advantages over doing it directly via filesystem:

  • No need to let users log in via FTP/SFTP/etc, which could be difficult especially with virtual users.
  • ManageSieve is a standard protocol, so users can manage their scripts using (hopefully) user-friendly ManageSieve clients. Many webmails already include a ManageSieve client.

  • Scripts are compiled before they are installed, which guarantees that the uploaded script is valid. This prevents a user from inadvertently installing a broken Sieve script.

Dovecot's ManageSieve support is distributed in a separate package from the Pigeonhole project. There exists also an alternative pysieved ManageSieve server that works with Dovecot.

None: Pigeonhole/ManageSieve (last edited 2019-09-12 08:43:59 by MichaelSlusarz)