[Dovecot] 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@rename-it.nl
On 25/05/2012 23:12, Stephan Bosch wrote:
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
On 27/05/2012 14:00, Daniel Parthey wrote:
That probably works for my current situation which is mainly grouping by
domain. But I wanted to allow specific users to opt out and so ideally
I want the include to be on a per user basis, not just a per domain.
Good idea though - thanks
Ed W
Op 5/27/2012 3:00 PM, Daniel Parthey schreef:
Including from global to local is not a good idea:
if the script is missing (user deletes it through managesieve) delivery fails.
Included scripts are currently always incorporated in the global binary. This means that it is not possible to pre-compile the global binary.
I have some plans to make this possible, but so far this situation is best avoided.
Regards,
Stephan.
participants (3)
-
Daniel Parthey
-
Ed W
-
Stephan Bosch