[Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3

Stephan Bosch stephan at rename-it.nl
Sat Aug 18 01:21:19 EEST 2007


Hi,

Robin Breathe schreef:
>  Stephan Bosch wrote:

> > On Fri, 2007-08-17 at 11:56 +0100, Robin Breathe wrote:

> >> Should the current incarnation of the patch support TLS,or is
> >> there anything I need to do to enable TLS for managesieve;the
> >> Thunderbird Sieve extension hangs when "Use TLS" option is
> >> selected.
> > Yes, it should. I'll have a look at the sieve extension's TLS
> > support this evening (i didn't know it supported TLS already). I
> > re-tested the TLS support of the managesieve patch v6 at my end and
> > it still works
>  I can confirm that TLS is working via gnutls-cli, so I guess the
>  problem must lie with the Sieve extension. Of note, we're using a
>  non-standard port (12000) and a chained, wildcard GlobalSign
>  certificate.
Ok, I have the same problem here and as for KMail I decided to dive into 
the sourcecode of Thunderbird's Sieve extension.  The offending source 
code is the following 
(extensions/sieve at mozdev.org/chrome/chromeFiles/content/editor/SieveFilterExplorer.js):

onStartTLSResponse : function(response)
{
    // activate TLS
   sieve.startTLS();

    // we should call now Capabilities ...
    // .. they can change with enabled TLS

    var request = new SieveCapabilitiesRequest();
    request.addCapabilitiesListener(event);
    request.addErrorListener(event);

    sieve.addRequest(request);
},

This method is called after the server gives an Ok response to the 
STARTTLS command. It starts the TLS negotiation and afterwards it sends 
a capability command. So, it seems like managesieve client implementors 
have a hard time reading the specification which clearly gives the 
following example (KMail had this problem as well):

C: StartTls
S: oK
<TLS negotiation, further commands are under TLS layer>
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
S: "SIEVE" "FILEINTO VACATION"
S: ok

As you can see, the server is supposed to send the CAPABILITY reponse 
implicitly, just like when the client first connects. The Sieve 
extension for Thunderbird does not expect this implicit reponse and 
sends a CAPABILITY command to get the new capabilities. The unexpected  
data  causes the  sieve extension's connection attempt to freeze. The 
following log shows the sequence of commands:

Aug 18 00:14:29 xi dovecot: managesieve-login: managesieve: C: STARTTLS
Aug 18 00:14:31 xi dovecot: managesieve-login: managesieve: C: CAPABILITY
Aug 18 00:14:31 xi dovecot: managesieve-login: managesieve: C: AUTHENTICATE

I'll give it a try to fix it, but my Xul/JavaScript is a bit rusty. I'll 
pop the author an e-mail in either case.

Regards,

Stephan.















More information about the dovecot mailing list