[Dovecot] Feature Request: content-filter / MOVE scripts

[Daniel L. Miller]

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?) ;).

-- 
Daniel