Dovecot news - May 2012 - Released Pigeonhole v0.3.1 for Dovecot v2.1.6

Hello Dovecot users,

It's been a few months since the last Pigeonhole release. The main 
reason is that I've introduced a few big new features. Although the new 
features themselves probably haven't seen much testing so far, I'm now 
pretty confident that existing configurations are not broken by these 
changes.

The biggest change is the addition of dict support for Sieve script 
retrieval. It now possible to fetch Sieve scripts from an SQL database 
using the Dovecot dict facility. Read the INSTALL file and the 
referenced additional documentation for more information. Note that this 
feature currently is not usable with sieve_before/sieve_after and 
ManageSieve.

Additionally, it is now possible to specify multiple sieve_before and
sieve_after scripts. This for instance enables administrators to specify 
both global and user-specific scripts that are to be executed before and 
after the user's personal script. User-specific scripts
configured in sieve_before and sieve_after can not be seen or changed 
through the ManageSieve protocol.

Finally, as promised a while back, I've incorporated the 
vnd.dovecot.duplicate extension into the main Pigeonhole package. Using 
this Dovecot-specific extension it is possible to detect duplicate 
deliveries (such as for example caused by mailing list subscriptions). 
The detection is based on the message ID and uses the same database file 
(~/.dovecot.lda-dupes) as the vacation extension.

Since the changes introduced in the release are rather large, I strongly 
advise you to experiment with it a bit before deployment.

Changelog v0.3.1:

  * Added support for retrieving Sieve scripts from dict lookup. This
    means that Sieve scripts can now be downloaded from a database.
    Compiled script binaries are still put on disk somewhere if used.
    The INSTALL documentation is updated with information on this new
    feature and the (backwards-compatible) changes to the configuration.
    Note that his feature is currently not supported for
    sieve_before/sieve_after or script management through ManageSieve.
  + Incorporated the sieve_duplicate plugin into main Pigeonhole tree as
    a normal extension (vnd.dovecot.duplicate). This Dovecot-specific
    extension adds the ability to check for duplicate deliveries based
    on message ID. Specification can be found in:
    doc/rfc/spec-bosch-sieve-duplicate.txt
  + Added support for specifying multiple sieve_before and sieve_after
    paths. This adds much more flexibility to the multiscript
    configuration. One application is to have user-specific Sieve
    scripts outside the user's normal control through ManageSieve.
  + Added a "session ID" string for managesieve connections, available
in
    %{session} variable (analogous to Dovecot change).
  - Fixed several small issues, including a few potential segfault bugs,
    based on static source code analysis.
  - ManageSieve: changed use of EPROTO error to EIO in ManageSieve
    string stream implementation because it is apparently not known in
    BSD.
  - Gave stamp.h.in (needed for autotools) some content to prevent it
    from disappearing in patch files.
  - Fixed bug that caused a SunStudio CC compile failure (reported by
    Piotr Tarnowski).

The release is available as follows:

http://www.rename-it.nl/dovecot/2.1/dovecot-2.1-pigeonhole-0.3.1.tar.gz
http://www.rename-it.nl/dovecot/2.1/dovecot-2.1-pigeonhole-0.3.1.tar.gz.sig

Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for 
more information. Have fun testing this new release and don't hesitate 
to notify me when there are any problems.

Regards,

-- 
Stephan Bosch
stephan at rename-it.nl

On 25/05/2012 23:12, Stephan Bosch wrote:
>
> The biggest change is the addition of dict support for Sieve script 
> retrieval. It now possible to fetch Sieve scripts from an SQL database 
> using the Dovecot dict facility. Read the INSTALL file and the 
> referenced additional documentation for more information. Note that 
> this feature currently is not usable with sieve_before/sieve_after and 
> ManageSieve. 
This is very interesting!

In fact on reflection, I would very much like sql decided before/after 
and a disk based main sieve script.  Or phrased in terms of usage: I 
have groups of users where we have a predefined bunch of filtering that 
happens on their account. At the moment the users are grouped into top 
level directories so that the "home" and hence default scripts can 
cascade down.  However, it means it's not trivial to adjust the grouping 
of the users and requires on disk placement to be meaningful.  I would 
desire to find a way of when Postfix delivers a mail for a user X that 
this will run a bunch of predefined filtering scripts which are 
per-user, plus the users normal scripts.  All scripts would normally 
live on disk

Perhaps this is actually more easily done a different way?

Thanks for any thoughts?

Ed W