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