[Dovecot] [Fwd: [PATCH] Dovecot-1.0rc2 MANAGESIEVE]
Timo Sirainen wrote:
I have constructed a patch against dovecot-1.0rc2 (it currently also applies more or less cleanly to the HEAD cvs branch, but you will get a compile error due to a (typo) namechange in lib/buffer.h. This is easy to fix in src/managesieve/commands.c). This patch can be downloaded from:
This managesieve daemon still needs some work (a small TODO list can be found in the src/managesieve/README file), but I hope you like it enough to incorporate it in the main dovecot package in the future. I would greatly appreciate your feedback.
This is awesome news; I wish I could test it... :(
Applying the patch and running any/all of:
aclocal
automake
autoconf
configureand it appears that the Makefile.am and Makefile.in are not being seen and no Makefile is being generated for the new features. Any autoconf wizards out there care to chime in to what order things need to happen?
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
John Peacock wrote:
Applying the patch and running any/all of:
aclocal automake autoconf configure
Oops. Applying to a clean tree and running (in this order):
autoconf
automakeseems to have done it. Testing reports will follow...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Preliminary tests using [1]:
A) Login correctly using same login settings as IMAP (including TLS);
B) CAPABILITIES displays "FILEINTO VACATION" [2];
C) Edit script with user defined name;
D) Mark script as ACTIVE creates link in maildir;
As pointed out in the original report, to be complete, the managesieve daemon *must* validate the script (see the draft RFC section 2.6).
I'm going to stop working on my proof-of-concept managesieve daemon, since this is so much farther along...
I'm going to set up one of the web-based clients (either websieve or Smartsieve) and see what else I can test (the Mozilla plugin is not very stable).
John
According to what I've found listed here:
http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
the libsieve supports more capabilities than that: SUBADDRESS IMAPFLAGS FILEINTO REGEX NOTIFY ENVELOPE VACATION
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
John Peacock schreef:
Preliminary tests using [1]:
- http://sieve.mozdev.org/index.html Nice, I'll do some tests with this one as well.
B) CAPABILITIES displays "FILEINTO VACATION" [2];
- According to what I've found listed here:
http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix
the libsieve supports more capabilities than that: SUBADDRESS IMAPFLAGS FILEINTO REGEX NOTIFY ENVELOPE VACATION
I know, the reported sieve capabilities are currently very much hardcoded. I didn't look at the CMU sieve library just yet, so I simply hardcoded the response given in the draft RFC. Maybe the CMU library even includes some capability macro (or whatever) I can use.
Btw, linking the managesieve daemon to the sieve library shouldn't be too hard. It only needs to compile/verify the source and no execution is needed. That should only require just a few lines of code and dovecot-lda can serve as an extensive example. I'll give it a look later this week.
Regards,
-- Stephan Bosch stephan@rename-it.nl
Stephan Bosch wrote:
Nice, I'll do some tests with this one as well.
Don't bother. It only succeeded in logging in once and then froze solid every other time; don't know why. Smartsieve works, though:
http://smartsieve.sourceforge.net/but you have to change lib/sieve.lib (which stupidly hardcodes for timsieved). Once you tweak that file, it works fine (though I'm still not happy with the ability to create rules using a web-GUI, but you cannot edit them except as a script).
I tested websieve, being more inclined to work in Perl than PHP, but it hasn't been updated is several years and appears to be broken. One thing that testing showed was that the string length (e.g. {13+}) is part of the API that the draft RFC doesn't cover fully. In particular, websieve wanted to send the string length as part of the AUTHENTICATE stanza (which your code didn't like). You should probably just expect a string length for any command and just discard it when you don't care.
I know, the reported sieve capabilities are currently very much hardcoded. I didn't look at the CMU sieve library just yet, so I simply hardcoded the response given in the draft RFC. Maybe the CMU library even includes some capability macro (or whatever) I can use.
See these pages:
http://libsieve.sourceforge.net/functions.php
http://libsieve.sourceforge.net/structures.php
http://libsieve.sourceforge.net/example.phpspecifically sieve2_validate() is all you should need to call in PUTSCRIPT. Looking at the actual header files, it appears that sieve2_listextensions() will show you which extensions are supported (but you have to provide a callback for each one you wish to support). Those pages don't have the most recent API listed.
HTH
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
but you have to change lib/sieve.lib (which stupidly hardcodes for timsieved).
Hahaha omg why would anyone think of implementing a (draft standard)
John Peacock schreef: protocol and require just a specific implementation! If he needs the IMPLEMENTATION capability string something is either wrong with the protocol or wrong with his implementation :)
One thing that testing showed was that the string length (e.g. {13+}) is part of the API that the draft RFC doesn't cover fully. In particular, websieve wanted to send the string length as part of the AUTHENTICATE stanza (which your code didn't like). You should probably just expect a string length for any command and just discard it when you don't care.
Actually, like the imap daemon, managesieve should accept quoted strings as well as string literals (with size spec) as string tokens anywhere in the managesieve grammar. I implemented this accordingly, but of course I cannot rule out any bugs in this implementation. I tested this for authenticate and this worked (altered the base64 for security reasons):
"IMPLEMENTATION" "dovecot" "SASL" "PLAIN" "SIEVE" "FILEINTO VACATION" OK "Dovecot ready." authenticate {5+} plain {16+} AHSlc3RAXnJvcA== OK "Logged in."
However, I found a very stupid bug, which might be the cause of your problem: if you login with "plain" (for instance) without an initial response, you get an empty response back, but the linefeed is missing. This is obviously a protocol error. Initially this bug was not present, but it has been introduced when I added managesieve string quoting to the string output functions.
While checking out smartsieve I noticed forgot to implement the SASL response code. Some implementations (noteably smartsieve) might moan about this with the more complex sasl mechanisms.
I also noticed that somewhere in the code I forgot a t_pop() call; the log moans about it sometimes when I log out. Still can't find it.
Regards,
-- Stephan Bosch stephan@rename-it.nl
participants (3)
-
John Peacock
-
Stephan Bosch
-
Timo Sirainen