[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dovecot
Subject:    Re: [Dovecot] imaps multiple domains proposal
From:       "Jim Flowers" <jflowers () ezo ! net>
Date:       2006-05-31 18:45:46
Message-ID: 20060531173714.M73929 () ezo ! net
[Download RAW message or body]

OK, I understand now but I anticipate Dovecot 2.0 is sometime in the future
(nothing in CVS)?  Also for the wishlist would be a per-domain default realm
so that users migrating from other systems where they don't have to include a
domain-name could do so transparantly.

--
Jim Flowers<jflowers@ezo.net>

---------- Original Message -----------
From: Timo Sirainen <tss@iki.fi>
To: "Jim Flowers" <jflowers@ezo.net>
Cc: dovecot@dovecot.org
Sent: Wed, 31 May 2006 19:19:25 +0300
Subject: Re: [Dovecot] imaps multiple domains proposal

> On May 31, 2006, at 7:20 PM, Jim Flowers wrote:
> 
> > There was a thread earlier this year that noted a difficulty in  
> > modifying
> > dovecot to handle multiple domain certificates.  This is a proposal  
> > that may
> > require only minor modifications.
> 
> I guess there could be some ways to kludge around this so that it  
> wouldn't require any major changes. But there's one problem why I  
> don't really want to touch this right now: imap-login process is  
> chrooted, so the SSL certificates etc. have to be opened before  
> chrooting. The connection is accepted after chrooting, so they can't 
>  be opened at that time anymore.
> 
> So the solutions are to either read all the certificates from a  
> directory at startup time (which I think is a bad idea) or get the  
> certificates from another non-chrooted process. The latter one is  
> what I'm planning to do with Dovecot 2.0.
> 
> You could of course also just not run login process chrooted, but I  
> won't accept code into Dovecot that only works that way. :)
> 
> > Alternatively, as virtual servers almost always use some form of  
> > lookup (in my
> > case mysql) the certificate used could be determined at time of  
> > connection,
> > similar to the way ssl_ca is handled.  For example:
> >
> > user_query = SELECT '125'as uid, '125' as gid, maildir as home,
> >      '/etc/ssl/%d/certs/dovecot.pem' as cert, '/etc/ssl/%d/private/ 
> > dovecot.pem
> >       as priv FROM mailbox WHERE username = '%u'
> 
> In Dovecot 2.0 there's a config process which can read its  
> configuration from pretty much anywhere. The login process requests  
> the configuration after accepting connections, so you could make per-
>  IP settings or whatever..
> 
> user_query wouldn't anyway work because the certificate needs to be  
> known before username is sent.
------- End of Original Message -------

[prev in list] [next in list] [prev in thread] [next in thread]