Yeah, they still work. I found my bug and the unique login_dir works now. I actually like being able to setup a separate SQL auth for different virtual servers. Now, if there was only a post_login script :)

On 12/22/06, Timo Sirainen tss@iki.fi wrote:

On 19.12.2006, at 6.52, Cassidy B. Larson wrote:

...

Just a quick question, nothing broke.

I setup about 5 virtual servers. It's great! I can define which protocols to listen on per server. Just curious why I can specify a unique "login_dir" per server, but not a unqiue login_greeting?

Appears dovecot always shows the first login_greeting from the first virtual server.

Intended this way?

You mean the server {} blocks? Do they still actually work? ;) I thought they had broken long time ago and I haven't even tried to keep them working.. I was planning on rewriting that part of the code once my master/config rewrite was finished.

That'd work if I were wanting to run it on my destination server. Instead, I want to run it on my proxy server after auth succeeds then proxy off the request to the destination. I dont suppose the mail_executable will work on a proxy server, or if there's some other variable I can return in a SQL result to run an executable?

-cassidy

On 12/22/06, Timo Sirainen tss@iki.fi wrote:

Umm. Like this? http://wiki.dovecot.org/PostLoginScripting

Nope. Two possibilities:

1. Modify the sources.

2. Create a dovecot-auth proxying daemon. Login process connects to your proxy, which in turn connects to dovecot-auth and just proxies the data. Then whenever it sees that a login succeeds, it executes whatever you want.

I'm not really planning on adding a post_login setting soon, since mail_executable works for pretty much everyone. Have to think about the proxying problem more before implementing anything.

My original idea was for my proxys to do some popbeforesmtp insertions into a database upon auth-success. Since the proxy knows the remote IP but the destination servers wont. My solution, for those that care, was to send my logging off to syslog, and have it execute a perl script which just listens for input. Grab the correct string via regex (from the wiki), make sure it's a non-local IP, and INSERT it into the table (going to switch to REPLACE syntax soon enough, so I dont have to worry about duplicates, nor tons of entries in my table). Seems to work fine with my current load. I'd be willing to share my hacks with any that might be interested.

Thanks,

-c

Also I think dovecot-auth would need to support two kinds of IP address %variables then. The proxy's and the client's. Which ones should be the defaults? Client's, I think?

Clients, definitely. Since dovecot-auth should already know the proxy IP. A fun way I just thought up that might work in my situation (with some SQL magic.. aww.. if only I could figure out MySQL SPs :)), would be to have a delimiter character (like the master user) that I could append the client IP to the username. Then strip it out and the IP on the other side and use it for whatever I need to.