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