[Dovecot] Global Recipe Location
jbutler at thebestdefense.com
Mon Apr 6 21:25:57 EEST 2009
Thank you for your response, Mr. Bosch.
> James Butler schreef:
>> Hmmm. I'm having difficulty finding a good place for a global Sieve
> First of all, you should start a new thread (i.e. don't reply on an
> existing message) if you have a completely new question. Otherwise, some
> people may miss it and you'll mess the threads up in general.
I apologize. I thought I had created a new thread. I will be more careful
in the future.
>> The problem seems to be related to saving the compiled version
>> (xxx.svbin.tmp) in the same location as the script (xxx.sieve), which
>> happens using the credentials of the recipient user.
> The .svbin.tmp is a temporary version of the binary that is produced
> (and removed) when the script is recompiled. So, the actual name for the
> Sieve binary is global.svbin.
>> drwxr-xr-x dovecoter dovecoter /scripts
>> -rw-r--r-- dovecoter dovecoter /scripts/global.sieve
>> -rw------- recipient USERGROUP /scripts/global.svbin.tmp
>> Where should I be storing a global script that will process all incoming
>> mail, and is not user-specific? Also, I would love some suggestions
>> regarding how the permissions should be set, or anything that would make
>> this work as expected.
> The main problem is that the recipient users will not be able to write
> in the global directory, or they are not able to replace an existing
> binary with a recompiled version. This makes it impossible for deliver
> to store compiled global script binaries (it will work though). To
> prevent this, you must manually pre-compile your global scripts using
> the sievec tool each time you change them. Read the man page for more
If this is the method for utilizing a global script, I am still unable to
I have manually pre-compiled the global.sieve script into global.svbin in
the same location, however I still get the error (shown below), plus there
is now another error, since a normal user does not have permission to even
access the binary, which is owned by the Dovecot user.
Here are the errors:
(Running as recipient user1, try to open the pre-compiled script, which is
owned by the Dovecot user:)
dovecot: deliver(user1): sieve: binary open(/dovecot/global.svbin) failed:
(No permissions, so it tries to create its own .tmp file:)
dovecot: deliver(user1): sieve: rename(/dovecot/global.svbin.tmp,
/dovecot/global.svbin) failed for binary save: Permission denied
For the record, here's my global script stuff:
drwxr-xr-x dovecotuser:dovecotgroup /scripts
-rw-r--r-- dovecotuser:dovecotgroup /scripts/global.sieve
-rw------- dovecotuser:dovecotgroup /scripts/global.svbin
And here's what is being attempted with regard to error #2, above:
-rw------- user1:user1group /scripts/global.svbin.tmp
Note that this .tmp file remains in the directory along with the other
files, and it is not removed.
Mr. Bosch, I am curious about your statement:
"This makes it impossible for deliver to store compiled global script
binaries (it will work though)."
I'm not sure what is 'impossible' and what 'will work though'. I can
definitely *store* a compiled global script binary ... it just seems to be
tricky to *use* it. ;) I appreciate any clarity you can give.
More information about the dovecot