[Dovecot] MANAGESIEVE patch v3 for dovecot 1.0.rc28
Hello dovecot users,
I have updated the MANAGESIEVE patch to apply and compile against dovecot 1.0.rc28. Not much has changed with respect to the functionality of the previous version however:
ChangeLog vs v2
- Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package)
- Daemon now uses the same location for .dovecot.sieve as dovecot-lda This is typically ~/.dovecot.sieve.
- If .dovecot.sieve is a regular file, it is now moved into the script storage as dovecot.orig.sieve, preventing deletion of (important) active scripts upon managesieve installation. Otherwise, it would simply be replaced by a symlink to the new active script.
- Changed error handling to yield a BYE message when the managesieve daemon exits unexpectedly (upon login) before any commands are entered. Horde-ingo would wait indefinitely for a response.
This patch still includes (yet another) instance of the CMU Sieve source, as explained in my previous mail (http://dovecot.org/list/dovecot/2006-July/015016.html).
It can be downloaded at:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v3.diff.gz
Have fun testing the patch. Notify me when there are problems.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
Hi Stephan,
Stephan Bosch wrote:
I have updated the MANAGESIEVE patch to apply and compile against dovecot 1.0.rc28. Not much has changed with respect to the functionality of the previous version however:
(...)
How can you implement this in an actual reverse-proxied environment ? like having a dovecot or perdition as front imap servers on the DMZ and then real boxes inside... how can I proxy the managesieve daemon the same way ? ('cause it really rocks)
Op ma, 26-03-2007 te 18:34 +0200, schreef Stephan Bosch:
- Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package)
I downloaded the rc28 Debian source package, ran dpkg-source -x dovecot-1.0.rc28-1.dsc, applied the patch and ran dpkg-buildpackage -uc -us -rfakeroot, which resulted in the error: [...] config.status: creating src/lib-ntlm/Makefile config.status: creating src/lib-settings/Makefile config.status: error: cannot find input file: src/lib-sievestorage/Makefile.in make: *** [config.status] Error 1
Should I run some script to configure managesieve first?
Thanks!
Koen
On Mon, 2007-03-26 at 20:02 +0200, Koen Vermeer wrote:
Op ma, 26-03-2007 te 18:34 +0200, schreef Stephan Bosch:
- Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package)
I downloaded the rc28 Debian source package, ran dpkg-source -x dovecot-1.0.rc28-1.dsc, applied the patch and ran dpkg-buildpackage -uc -us -rfakeroot, which resulted in the error: [...] config.status: creating src/lib-ntlm/Makefile config.status: creating src/lib-settings/Makefile config.status: error: cannot find input file: src/lib-sievestorage/Makefile.in make: *** [config.status] Error 1
Should I run some script to configure managesieve first?
./autogen.sh (re)creates the Makefile.in files. You might also need some extra packages for that to work. See compiling from CVS in http://wiki.dovecot.org/CompilingSource
Op ma, 26-03-2007 te 22:04 +0300, schreef Timo Sirainen:
./autogen.sh (re)creates the Makefile.in files. You might also need some extra packages for that to work. See compiling from CVS in http://wiki.dovecot.org/CompilingSource
OK, I tried it again. I applied the patch, ran chmod 744 autogen.sh, ran autogen.sh, and then tried dpkg-buildsource -uc -us -rfakeroot. I got
dpkg-buildpackage: source package is dovecot
dpkg-buildpackage: source version is 1.0.rc28-1
dpkg-buildpackage: source changed by Fabio Tranchitella
kobold@debian.org
dpkg-buildpackage: host architecture powerpc
dpkg-buildpackage: source version without epoch 1.0.rc28-1
fakeroot debian/rules clean
dpatch deapply-all
quota_v2 not applied to ./ .
quota_mountpoint not applied to ./ .
postgres_configure not applied to ./ .
dovecot-sql not applied to ./ .
dovecot-example not applied to ./ .
rm -rf patch-stamp patch-stampT debian/patched
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory /home/koen/dcot/dovecot-1.0.rc28' make[1]: *** No rule to make target distclean'. Stop.
make[1]: Leaving directory /home/koen/dcot/dovecot-1.0.rc28' make: [clean] Error 2 (ignored) /usr/bin/make -C dovecot-sieve distclean make[1]: Entering directory /home/koen/dcot/dovecot-1.0.rc28/dovecot-sieve'
make[1]: *** No rule to make target distclean'. Stop. make[1]: Leaving directory /home/koen/dcot/dovecot-1.0.rc28/dovecot-sieve'
make: [clean] Error 2 (ignored)
rm -f conftest conftest.o config.log config.cache config.status ylwrap
[ -f config.sub.orig ] && mv config.sub.orig config.sub || true
[ -f config.guess.orig ] && mv config.sub.orig config.guess || true
dh_clean
dpkg-source -b dovecot-1.0.rc28
dpkg-source: building dovecot using existing
dovecot_1.0.rc28.orig.tar.gz
dpkg-source: building dovecot in dovecot_1.0.rc28-1.diff.gz
dpkg-source: warning: executable mode 0744 of dovecot-sieve/autogen.sh' will not be represented in diff dpkg-source: warning: executable mode 0755 of dovecot-sieve/configure'
will not be represented in diff
dpkg-source: cannot represent change to dovecot-sieve/COPYING:
dpkg-source: new version is symlink
dpkg-source: old version is nonexistent
dpkg-source: warning: executable mode 0755 of
debian/patches/quota_v2.dpatch' will not be represented in diff dpkg-source: warning: executable mode 0755 of debian/patches/dovecot-sql.dpatch' will not be represented in diff
dpkg-source: warning: executable mode 0755 of
debian/patches/dovecot-example.dpatch' will not be represented in diff dpkg-source: warning: executable mode 0755 of debian/patches/quota_mountpoint.dpatch' will not be represented in diff
dpkg-source: warning: executable mode 0755 of
`debian/patches/postgres_configure.dpatch' will not be represented in
diff
dpkg-source: cannot represent change to config.sub:
dpkg-source: new version is symlink
dpkg-source: old version is something else
dpkg-source: cannot represent change to config.guess:
dpkg-source: new version is symlink
dpkg-source: old version is something else
dpkg-source: cannot represent change to ltmain.sh:
dpkg-source: new version is symlink
dpkg-source: old version is something else
dpkg-source: building dovecot in dovecot_1.0.rc28-1.dsc
dpkg-source: unrepresentable changes to source
I can't really find an error message, but the packages weren't build. I tried it three times, but to no avail. I feel pretty stupid...
Koen
On Monday 26 March 2007 21:43, Koen Vermeer wrote:
Op ma, 26-03-2007 te 22:04 +0300, schreef Timo Sirainen:
./autogen.sh (re)creates the Makefile.in files. You might also need some extra packages for that to work. See compiling from CVS in http://wiki.dovecot.org/CompilingSource
OK, I tried it again. I applied the patch, ran chmod 744 autogen.sh, ran autogen.sh, and then tried dpkg-buildsource -uc -us -rfakeroot. I got
dpkg-source: cannot represent change to config.sub: dpkg-source: new version is symlink dpkg-source: old version is something else dpkg-source: cannot represent change to config.guess: dpkg-source: new version is symlink dpkg-source: old version is something else dpkg-source: cannot represent change to ltmain.sh: dpkg-source: new version is symlink dpkg-source: old version is something else dpkg-source: building dovecot in dovecot_1.0.rc28-1.dsc dpkg-source: unrepresentable changes to source
I can't really find an error message, but the packages weren't build. I tried it three times, but to no avail. I feel pretty stupid...
dpkg-buildpackage fails to build the source package because it can't represent symlinks in a diff file. But you don't need to build the source package. Just run fakeroot debian/rules binary. dpkg-buildpackage -b should work too.
-- Magnus Holmgren holmgren@lysator.liu.se (No Cc of list mail needed, thanks)
Koen Vermeer wrote:
Op ma, 26-03-2007 te 18:34 +0200, schreef Stephan Bosch:
- Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package)
I downloaded the rc28 Debian source package, ran dpkg-source -x dovecot-1.0.rc28-1.dsc, applied the patch and ran dpkg-buildpackage -uc -us -rfakeroot, which resulted in the error:
You should probably give up trying to use the debian package method if you are applying third-party patches like this. In particular, you will need to run autogen.sh, which isn't in the source tarballs, but is only available with you check out the CVS files (you will also need to have ylwrap, which can be found in the top level of the dovecot-sieve distro).
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
Op ma, 26-03-2007 te 15:12 -0400, schreef John Peacock:
You should probably give up trying to use the debian package method if you are applying third-party patches like this. In particular, you will need to run autogen.sh, which isn't in the source tarballs, but is only available with you check out the CVS files (you will also need to have ylwrap, which can be found in the top level of the dovecot-sieve distro).
Ah... It worked so beautifully with rc27, that I thought I'd just give it a try. Besides, Stephan mentioned he tested it with the rc27 Debian package.
Koen
On Mon, 2007-03-26 at 18:34 +0200, Stephan Bosch wrote:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v3.diff.gz
I finally took a look at this. The biggest problem is that there's way too much duplicated code.
lib-managesieve: Is the only thing different from lib-imap that it does UTF8 validation? Then rather add some utf8-flag to the imap-parser. Or maybe add some string validation callback which does it in lib-managesieve.
managesieve: I guess the commands-common.c could be put somewhere.. Hmm. Also client.c has a lot of copy&pasted code. I'm not sure what's the right place for these though.
login: There is still too much duplication in the login code (also for imap/pop3). I'm thinking about cleaning this up after v1.0. Wonder if there should exist just one login binary which can handle multiple protocols (and support plugins)..
Sieve plugin would need to be merged somehow to this to avoid adding lib-sieve/cmu.
There's also one bug:
/* FIXME: Is this buffer on the stack method allowable for
* dovecot at all or do we need to define some t_buffer?
*/
static const int bufsize = 255;
char linkbuf[bufsize];
ret = readlink(storage->active_path, linkbuf, bufsize-1);
linkbuf[ret] = '\0'; //// ret can be -1.. return t_strdup(linkbuf);
Change rather to something like:
char linkbuf[PATH_MAX];
ret = readlink(storage->active_path, linkbuf, sizeof(linkbuf));.. return t_strndup(linkbuf, ret);
Hello Timo,
Thanks for reviewing the managesieve patch.
Timo Sirainen schreef:
On Mon, 2007-03-26 at 18:34 +0200, Stephan Bosch wrote:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v3.diff.gz
I finally took a look at this. The biggest problem is that there's way too much duplicated code. I agree. This would make updating the various protocol implementations tedious and error prone (to say the least). My initial goal was to write a working non-intrusive managesieve patch for dovecot, to be fully merged with dovecot later.
- lib-managesieve: Is the only thing different from lib-imap that it does UTF8 validation? Then rather add some utf8-flag to the imap-parser. Or maybe add some string validation callback which does it in lib-managesieve. It has been 6 months since I adapted this code for managesieve. I'll do a quick review and check whether these two libraries can be merged easily, but I believe they can.
managesieve: I guess the commands-common.c could be put somewhere.. Hmm. Also client.c has a lot of copy&pasted code. I'm not sure what's the right place for these though.
login: There is still too much duplication in the login code (also for imap/pop3). I'm thinking about cleaning this up after v1.0. Wonder if there should exist just one login binary which can handle multiple protocols (and support plugins).. That's a nice idea.
- Sieve plugin would need to be merged somehow to this to avoid adding lib-sieve/cmu.
I coined this in my previous e-mail: if the master process could provide some means of dynamically registering new process types (protocols), e.g. through plugins, it should not be difficult to incorporate this managesieve implementation in dovecot-sieve entirely. Also, this plugin solution could be implemented/complemented by your single-login-process idea.
Within the dovecot-sieve plugin package, a common sieve library would then solve the lib-sieve/cmu duplication problem.
There's also one bug:
/* FIXME: Is this buffer on the stack method allowable for
- dovecot at all or do we need to define some t_buffer? */ static const int bufsize = 255; char linkbuf[bufsize];
ret = readlink(storage->active_path, linkbuf, bufsize-1); linkbuf[ret] = '\0'; //// ret can be -1 .. return t_strdup(linkbuf);
Change rather to something like:
char linkbuf[PATH_MAX]; ret = readlink(storage->active_path, linkbuf, sizeof(linkbuf)); .. return t_strndup(linkbuf, ret);
Nice one, also with respect to the buffer size. Apart from this real bug, there are currently still many more FIXMEs out there.
I'll fix the issues that I can fix right now. Most duplicate code problems will have to wait until you have the time to juggle around a bit with the dovecot(-sieve) code. Please notify my when you have changed anything with this respect.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
On 26.3.2007, at 22.59, Stephan Bosch wrote:
I coined this in my previous e-mail: if the master process could
provide some means of dynamically registering new process types
(protocols), e.g. through plugins, it should not be difficult to
incorporate this managesieve implementation in dovecot-sieve
entirely. Also, this plugin solution could be implemented/ complemented by your single-login-process idea.
Yea. Although I think this will have to wait for Dovecot v2.0 which
has my rewritten master/config code. There the master process really
doesn't know anything about different protocols, they're all
configured in a config file.
The settings are also distributed in the code where they're used,
instead of everything being in one place. However currently there
still exists a generated all-settings.c so that the config file
parser knows what settings are valid. I haven't really figured out
yet how this could be made to work with external programs.. I don't
really like the idea of having a "settings configuration file" :)
With plugins it could dynamically load them and get the settings
structures directly, but I'm not sure about binaries. Perhaps each
binary could have a "--dump-settings" option.
BTW. I'm also planning on adding a new protocol to Dovecot some day
in an external package: http://icecap.irssi2.org/
On 3/26/2007 Timo Sirainen (tss@iki.fi) wrote:
BTW. I'm also planning on adding a new protocol to Dovecot some day in an external package: http://icecap.irssi2.org/
So... ?
Dovecot will act as an IRC chat server?
?
--
Best regards,
Charles
On 22:49:36 2007-03-26 Charles Marcus CMarcus@Media-Brokers.com wrote:
On 3/26/2007 Timo Sirainen (tss@iki.fi) wrote:
BTW. I'm also planning on adding a new protocol to Dovecot some day in an external package: http://icecap.irssi2.org/
So... ?
Dovecot will act as an IRC chat server?
?
Sounds like an overly glorified irc bouncer and bitlbee in one... Though competition against all the existing bouncers though...
On Mon, 2007-03-26 at 16:49 -0400, Charles Marcus wrote:
On 3/26/2007 Timo Sirainen (tss@iki.fi) wrote:
BTW. I'm also planning on adding a new protocol to Dovecot some day in an external package: http://icecap.irssi2.org/
So... ?
Dovecot will act as an IRC chat server?
By "external package" I meant that Dovecot's standard distribution would have absolutely no knowledge of it. It could just be configured to use the separately distributed icecapd to run if wanted.
It already runs standalone or executed via SSH. So Dovecot would just provide it easy way to support TCP connections, TLS and authentication. I'm not all that interested in using those myself though, SSH is better. :)
And as for the discussion about how useful the whole Icecap thing is, we'll see. It's already 1,5 years old and it hasn't had much development since the first few months. I still don't much like screen+irssi combination for IRCing though (and other clients/bouncers even less), and I have some nice ideas for an IRC client that are pretty easy to implement with Icecap (and if something is not, it's still easy to change the protocol).
Timo Sirainen schreef:
On 26.3.2007, at 22.59, Stephan Bosch wrote:
I coined this in my previous e-mail: if the master process could provide some means of dynamically registering new process types (protocols), e.g. through plugins, it should not be difficult to incorporate this managesieve implementation in dovecot-sieve entirely. Also, this plugin solution could be implemented/complemented by your single-login-process idea.
Yea. Although I think this will have to wait for Dovecot v2.0 which has my rewritten master/config code. There the master process really doesn't know anything about different protocols, they're all configured in a config file. Nice. Is v2.0 available already trough CVS somewhere? Btw, if this is going to wait until v2.0, do you have any other ideas on how to merge managesieve and dovecot-sieve? Or do you want to wait with that until v2.0 as well?
The settings are also distributed in the code where they're used, instead of everything being in one place. However currently there still exists a generated all-settings.c so that the config file parser knows what settings are valid. I haven't really figured out yet how this could be made to work with external programs.. I don't really like the idea of having a "settings configuration file" :) With plugins it could dynamically load them and get the settings structures directly, but I'm not sure about binaries. Perhaps each binary could have a "--dump-settings" option. You could also provide some common settings access library. This library is then used to access the configuration by all possible binaries. This can be considered ugly in many ways, however. For instance, the config file is read many times or per-protocol config files are used. I'm not very familiar to common solutions to this problem, but I do know that it is a very interesting one. :)
BTW. I'm also planning on adding a new protocol to Dovecot some day in an external package: http://icecap.irssi2.org/ Ok, nice protocol, but how does this relate to mail processing? :) Admittedly, it is in essence quite similar to IMAP and dovecot would provide an ideal framework to implement it. Still seems strange to me however :)
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
On Mon, 2007-03-26 at 23:01 +0200, Stephan Bosch wrote:
Timo Sirainen schreef:
On 26.3.2007, at 22.59, Stephan Bosch wrote:
I coined this in my previous e-mail: if the master process could provide some means of dynamically registering new process types (protocols), e.g. through plugins, it should not be difficult to incorporate this managesieve implementation in dovecot-sieve entirely. Also, this plugin solution could be implemented/complemented by your single-login-process idea.
Yea. Although I think this will have to wait for Dovecot v2.0 which has my rewritten master/config code. There the master process really doesn't know anything about different protocols, they're all configured in a config file. Nice. Is v2.0 available already trough CVS somewhere?
Not currently. CVS branches are kind of annoying to deal with, so I just keep it updated by "cvs up"ing once in a while and fixing the conflicts. :) You can get it from http://dovecot.org/tmp/dovecot-2.0-prealpha.tar.gz though. Plugins won't compile yet and TODO.rewrite has a list of features still missing.
Btw, if this is going to wait until v2.0, do you have any other ideas on how to merge managesieve and dovecot-sieve? Or do you want to wait with that until v2.0 as well?
I don't currently really have any ideas.
BTW. v2.0 isn't probably that far away. v1.0 should be out in a few weeks. v1.1/v1.2 (not sure which one I want to call the second stable branch) shouldn't hopefully take too many months to stabilize from the current CVS HEAD. So I'm hoping v2.0 code is in CVS HEAD by the next summer or so. :)
On 085, 03 26, 2007 at 06:34:21PM +0200, Stephan Bosch wrote:
Hello dovecot users,
I don't see how anonymous logins are handled. You must handle anonymous logins according to managesieve draft (see below) or don't advertise ANONYMOUS SASL mechanism at all.
Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL-
ANON]. This indicates that the server supports ANONYMOUS sieve
script syntax verification. Only the CAPABILITY, PUTSCRIPT and
LOGOUT commands are available to the anonymous user. All other
commands MUST give NO responses. Furthermore the PUTSCRIPT command
SHOULD NOT store any data. In this mode a positive response to the
PUTSCRIPT command indicates that the given script does not have any
syntax errors.I have updated the MANAGESIEVE patch to apply and compile against dovecot 1.0.rc28. Not much has changed with respect to the functionality of the previous version however:
ChangeLog vs v2
- Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package)
- Daemon now uses the same location for .dovecot.sieve as dovecot-lda This is typically ~/.dovecot.sieve.
- If .dovecot.sieve is a regular file, it is now moved into the script storage as dovecot.orig.sieve, preventing deletion of (important) active scripts upon managesieve installation. Otherwise, it would simply be replaced by a symlink to the new active script.
- Changed error handling to yield a BYE message when the managesieve daemon exits unexpectedly (upon login) before any commands are entered. Horde-ingo would wait indefinitely for a response.
This patch still includes (yet another) instance of the CMU Sieve source, as explained in my previous mail (http://dovecot.org/list/dovecot/2006-July/015016.html).
It can be downloaded at:
http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v3.diff.gz
Have fun testing the patch. Notify me when there are problems.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Andrey Panin schreef:
On 085, 03 26, 2007 at 06:34:21PM +0200, Stephan Bosch wrote:
Hello dovecot users,
I don't see how anonymous logins are handled. You must handle anonymous logins according to managesieve draft (see below) or don't advertise ANONYMOUS SASL mechanism at all.
Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL- ANON]. This indicates that the server supports ANONYMOUS sieve script syntax verification. Only the CAPABILITY, PUTSCRIPT and LOGOUT commands are available to the anonymous user. All other commands MUST give NO responses. Furthermore the PUTSCRIPT command SHOULD NOT store any data. In this mode a positive response to the PUTSCRIPT command indicates that the given script does not have any syntax errors.
The managesieve daemon extracts the available authentication mechanisms from the dovecot authentication implementation. It does not display the ANONYMOUS mechanism by default. So, obviously you must have configured ANONYMOUS somewhere. I haven't tested the daemon's behavior with ANONYMOUS thusfar.
This is what my server currently reports:
"IMPLEMENTATION" "dovecot" "SASL" "PLAIN" "SIEVE" "FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC" "STARTTLS" OK "Dovecot ready."
If you could state the problem more explicitly, I can check what is wrong.
Regards,
-- Stephan Bosch stephan@rename-it.nl IRC: Freenode, #dovecot, S[r]us
Stephan Bosch schreef:
Andrey Panin schreef:
On 085, 03 26, 2007 at 06:34:21PM +0200, Stephan Bosch wrote:
Hello dovecot users,
I don't see how anonymous logins are handled. You must handle anonymous logins according to managesieve draft (see below) or don't advertise ANONYMOUS SASL mechanism at all.
Implementations MAY advertise the ANONYMOUS SASL mechanism [SASL- ANON]. This indicates that the server supports ANONYMOUS sieve script syntax verification. Only the CAPABILITY, PUTSCRIPT and LOGOUT commands are available to the anonymous user. All other commands MUST give NO responses. Furthermore the PUTSCRIPT command SHOULD NOT store any data. In this mode a positive response to the PUTSCRIPT command indicates that the given script does not have any syntax errors.The managesieve daemon extracts the available authentication mechanisms from the dovecot authentication implementation. It does not display the ANONYMOUS mechanism by default. So, obviously you must have configured ANONYMOUS somewhere. I haven't tested the daemon's behavior with ANONYMOUS thusfar.
This is what my server currently reports:
"IMPLEMENTATION" "dovecot" "SASL" "PLAIN" "SIEVE" "FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC" "STARTTLS" OK "Dovecot ready." Ah ok, after reading the SASL-ANONYMOUS RFC and playing around with anonymous authentication, I understand what you mean (found a bug in authenticate as well: continued responses don't work anymore at the moment until next patch version).
I'm currently looking for a means to detect whether the current user is logged-in anonymously, to fully support the draft spec.
Note: like the current IMAP implementation, the managesieve anonymous login gives full access to the anonymous client within the privileges of the user specified in the config file with 'auth_anonymous_username'. Given the draft spec and common sense this is NOT WHAT YOU WANT! Thanks Andrey for pointing this out.
Regards,
Stephan.
Stephan Bosch wrote:
Hello dovecot users,
I have updated the MANAGESIEVE patch to apply and compile against dovecot 1.0.rc28. Not much has changed with respect to the functionality of the previous version however:
One thing that would be very important is some way to pretend that this server implements the timsieved daemon. All software that I've tried is hardcoded to assume something like this regex:
"Cyrus timsieved (v1\.\d|v2\.\d)"Perhaps, instead of just plopping PACKAGE into that IMPLEMENTATION string, it would be better to add a configure option to set that string to something else than "dovecot" (which no software currently supports).
FWIW, I've just fired up smartsieve:
http://smartsieve.sourceforge.net/and it works like a charm for editing scripts.
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
On 22:57:20 2007-03-26 John Peacock jpeacock@rowman.com wrote:
Stephan Bosch wrote: http://smartsieve.sourceforge.net/
and it works like a charm for editing scripts.
Here's another that was acctually developed on this one(not my code but it's a friend of mine GPLv2)
https://mages.ath.cx:19191/sieve.tar.bz2
Then there's also a ruby managesieve library with a sievectl script that also works fine...
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
participants (10)
-
"Andraž 'ruskie' Levstik"
-
Andrey Panin
-
Charles Marcus
-
John Peacock
-
Koen Vermeer
-
Magnus Holmgren
-
Rene Luria
-
Stephan Bosch
-
Stephan Bosch
-
Timo Sirainen