dovecot - Jan 2009 - docecot managesieve global filter, service name

I do have two questions related to the managesieve setup in dovecot

1) I did setup a global sieve filter, that is invoked if a user has no 
other sieve filter. If a user installs a sieve filter and activates it
(PUTSCRIPT, SETACTIVE) then the sieve filter gets compiled (.sievec) and 
deliver does use it.

If I want to deactivate the filter (SETACTIVE "") only the symlink (to
the
.sieve script) is removed, the .sievec file remains intact. On the other 
hand the dovecot documentation reads (http://wiki.dovecot.org/LDA/Sieve):

To stop using sieve, both the .sieve source file and the compiled .sievec 
file must be deleted

How can I let a user switch between the globally installed sieve filter 
and an own filter. Activation seems to be ok, but deactivation would not
result in the switch back to the global filter if I believe the docs.

2) To use the SASL authentication with managesieve the name of the 
service has to be given. In the managesieve RFC 
http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09 
I can read (page13): The service name specified by this protocol's profile 
of SASL is  "sieve".

On the other hand I can find in managesieve-0.10.4 in 
client-authenticate.c

#define MANAGESIEVE_SERVICE_NAME "managesieve"

The name is important for the Kerberos5 auth I am doing, as I have to 
provide a service key for managesieve.hostname at REALM instead of 
sieve.hostname at REALM. Currently I have adapted my auth to the 
"managesieve" service name but maybe that should be changed.

My Installation: dovecot 1.1.8 patched for dovecot-1.1-managesieve-0.10.4
Authentication using SASL (GSSAPI), contained in the perl Module
Net::ManageSieve on CPAN.
-- 
Wolfgang Friebel                   Deutsches Elektronen-Synchrotron DESY
Phone/Fax:  +49 33762 77372/216    Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de  D-15738 Zeuthen  Germany

Wolfgang.Friebel at desy.de wrote:
> I do have two questions related to the managesieve setup in dovecot
> 
> 1) I did setup a global sieve filter, that is invoked if a user has no 
> other sieve filter. If a user installs a sieve filter and activates it
> (PUTSCRIPT, SETACTIVE) then the sieve filter gets compiled (.sievec) and 
> deliver does use it.
> 
> If I want to deactivate the filter (SETACTIVE "") only the
symlink (to
> the .sieve script) is removed, the .sievec file remains intact. On the 
> other hand the dovecot documentation reads 
> (http://wiki.dovecot.org/LDA/Sieve):
> 
> To stop using sieve, both the .sieve source file and the compiled 
> .sievec file must be deleted
> 
> How can I let a user switch between the globally installed sieve filter 
> and an own filter. Activation seems to be ok, but deactivation would not
> result in the switch back to the global filter if I believe the docs.
The old and the new Sieve plugin (should) both require the original 
script to be present. The binary is ignored otherwise. I don't know why 
this is listed on the wiki. I suggest you test this first and remove 
this from the wiki. Otherwise, it would be a bug anyway. I did check the 
sources and, by the looks of it, this should work correctly.
> 2) To use the SASL authentication with managesieve the name of the 
> service has to be given. In the managesieve RFC 
> http://tools.ietf.org/html/draft-ietf-sieve-managesieve-09 I can read 
> (page13): The service name specified by this protocol's profile of SASL
> is  "sieve".
Ohw, good point.
> On the other hand I can find in managesieve-0.10.4 in client-authenticate.c
> 
> #define MANAGESIEVE_SERVICE_NAME "managesieve"
> 
> The name is important for the Kerberos5 auth I am doing, as I have to 
> provide a service key for managesieve.hostname at REALM instead of 
> sieve.hostname at REALM. Currently I have adapted my auth to the 
> "managesieve" service name but maybe that should be changed.
> 
> My Installation: dovecot 1.1.8 patched for dovecot-1.1-managesieve-0.10.4
> Authentication using SASL (GSSAPI), contained in the perl Module
> Net::ManageSieve on CPAN.
Yes, it needs to be changed. I am wondering though whether it is a good 
idea to adjust this for v1.1.8.

Regards,

Stephan Bosch.