[Dovecot] IMAP-proxy or not with sogo webmail and dovecot backend

Ed W lists at wildgooses.com
Thu Feb 23 00:54:53 EET 2012

On 22/02/2012 19:49, Timo Sirainen wrote:
> On 22.2.2012, at 11.38, Ed W wrote:
>>> void postlogout_init(struct module *module) { }
>>> void postlogout_deinit(void) {
>>>    system("/usr/local/bin/dovecot-postlogout.sh");
>>> }
>>> Add a few missing #includes and compile and enable for imap/pop3 and that should be it.
>> Thanks - that's really obvious and quite interesting.  I guess a simple "log" plugin makes sense.
>> Quick followup question - the logout log file currently logs a bunch of statistics such as mails read/deleted, bytes sent/received.  How might I access these from the _deinit context as above?  Apologies if this is a RTFM question?
> You'd have to build separate plugins for POP3 and IMAP, and even then it becomes tricky since there's no simple hook for catching when client gets destroyed.

Do you think you could keep something similar on your low priority 
backlog?  Clearly parsing log files or hacking the code is possible, but 
I think the interest in the login scripting shows there is general 
interest, and having a full log of logon/logoff/bytes is clearly 
interesting to more minority users?

>> Finally, do you see it feasible to offer a "scriptable" plugin interface, eg perhaps using some high performance scripting language such as lua?  Such a plugin might itself be simply a standard plugin..?  The motivation being to offer the ability to create plugins to those who are nervous of using a compiler, and of course to reduce the ability of a badly written plugin to kill dovecot?
> I've been thinking about adding a scripting language plugin to Dovecot. Perhaps even using one of the existing generators that are supposed to make this easy for multiple languages, such as SWIG. But this is pretty low priority currently..

I think SWIG is for wrapping dovecot's api into the scripting language?  
(ie you could call dovecot methods from say perl/python/etc). What I had 
in mind was the reverse, ie embed LUA inside dovecot.  Whenever dovecot 
normally calls a plugin method it will also run any [lua] scripts.

I'm sure you know how to use google, but just so we are on the same 
page, top hit (below) from google shows how straight forward this is 
(lua has been built to be extremely fast and easy to embed, ie it's not 
an arbitrary choice)


Ed W

More information about the dovecot mailing list