Re: [Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
Stephan Bosch wrote: I have updated the MANAGESIEVE patch to (hopefully) fix the compilation issues reported by Robin Breathe. This is a patch against the latest stable release 1.0.3. It currently won't compile with 1.1 due to significant changes in the master code. I can confirm that it's now compiling fairly cleanly with Sun CC under Solaris 10 again, thanks. Change Log V6 - - Corked the client output stream while producing the capability greeting and on other some other occasions as well. Some naive client implementations expect to receive this as a single tcp frame and it is a good practice to do so anyway. Using this change the Thunderbird sieve extension (v0.1.1) seemed to work. However, scripts larger than a tcp frame still caused failures. All these issues are fixed in the latest version of the sieve add-on (currently v0.1.4). 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. Configuration below: # ./dovecot -n # 1.0.3: /app/dovecot/1.0.3-managesieve/etc/dovecot.conf base_dir: /dovecot/run-managesieve/ protocols: managesieve listen: imap.brookes.ac.uk:12000 ssl_cert_file: /app/openssl/certs/public/dovecot.pem disable_plaintext_auth: no login_dir: /dovecot/run-managesieve/login login_executable: /app/dovecot/1.0.3-managesieve/libexec/dovecot/managesieve-login login_processes_count: 16 login_max_processes_count: 512 max_mail_processes: 8192 verbose_proctitle: yes first_valid_uid: 900 first_valid_gid: 10 mail_location: maildir:%h/Maildir:INDEX=/dovecot/index/%u:CONTROL=/dovecot/control/%u mail_debug: yes mail_executable: /app/dovecot/1.0.3-managesieve/libexec/dovecot/managesieve mail_plugin_dir: /app/dovecot/1.0.3-managesieve/lib/dovecot/managesieve namespace: type: private inbox: yes auth default: cache_size: 8192 verbose: yes debug: yes passdb: driver: pam args: cache_key=%u%r%l%s dovecot userdb: driver: passwd plugin: quota: fs Regards, Robin
Re: [Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
On Fri, 2007-08-17 at 11:56 +0100, Robin Breathe wrote: Stephan Bosch wrote: I have updated the MANAGESIEVE patch to (hopefully) fix the compilation issues reported by Robin Breathe. This is a patch against the latest stable release 1.0.3. It currently won't compile with 1.1 due to significant changes in the master code. I can confirm that it's now compiling fairly cleanly with Sun CC under Solaris 10 again, thanks. Nice. 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. You could test it yourself using the method I described earlier: http://dovecot.org/list/dovecot/2007-August/024470.html Last time I forgot to mention that the second parameter to the authenticate plain should be a bese64-encoded version of a string \0username\0password (http://www.ietf.org/rfc/rfc4616.txt). The following script should for example do the trick if your username would be breathe with password hutsefluts: #!/usr/bin/perl use MIME::Base64 (); print MIME::Base64::encode(\0breathe\0hutsefluts); This produces 'AGJyZWF0aGUAaHV0c2VmbHV0cw==' and thus you would send the following command after TLS negotiation: AUTHENTICATE PLAIN AGJyZWF0aGUAaHV0c2VmbHV0cw== Please let me know when problems occur. Include any log lines that might be of interest. Regards, Stephan.
Re: [Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 16 Aug 2007, Stephan Bosch wrote:
I have updated the MANAGESIEVE patch to (hopefully) fix the compilation
issues reported by Robin Breathe. This is a patch against the latest
stable release 1.0.3. It currently won't compile with 1.1 due to
I have the problem that, if I do not explicitly set
login_dir = /var/run/dovecot/login
Managesieve-login dies with:
dovecot: Aug 17 16:01:18 Error: managesieve-login: chroot(login) failed:
No such file or directory
dovecot: Aug 17 16:01:18 Error: managesieve-login: chroot(login) failed:
No such file or directory
dovecot: Aug 17 16:01:18 Error: managesieve-login: chroot(login) failed:
No such file or directory
dovecot: Aug 17 16:01:18 Error: child 11480 (login) returned error 89
dovecot: Aug 17 16:01:18 Error: child 11481 (login) returned error 89
dovecot: Aug 17 16:01:18 Error: child 11482 (login) returned error 89
There is the default run-directory missing, I guess. If I start the
command from command line, it uses
/usr/local/dovecot-1.0.3/var/run/dovecot/login - however the base
directory does not exists.
I did not explicitly assigned login_dir in the .conf:
Some settings of dovecot -n
# 1.0.3: /usr/local/dovecot-1.0.3/etc/dovecot.conf
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot/dovecot.log
protocols: imap imaps pop3 pop3s managesieve
login_dir(default): /var/run/dovecot//login
login_dir(imap): /var/run/dovecot//login
login_dir(pop3): /var/run/dovecot//login
login_dir(managesieve): /var/run/dovecot/login
Note the difference of the last two lines (double slash)!
Secondly, I suggest to add to the README.managesieve, that the server is
using the CONTROL= directory to store the sieve scripts and that you can
set mail_location= to change that, e.g.:
protocol managesieve {
# Without the login_dir managesieve-login fails to start up
login_dir = /var/run/dovecot/login
listen = *:2000
# Otherwise the Sieve scripts would be placed into the CONTROL= dir
mail_location = maildir:%h/Maildir
}
Bye.
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRsWs1C9SORjhbDpvAQKAagf/YQta9xt1iEdzZDL+eUjEsVWX6uWwjFkC
Ge8AH85u4AOghBS8GrsVGPTyAGJP7T+wtwLjiPZI+/PVkWnQkVNYcOfMAmQRzcWl
vHhWhWgMKCHpZGsRrnmK+IzjK9IYSqQ9ApR5V7YXDHWfag6dhmvUjL4sD287o9EJ
Ssl/KkpZ1c3HPFp4GCxepxtoQXoTu9dl+wfUytYleKnh3kBN1zRy0nhxYzEsVkUO
B2aJzk0BoAy3DS5E2H3+clB1d013TzbjFotibmIs8kVzSsfkTkqlDPTxodjTUg2c
heV8S1ZQFq2+S50uvbCH7Lh4uaAEnr/9UKylqiOEtp1pcS9vMJUIXg==
=rgxC
-END PGP SIGNATURE-
Re: [Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
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. Regards, Robin
Re: [Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
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/[EMAIL PROTECTED]/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.
