[Dovecot] considering dovecot
Mark E. Mallett
mem at mv.mv.com
Wed Nov 29 21:38:52 UTC 2006
On Wed, Nov 29, 2006 at 10:38:16PM +0200, Timo Sirainen wrote:
> On Wed, 2006-11-29 at 12:47 -0500, Mark E. Mallett wrote:
> > My own MDA (which I haven't plugged here lately :) but which I do use
> > with dovecot)
> Have you tried if you could plug it into Dovecot's deliver as a
> replacement plugin to CMU sieve?
No, but that might be an interesting experiment. I *have* looked over
the interface between dovecot lda and libsieve.
> I'd like to get an alternative to it,
> but I don't really want to spend time coding yet another Sieve
> implementation. And last I checked, your code wasn't exactly
> library/plugin-friendly at least to my eyes.. :)
You're right there, but I don't think it would take much to make
it so. I have "plugged" mfl (the language) into multiple applications,
but those have been written with using the language in mind from
I see only a few obstacles to making it more generically usable (most of
you can probably hit delete now...):
- mfl/sieve code makes calls to specifically-named functions to do
actions (like "fileinto" etc). These could fairly easily be turned
into callbacks or calls via function pointers.
- mfl code thinks it knows how messages are stored in memory, and makes
some direct use of structure elements; it also makes calls to
specifically-named functions to access things like headers and mime
parts. These things could also be turned into callbacks.
- mfl code makes use of a bunch of my own suite of utility functions,
which would have to be added to the library references. Undoubtedly
some of these utility functions duplicate those in your application
(or any that would want to use it), so it would add some size to the
executable. It also creates another library dependancy to be figured
out at configure time. Neither of those are all that big of a deal,
but they might offend some purist nature.
I dunno, maybe I'll give it a shot, e.g. over the upcoming holiday.
I've been thinking about trying to make the mfl piece more standalone
anyway: the main downside being that it creates yet another library
piece to maintain and for users to download.
More information about the dovecot