[Dovecot] MANAGESIEVE patch v6 for dovecot 1.0.3
Hello dovecot users,
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.
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).
- Cleaned up the new proxy source. My editor made the indentation a complete mess in terms of TABs vs spaces.
- Added TRYLATER response codes to BYE and NO messages where appropriate.
- Recopied the libsieve library into this patch to incorporate any changes that were made (only sieve-cmu.c still needs to be compared to the old cmu-sieve.c). This also solves the __attribute__((unused)) GCC dependencies. These were fixed long ago by Timo.... the code duplication beast strikes again. (Will have to do this again for dovecot 1.1)
- Removed spurious return value from void function in src/lib-sieve/sieve-implementation.c as reported by Robin Breathe. GCC fails to report these issues. The function involved is currently not used and serves only as an example on how dovecot could support multiple sieve back-ends...
This patch still includes (yet another) instance of the CMU Sieve source, as explained in one of my previous e-mails (http://dovecot.org/list/dovecot/2006-July/015016.html).
The patch can be downloaded at:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.3-MANAGESIEVE-v6.diff.gz
The README.managesieve is located in the root of the dovecot source tree after applying the patch.
Have fun testing the patch. Don't hesitate to notify me when there are problems.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
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
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.
Stephan Bosch 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
On Fri, 2007-08-17 at 11:56 +0100, Robin Breathe wrote: 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
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@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
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.
-----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/loginManagesieve-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-----
participants (3)
-
Robin Breathe
-
Steffen Kaiser
-
Stephan Bosch