[Dovecot] (summarized) wishlist :-)

[Timo Sirainen]

On Wed, 2010-11-24 at 15:38 +0100, Clemens Schrimpe wrote:

> 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'm not sure what specifically wasn't clear to you, but I added more
text there.

> 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.

There is no clear way to distinguish between sessions. It gets worse
when many users come behind a NAT. What would you do anyway with it? If
user connects from two different IPs, are those two sessions? Anyway,
I'd think you could do all of these checks inside your script.

> "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! :-)

Yeah, some people have requested this before. But what would you use it
for? Maybe this could be part of a more generic event plugin that
allowed executing scripts when something specific happened.

> 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

I don't know about ports.. It adds annoying extra complexity. Maybe if
enough people keep asking about it. You could usually do the same with
extra IPs anyway.

> If one would like to become really funky, the optional "/xx" addition
> to specify a prefix-length would leave no more wishes open.

That's already possible. I think that should be enough for the
wildcards.

> 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. 

I thought about this first, but there aren't really many %variables
available for it. Yeah, %s could be one, but..

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

The %s would always expand to "doveadm" in these cases. (In future it
should be possible to execute multiple different commands for users with
a single -A iteration, so it couldn't work well even in theory.)

> 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. 

Yeah, %{hostname} would work. %{env:*} would only work if you start
dovecot with -k parameter, so that it won't clear the environment. Well,
maybe that's better than nothing. Added:
http://hg.dovecot.org/dovecot-2.0/rev/8ca8de045df1