I'm currently looking at dovecot for a large-scale deployment. The requirements will almost certainly mean we would use the dovecot lda with the sieve plugin.
The current method of distribution causes (binary distro) packaging to be slightly awkward IMHO. The dovecot-sieve code needs to be told where an in-tree build of dovecot lives. The fact that it _must_ be an in-tree build I was considering as a bug; the dovecot-sieve build wants to access both '.a' and '.h' files from the dovecot build but in an out-of-tree build these are in different places.
My first thoughts were to simply move the dovecot-sieve code into the dovecot tree (I imagine under src/plugins/cmusieve or similar) and rework the autoconf setup as appropriate. This sidesteps the problem for this case but does not help other 'third party' dovecot plugins.
If however a simple plugin build environment were to exist as part of a dovecot install then plugins could be distributed and built as independent packages. I quite understand that this additionally burdens dovecot development with 'stable API' concerns which may not be considered worth the effort.
Timo: have you thought about any of the above and if so which direction have your thoughts taken you?
I can justify spending a small amount of time to develop this into real code but it would be a waste to fight against or duplicate existing effort that has gone into this area. All comments welcome.