[Dovecot] Feature Request: content-filter / MOVE scripts
Daniel L. Miller
dmiller at amfes.com
Thu Apr 19 18:07:29 EEST 2007
Since your "1.1 plans" announcement somehow turned into everybody
handing in a wish list . . . thought I'd start one by itself - since I
expect a few people to have opinions on this matter.
I'm aware of a plug-in functionality in Dovecot, and that a plug-in
exists for dspam processing - but my review of the plug-ins indicate
they require compiling your own Dovecot - the plug-in setup isn't really
suitable for packaged distros. As a packaged software user - I really
really really don't like compiling my own software, either for features
or bugfixes - I want leave that to the experts. On learning of 1.0's
official release, I nudged the Debian package maintainers to check - and
they were already on it and it updated. Thanx Timo, Jaldhar, and Fabio.
I have some thoughts on an interface that would eliminate the need for
compile-time plug-ins, but provide some major power to sysadmins.
Basically, I want a way of telling an external program the following:
1. A message was moved.
2. The folder is moved from was XXX.
3. The folder it moved to was YYY.
4. The message moved was ZZZ.
Armed with this information, just about anybody's spam fighting learn
scripts can be called to do their thing.
A few different ways have occurred to me:
1. Have a dedicated "content-filter" functionality built-in to
Dovecot. Under this model, Dovecot.conf would include at least three
new parameters: FILTER-FOLDER-SUFFIX, FILTER-FOLDER-IN-SCRIPT, and
FILTER-FOLDER-OUT-SCRIPT. Whenever a message is moved into or out of a
folder ending in SUFFIX the appropriate SCRIPT is called, with the
arguments above being passed.
2. A bit more generic, less processing for Dovecot. Dovecot.conf
parameter ACTION-SCRIPT (hey, feel free to use other names - I'm just
brainstorming here). Any time any message is moved anywhere, call
SCRIPT with the arguments. Having never looked at Dovecot's code, I'm
just guessing, but this probably wouldn't take much to implement - but
might be the most performance affecting.
3. Have a definable named-pipe to send the same information to.
4. Have a definable TCP socket to send the same information to.
In any case, I figure it's best to prevent any message processing by
Dovecot itself - so while it might be nice to define a list of headers
to send to the scripts, instead of the whole message, that's probably
not appropriate for Dovecot to focus on. On the other hand, any of the
above options would probably benefit from a MAXIMUM_FILTER_SIZE
parameter to limit the maximum message size.
So what's the world got to say about this? (More importantly, how does
TIMO feel about this?) ;).
More information about the dovecot