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:
- A message was moved.
- The folder is moved from was XXX.
- The folder it moved to was YYY.
- 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:
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.
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.
Have a definable named-pipe to send the same information to.
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