On Fri, 2011-02-11 at 13:05 +0100, Thomas Hummel wrote:
> Besides, my understanding is that with dovecot linked to libwrap, I can
> avoid spawning imap-login through inetd. Is that correct ?
You can't spawn imap-login through inetd at all with v2.0 anymore.
On Fri, 2011-02-11 at 14:19 +0100, Thomas Hummel wrote:
> On Fri, Feb 11, 2011 at 01:11:15PM +0100, Pascal Volk wrote:
>
> > You have to configure also a service for the tcpwrapper:
> >
> > service tcpwrap {
> > unix_listener login/tcpwrap {
> > group = $default_login_user
> > mode = 06
On Fri, Feb 11, 2011 at 01:11:15PM +0100, Pascal Volk wrote:
> You have to configure also a service for the tcpwrapper:
>
> service tcpwrap {
> unix_listener login/tcpwrap {
> group = $default_login_user
> mode = 0600
> user = $default_login_user
> }
> }
Oh yes, thanks.
Also, is
On 02/11/2011 01:05 PM Thomas Hummel wrote:
> I tried this (dovecot is compiled with support for tcpwrappers) but I get :
>
> doveot: imap-login: Error: connect(tcpwrap) failed: No such file or
> directory
>
> Besides, my understanding is that with dovecot linked to libwrap, I can
> avoid sp
On Thu, Feb 10, 2011 at 12:58:29AM +0200, Timo Sirainen wrote:
> If tcpwrappers supports it, then it should be pretty easy with v2.0, as
> long as Dovecot was compiled with support for it:
>
> login_access_sockets = tcpwrap
I tried this (dovecot is compiled with support for tcpwrappers) but I ge
On Wed, 2011-02-09 at 11:57 +0100, Thomas Hummel wrote:
> My understanding is that I cannot use some negative form of "allow_nets". The
> only mechanism I can think of is tcp_wrappers. However, dovecot documentation
> mention it only in the dovecot-1 section. Does it work the same way with
> dove