[Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2
Hello dovecot users,
I have finally updated the MANAGESIEVE patch to fix the currently known small problems with the protocol implementation. Also, I included a proxy implementation based on imap-proxy.c. This patch is designed for dovecot release 1.0.2 and it will not apply cleanly to the 1.1 versions yet.
Change Log V5
- Applied patch by Uldis Pakuls to fix master_dump_settings bug
- Added some compilation/installation info to the README
- Moved README to source tree's root as README.managesieve
- Fixed minor error handling bug in sieve_storage.c with respect to a missing root directory.
- Now sieve capabilities are reported as they are specified by the implementing library and not in forced upper case. The sieve RFC now explicitly states that sieve capability identifiers are case-sensitive. This broke compatibility with SquirrelMail/Avelsieve.
- Disabled ANONYMOUS login entirely until proper support is implemented. V4 claimed to do so as well, but in fact it only stopped announcing it.
- Implemented managesieve-proxy. It is not so much a clean copy of imap-proxy, since the managesieve greeting is much more complex and requires parsing. Configuration is identical to imap-proxy. This seems to be a little under-documented however (http://wiki.dovecot.org/PasswordDatabase/ExtraFields).
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).
Current plans include merging src/lib-managesieve with src/lib-imap, updating the patch for dovecot-1.1 and fixing any problems you might find.
The patch can be downloaded at:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.2-MANAGESIEVE-v5.diff.gz
The README.managesieve is located in the root of the dovecot source tree after applying the patch.
Have fun testing the patch. Notify me when there are problems.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
Stephan Bosch wrote:
I have finally updated the MANAGESIEVE patch to fix the currently known small problems with the protocol implementation. Also, I included a proxy implementation based on imap-proxy.c. This patch is designed for dovecot release 1.0.2 and it will not apply cleanly to the 1.1 versions yet.
Thank you Stephan !
On Tuesday 31 July 2007 01:41:11 Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems.
Hello Stephan,
I still get the following message when trying to connect and authenticate:
Choose a different authentication method to PLAIN.
The same with LOGIN when I tell Dovecot to use the login authentication method. The logs show:
Aug 1 15:25:52 hostname dovecot: managesieve-login: Login: user=<username>, method=PLAIN, rip=aa.bb.cc.dd, lip=ww.xx.yy.zz, TLS Aug 1 15:25:52 hostname dovecot: MANAGESIEVE(username): Disconnected: Logged out
I am using real Unix users and Dovecot is configured with authdb pam and userdb passwd. I previously described the problem in [1].
Does your patch not support PLAIN or LOGIN or am I missing something?
TIA
Andreas
[1] http://www.dovecot.org/list/dovecot/2007-June/023283.html
Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
On Wed, 2007-08-01 at 15:27 +0200, Andreas Ntaflos wrote:
On Tuesday 31 July 2007 01:41:11 Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems.
Hello Stephan,
I still get the following message when trying to connect and authenticate:
Choose a different authentication method to PLAIN.
The same with LOGIN when I tell Dovecot to use the login authentication method. The logs show:
Aug 1 15:25:52 hostname dovecot: managesieve-login: Login: user=<username>, method=PLAIN, rip=aa.bb.cc.dd, lip=ww.xx.yy.zz, TLS Aug 1 15:25:52 hostname dovecot: MANAGESIEVE(username): Disconnected: Logged out
I am using real Unix users and Dovecot is configured with authdb pam and userdb passwd. I previously described the problem in [1].
Does your patch not support PLAIN or LOGIN or am I missing something? Could you give me some more information, i.e. your config, what client you test with and (if possible) a log of the connection. This way I can reproduce the situation. The managesieve patch should support all SASL mechanisms supported by dovecot. In fact, I only test using PLAIN.
Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go.
Regards,
Stephan
Hi Andreas,
On Wed, 2007-08-01 at 16:45 +0200, Stephan Bosch wrote:
Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go. I gave it a go and STARTTLS still seems to work fine at my end. This test was performed using 'disable_plaintext_auth = yes' in the config file, forcing a _remote_ host to use TLS/SSL for all protocols.
The gnutls-cli tool is very useful to test the STARTTLS command in various protocols. Using the --starttls switch the client starts in plaintext mode and starts the TLS negotiation when Ctrl-D is pressed.
With the information you provide I could test it with your setup, but of course you can test it yourself as well.
Oh, the end of this transcript might be interesting for Timo. The reported fatal error also occurs on IMAP (dovecot-1.0.2). I don't know whether gnutls-cli is just moaning or whether dovecot is not closing the tls connection very nicely...
Regards,
Stephan.
host:/# gnutls-cli -p 2000 --starttls host.example.com Resolving 'host.example.com'... Connecting to '10.0.0.1:2000'...
- Simple Client Mode:
"IMPLEMENTATION" "dovecot" "SASL" "" "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric" "STARTTLS" OK "Dovecot ready." STARTTLS OK "Begin TLS negotiation now." *** Starting TLS handshake
Certificate type: X.509
Got a certificate list of 1 certificates.
Certificate[0] info:
The hostname in the certificate matches 'host.example.com'.
# valid since: ******************************* # expires at: ******************************* # fingerprint: ******************************* # Subject's DN: O=Dovecot mail server,OU=host.,CN=host.example.com,EMAIL=root@host.example.com # Issuer's DN: O=Dovecot mail server,OU=host.,CN=host.example.com,EMAIL=root@host.example.com
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS 1.0
- Key Exchange: DHE RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE "IMPLEMENTATION" "dovecot" "SASL" "PLAIN" "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational comparator-i;ascii-numeric" OK "TLS negotiation successful." AUTHENTICATE "PLAIN" "**********" OK "Logged in." logout OK "Logout completed." *** Fatal error: A TLS packet with unexpected length was received. *** Server has terminated the connection abnormally.
On Wednesday 01 August 2007 17:53:16 Stephan Bosch wrote:
Hi Andreas,
On Wed, 2007-08-01 at 16:45 +0200, Stephan Bosch wrote:
Most likely the problem relates to the fact that, unless configured otherwise, dovecot will refuse to use plain text SASL mechanisms if the connection is not encrypted. I haven't re-tested the STARTTLS command in the last versions... I will give it a go.
I gave it a go and STARTTLS still seems to work fine at my end. This test was performed using 'disable_plaintext_auth = yes' in the config file, forcing a _remote_ host to use TLS/SSL for all protocols.
Thanks for taking the time to investigate this further! I will try to provide you with everything I can.
I have my server configured the same way, allowing only TLS connections for plaintext login on the standard IMAP port 143. I shall attach the output of dovecot -n.
The gnutls-cli tool is very useful to test the STARTTLS command in various protocols. Using the --starttls switch the client starts in plaintext mode and starts the TLS negotiation when Ctrl-D is pressed.
With the information you provide I could test it with your setup, but of course you can test it yourself as well.
I got this working just fine, using the method you described below. Of course I had to base64-encode the "username\0username\0password" string first, which is probably not so obvious to someone who doesn't have much experience debugging authentication problems :)
I am using KMail 1.9.7 and KDE 3.5.7 to connect to the server (KDE has a kioslave for sieve).
But seeing that connecting and authenticating worked fine with gnutls-cli this seems to be a KMail- oder KDE-related problem?
Is there anything else I can provide? How do you want the connection log? As the output of a tcpdump session?
Thanks again!
Andreas
# 1.0.2: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap managesieve listen(default): * listen(imap): * listen(managesieve): *:2000 ssl_cert_file: /etc/ssl/certs/pseudoterminal.org_dovecot.crt ssl_key_file: /etc/ssl/private/pseudoterminal.org.key login_dir(default): /var/run/dovecot//login login_dir(imap): /var/run/dovecot//login login_dir(managesieve): login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login mail_extra_groups: mail mail_location: maildir:~/Maildir maildir_copy_with_hardlinks: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(managesieve): outlook-idle namespace: type: public separator: / prefix: Public/ location: maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public namespace: type: private separator: / inbox: yes auth default: mechanisms: plain login passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix
-- Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Hi Andreas,
Andreas Ntaflos schreef:
I got this working just fine, using the method you described below. Of course I had to base64-encode the "username\0username\0password" string first, which is probably not so obvious to someone who doesn't have much experience debugging authentication problems :)
I am using KMail 1.9.7 and KDE 3.5.7 to connect to the server (KDE has a kioslave for sieve).
But seeing that connecting and authenticating worked fine with gnutls-cli this seems to be a KMail- oder KDE-related problem? Being curious, I installed KMail myself and I instantly get the same error. When I disable the TLS support on the server it can connect (it still tries to use STARTTLS however). But, then the trouble is not over. When trying to view a script it reports a protocol error and disconnects. This happens right after the GETSCRIPT command produces its output.
I'll have a dive into the sourcecode of KMail to see what might cause this 'incompatibility'...
Regards,
Stephan.
Hi Andreas,
Andreas Ntaflos schreef:
I got this working just fine, using the method you described below. Of course I had to base64-encode the "username\0username\0password" string first, which is probably not so obvious to someone who doesn't have much experience debugging authentication problems :)
I am using KMail 1.9.7 and KDE 3.5.7 to connect to the server (KDE has a kioslave for sieve).
But seeing that connecting and authenticating worked fine with gnutls-cli this seems to be a KMail- oder KDE-related problem? After a large series of frustrations about getting kdepim to compile, I finally found and fixed the problem in KMail. The issues were caused by small protocol violations in the kioslave implementation.
I constructed a small patch against kdepim 3.5.6/3.5.7. On Ubuntu/Debian I did not manage to do a complete kdepim build myself, because it would fail on strange linker errors reporting missing symbols. All I did was to execute ./configure in the main source tree (creating all the Makefiles) and then I changed directory to kioslaves/sieve and executed make there. This results in kio_sieve.la and kio_sieve.so being built in the local .libs direcory. I copied these to the location they are normally installed in my system (/usr/lib/kde3 for my distro), thus overwriting the originals. Then I could connect to dovecot managesieve, list scripts, delete scripts, edit scripts and save them.
The patch can be downloaded at:
http://sinas.rename-it.nl/~sirius/kdepim_sieve_patch.diff
I submitted the patch to the kdepim mailinglist and I hope they will merge it into their future releases to definitively resolve these issues.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
Hi Andreas,
Stephan Bosch wrote:
I submitted the patch to the kdepim mailinglist and I hope they will merge it into their future releases to definitively resolve these issues. The patch is committed to kde-3.5.8 and kde-4.0. So, these releases should no longer have the presented problems. However, the kde sieve code is unmaintained at the moment and other problems exist. I'm contemplating fixing the kde sieve code towards managesieve specification conformance. So, if you find other problems, you can report them to me or to the kde-pim bugtracker (if you are sure it is KDE/KMail-related).
Regards,
-- Stephan Bosch stephan@rename-it.nl
On Monday 06 August 2007 17:53:56 Stephan Bosch wrote:
Hi Andreas,
Stephan Bosch wrote:
I submitted the patch to the kdepim mailinglist and I hope they will merge it into their future releases to definitively resolve these issues.
The patch is committed to kde-3.5.8 and kde-4.0. So, these releases should no longer have the presented problems. However, the kde sieve code is unmaintained at the moment and other problems exist. I'm contemplating fixing the kde sieve code towards managesieve specification conformance. So, if you find other problems, you can report them to me or to the kde-pim bugtracker (if you are sure it is KDE/KMail-related).
Stephan,
thank you so much for taking the time to track this problem down and even supply a fix to the KDE developers. I am very much looking forward to 3.5.8 (i.e. KMail 1.9.8) and to hopefully finally being able to edit my sieve scripts without having to ssh into the mailserver.
Again, thank you!
Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems.
Stephan,
There's a small problem with your patch as it stands: it depends on a number of GCCisms, and fails to compile with, for example, Sun CC under Solaris 10. Removing all of your "__attribute__((unused))" declarations goes some way, but the build then fails with the following:
/opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/li b-storage -I../../src/lib-mail -I../../src/lib-sievestorage -I/app/openssl/0.9.7 m/include -g -c sieve-implementation.c -KPIC -DPIC -o .libs/sieve-implementatio n.o "sieve-implementation.c", line 193: void function cannot return value cc: acomp failed for sieve-implementation.c
A reasonable error given that sieve_runenv_mark_duplicate() is a void function with a return :) Removing the "return" leads to a clean build, but it's not clear what implications that might have.
NB: this is applied against dovecot-1.0.3, though only one of the hunks is off by 1 line.
Regards, Robin
On Wed, 2007-08-15 at 15:29 +0100, Robin Breathe wrote:
Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems.
Stephan,
There's a small problem with your patch as it stands: it depends on a number of GCCisms, and fails to compile with, for example, Sun CC under Solaris 10. Removing all of your "__attribute__((unused))" declarations goes some way, but the build then fails with the following:
These can be replaced with __attr_unused__.
"sieve-implementation.c", line 193: void function cannot return value cc: acomp failed for sieve-implementation.c
A reasonable error given that sieve_runenv_mark_duplicate() is a void function with a return :) Removing the "return" leads to a clean build, but it's not clear what implications that might have.
Probably just an accidental mistake. I've had the same problem when changing return values to voids. It's annoying that gcc doesn't complain about this.
Timo Sirainen wrote:
On Wed, 2007-08-15 at 15:29 +0100, Robin Breathe wrote:
Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems. Stephan,
There's a small problem with your patch as it stands: it depends on a number of GCCisms, and fails to compile with, for example, Sun CC under Solaris 10. Removing all of your "__attribute__((unused))" declarations goes some way, but the build then fails with the following:
These can be replaced with __attr_unused__.
Great.
"sieve-implementation.c", line 193: void function cannot return value cc: acomp failed for sieve-implementation.c
A reasonable error given that sieve_runenv_mark_duplicate() is a void function with a return :) Removing the "return" leads to a clean build, but it's not clear what implications that might have.
Probably just an accidental mistake. I've had the same problem when changing return values to voids. It's annoying that gcc doesn't complain about this.
Fair enough, you think that removing the return is safe/correct then?
On a side-note, I've not seen anything from you to indicate whether the managesieve functionality will be integrated into a future release. Any thoughts?
Regards, Robin
Stephan Bosch wrote:
Have fun testing the patch. Notify me when there are problems.
Stephan,
There's a small problem with your patch as it stands: it depends on a number of GCCisms, and fails to compile with, for example, Sun CC under Solaris 10. Removing all of your "__attribute__((unused))" declarations goes some way, but the build then fails with the following:
/opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/li b-storage -I../../src/lib-mail -I../../src/lib-sievestorage -I/app/openssl/0.9.7 m/include -g -c sieve-implementation.c -KPIC -DPIC -o .libs/sieve-implementatio n.o "sieve-implementation.c", line 193: void function cannot return value cc: acomp failed for sieve-implementation.c
A reasonable error given that sieve_runenv_mark_duplicate() is a void function with a return :) Removing the "return" leads to a clean build, but it's not clear what implications that might have.
NB: this is applied against dovecot-1.0.3, though only one of the hunks is off by 1 line I'll fix these issues tonight and make a release for 1.0.3. Thanks for
Robin Breathe schreef: the headsup! :)
Regards,
Stephan.
participants (5)
-
Andreas Ntaflos
-
Rene Luria
-
Robin Breathe
-
Stephan Bosch
-
Timo Sirainen