[Dovecot] (summarized) wishlist :-)

[Clemens Schrimpe]

Hello All (and Timo in particular :-) --

While reading through some of the conversations on this list over the past two weeks or so, I always thought "how would <this> particular problem affect you and how would you address it in your environment?".

This results in a few suggestions, or "thing to wish for", which I thought others may find useful, hence I'm posting this here.

1) the whole "post login scripting" is a mighty tool, yet it presently lacks a few more words in the documentation, i.e., the syntax of the corresponding config files isn't /entirely/ clear to me. Yes, I can replay the examples given, but I'm not fully sure, what happens when, etc. I'm perfectly willing, though, to contribute to that, by documenting findings in the Wiki2 (I'm just using 2.0.x, sorry). I'd appreciate a few more examples, so if anyone has a funny, working configuration, making good use of "post login scripting", I'd appreciate it, if you'd "show" them! :-)

Anyway: A bit more "control" over PLS would be nice. For example, I'd like to have a script invoked every time a new "session" starts (new IMAP/POP3 connection from a unique ID), as many clients open multiple connections at once and usually I wouldn't want to see the second, third, nth connection - just the first. "Nice" would also a "post logout scripting" feature - again: Both for "all" connections, as well as just for the "last" one. Yes, this certainly requires a bit more discussion, I know - but I hope to trigger just that with this message! :-)



2) The "local x.x.x.x {" feature is very nice, yet it could use some "polishing", I guess. Inclusion of ports and wildcards for either addresses or ports, for instance. I'm imagining a syntax like this:

local 1.2.3.4 		{ ... }	like now to remain backward compatible
local 1.2.3.4:*		{ ... } same result, just different new syntax -> don't care about port
local 1.2.3.4:4711	{ ... } add port restriction
local *:4711		{ ... } don't care for address, but match on port

and -of course- (yes, I am really USING IPv6), the use of "[2001:xxxx:yyyy::zzzz]" instead of "1.2.3.4" in the examples show above. If one would like to become really funky, the optional "/xx" addition to specify a prefix-length would leave no more wishes open. (Well ... maybe the use of "names" derived from DNS instead of literal addresses, of course :-)
[if this feature becomes clearer to me, I'd -again- be happy to help document it within the Wiki2]


3) The "iterate_query" in the SQL interface (I assume, there is something similar in the LDAP realm?) could be supplied with a few (optional, of course) "%x" variables, i.e., "%s" could deliver the "service" again, like with the other queries. This could tell the database engine, what the "show me all users" query is being used for ("quota", "expunge", ... basically all functions of doveadm, where you can supply a "-A" parameter). A "%{env:HOST}" could be used to tell the DB interface, which node of a multi-node installation is "asking". I.e., if you have your users distributed over multiple nodes, each one might want to perform "cleanups" only for their own users, saving a lot of bandwidth for unnecessary NFS traffic, etc. 


That's it - for now. Otherwise I'm pretty happy with dovecot, let me make that very clear here! :-) :-) :-)

	Clemens