dovecot - Dec 2010 - trying to make cmusieve happen globally

In Dovecot 1.1.11 cmusieve is apparently integrated in the Ubuntu 9.10
package "dovecot-common" since the files are there.  I am wanting to
right now just do a very basic test of the setup to see how it runs
before doing more sophisticated steps that could obscure any errors or
bugs (e.g. unit testing).

So I took the following example sieve script from the wiki1 documentation:

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
  fileinto "spam";
}

and recoded it to skip the test and just always do the fileinto step like so:

require "fileinto";
fileinto "spamtest";

Then I configured my dovecot.conf file (via dovecot-postfix.conf it
really points to) by setting:

protocol lda {
        ...
        mail_plugins = cmusieve
        mail_plugin_dir = /usr/lib/dovecot/modules/lda
        ...
}

and:

plugin {
        sieve_global_path = /etc/dovecot/sieve-global.d/spam.sieve
}

I manually compiled /etc/dovecot/sieve-global.d/spam.sieve so there
also exists /etc/dovecot/sieve-global.d/spam.sievec in the same
directory.  Then I restarted both Dovecot and Postfix.

Mail is being delivered, but still only to the same place it always
has.  The filesystem shows these sieve files are not being accessed at
all.  I've read documents http://wiki1.dovecot.org/LDA/Sieve and
http://wiki1.dovecot.org/LDA/Sieve/CMU to come up with this.  But it
just doesn't seem to be happening.  So I guess it is a good thing I've
broken my testing down into smaller units.  Anything standout that I
misinterpreted about the documentation?  If not, I can post the whole
config files (in case there is a conflict with something else I have
done).

FYI, I'm only trying to do a global sieve, not per-user sieve scripts.
 I'll tackle per-user stuff at a later date, after the global is
working.

-- 
sHiFt HaPpEnS!

Am 22.12.2010 um 16:45 schrieb Phil Howard:
> protocol lda {
>        ...
>        mail_plugins = cmusieve
>        mail_plugin_dir = /usr/lib/dovecot/modules/lda
>        ?
> }
Did you apply magic to the Postfix 'master.cf' as well? Just a hunch
because it is not mentioned in your post? For Sieve to work the Dovecot LDA
needs to be called by Postfix.

Hi,


> plugin {
>          sieve_global_path = /etc/dovecot/sieve-global.d/spam.sieve
Use "sieve_before", which is not documented in the wiki.

Only this way the sievescript really gets executed.


The global path requires a sieve script per home directory, including 
the global file.




best regards,

Anton

Op 22-12-2010 17:46, Anton Dollmaier schreef:
> Hi,
>
>
>
>> plugin {
>>          sieve_global_path = /etc/dovecot/sieve-global.d/spam.sieve
>
> Use "sieve_before", which is not documented in the wiki.
Eh.. no. CMUSieve does not have multiscript support, so sieve_before is 
not available.
> Only this way the sievescript really gets executed.
The global default is not executed when the user has a script of his 
own, otherwise it is executed.
> The global path requires a sieve script per home directory, including 
> the global file.
You are confusing the sieve_global_dir and sieve_global_path settings. 
The first is used by include, the latter specifies the default script 
executed when the user has none. Maybe these settings should be named 
differently, probably naming the latter sieve_default.


Regards,

Stephan

On Wed, Dec 22, 2010 at 13:12, Stephan Bosch <stephan at rename-it.nl>
wrote:
> Op 22-12-2010 17:46, Anton Dollmaier schreef:
>>> plugin {
>>> ? ? ? ? sieve_global_path = /etc/dovecot/sieve-global.d/spam.sieve
>>
>> Use "sieve_before", which is not documented in the wiki.
>
> Eh.. no. CMUSieve does not have multiscript support, so sieve_before is not
> available.
>
>> Only this way the sievescript really gets executed.
>
> The global default is not executed when the user has a script of his own,
> otherwise it is executed.
That sounds like a reasonable way to do it.

>> The global path requires a sieve script per home directory, including
the
>> global file.
>
> You are confusing the sieve_global_dir and sieve_global_path settings. The
> first is used by include, the latter specifies the default script executed
> when the user has none. Maybe these settings should be named differently,
> probably naming the latter sieve_default.
Yeah, since it behaves as a default, that name would have made sense.
That, or a sequence of path names that may or may not have %u to test
for an available script, and stop at the first one found.

sieve_global_path should have the file name?  Should it be the source
or the compiled sieve?  Does it need chmod +x ?

-- 
sHiFt HaPpEnS!