[Dovecot] Global Recipe Location

[James Butler]

Thank you for your response, Mr. Bosch.

> James Butler schreef:
>> Hmmm. I'm having difficulty finding a good place for a global Sieve
>> script.
> 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.

Thank you.

>> i.e.
>>
>> 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
> info.

If this is the method for utilizing a global script, I am still unable to
implement it.

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:
Permission denied

(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.

James