dovecot - Jan 2012 - proxy, managesieve and ssl?

Hello,

On a dovecot 2.0.14 proxy, I found that proxying managesieve works well 
when using 'starttls' option in pass_attrs, but does not work when using
'ssl' option. The backend server is also dovecot 2.0.14; when using the 
ssl option, it reports "no auth attempts" in the logs about 
managesieve-login, and meanwhile the MUA, Thunderbird with sieve plugin, 
reports [TRYLATER] account is temporary disabled; no problem when using 
starttls option on the proxy, all works well.

I would like to use IMAPs, instead of IMAP+STARTTLS, from proxy to 
backend, and have Managesieve still working. Is this supported?

Thanks,
-- 
Nicolas

On 11.1.2012, at 21.01, Nicolas KOWALSKI wrote:
> On a dovecot 2.0.14 proxy, I found that proxying managesieve works well 
> when using 'starttls' option in pass_attrs, but does not work when
using
> 'ssl' option. The backend server is also dovecot 2.0.14; when using
the
> ssl option, it reports "no auth attempts" in the logs about 
> managesieve-login, and meanwhile the MUA, Thunderbird with sieve plugin, 
> reports [TRYLATER] account is temporary disabled; no problem when using 
> starttls option on the proxy, all works well.
> 
> I would like to use IMAPs, instead of IMAP+STARTTLS, from proxy to 
> backend, and have Managesieve still working. Is this supported?
You'll need to kludge it a little bit. I guess you're using LDAP, since
you mentioned pass_attrs?

protocol sieve {
  passdb {
     args = ldap-with-starttls.conf
  }
}
protocol !sieve {
  passdb {
     args = ldap-with-ssl.conf
  }
}

On 1/11/2012 8:01 PM, Nicolas KOWALSKI wrote:
> Hello,
>
> On a dovecot 2.0.14 proxy, I found that proxying managesieve works well
> when using 'starttls' option in pass_attrs, but does not work when
using
> 'ssl' option. The backend server is also dovecot 2.0.14; when using
the
> ssl option, it reports "no auth attempts" in the logs about
> managesieve-login, and meanwhile the MUA, Thunderbird with sieve plugin,
> reports [TRYLATER] account is temporary disabled; no problem when using
> starttls option on the proxy, all works well.
>
> I would like to use IMAPs, instead of IMAP+STARTTLS, from proxy to
> backend, and have Managesieve still working. Is this supported?
Although there is no such thing as a standard sieveS protocol, you can 
make Dovecot v2.x talk SSL from the start at a ManageSieve socket. Since 
normally people will not use something like this, it is not available by 
default.

In conf.d/20-managesieve.conf you can adjust the service definition of 
ManageSieve as follows:

service managesieve-login {
   inet_listener sieve {
     port = 4190
   }

   inet_listener sieves {
     port = 5190
     ssl = yes
   }
}

This starts the normal protocol on port 4190 and the direct-SSL version 
on an alternative port.  You can also put the ssl=yes directly in the 
port 4190 listener, as long as no client will have to connect to this 
server directly (no client will support it).

Regards,

Stephan.

On Wed, Jan 11, 2012 at 10:06:51PM +0100, Stephan Bosch
wrote:
> On 1/11/2012 8:01 PM, Nicolas KOWALSKI wrote:
> >
> >I would like to use IMAPs, instead of IMAP+STARTTLS, from proxy to
> >backend, and have Managesieve still working. Is this supported?
> 
> Although there is no such thing as a standard sieveS protocol, you
> can make Dovecot v2.x talk SSL from the start at a ManageSieve
> socket. Since normally people will not use something like this, it
> is not available by default.
> 
> In conf.d/20-managesieve.conf you can adjust the service definition
> of ManageSieve as follows:
> 
> service managesieve-login {
>   inet_listener sieve {
>     port = 4190
>   }
> 
>   inet_listener sieves {
>     port = 5190
>     ssl = yes
>   }
> }
This works well, when using (as Timo wrote) a different ldap pass_attrs 
for sieve, specifying this specific 5190 port. Thanks for your 
suggestion.

> This starts the normal protocol on port 4190 and the direct-SSL
> version on an alternative port.  You can also put the ssl=yes
> directly in the port 4190 listener, as long as no client will have
> to connect to this server directly (no client will support it).
Well, as this is non-standard, I guess I will not use it. I much prefer 
to stick with what has been RFCed.

-- 
Nicolas