Op 2/7/2017 om 5:04 AM schreef Richard Laager:

I'm getting lots of errors like this (possibly on every message delivery):

imap2 dovecot: lmtp(rlaager@wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ : sieve: binary save: failed to create temporary file: open(/var/lib/dovecot/sieve/junk-mail.svbin.ima p2.852.) failed: Permission denied (euid=500(vmail) egid=500(vmail) missing +w perm: /var/lib/dovecot/ sieve, dir owned by 0:0 mode=0755)

imap2 dovecot: lmtp(rlaager@wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/var/lib/dovecot/sieve/junk-mail.sieve' need to be pre-compiled using the sievec tool

It's intentional in my setup that the vmail user can't write to the global sieve script directory. But it shouldn't need to, as those are already pre-compiled:

rlaager@imap2:/var/lib/dovecot/sieve$ ls -la total 12 drwxr-xr-x 2 root root 4096 Nov 29 22:27 . drwxr-xr-x 3 root root 4096 Feb 6 20:39 .. lrwxrwxrwx 1 root root 53 Sep 12 01:35 junk-mail.sieve -> /usr/share/wiktel-server-mail-backend/junk-mail.sieve -rw-r--r-- 1 root root 254 Nov 29 22:27 junk-mail.svbin

rlaager@imap2:/var/lib/dovecot/sieve$ ls -la /usr/share/wiktel-server-mail-backend/junk-mail.sieve -rw-r--r-- 1 root root 124 Oct 31 09:34 /usr/share/wiktel-server-mail-backend/junk-mail.sieve

Note that the .svbin is from November, while the text version is from October. Even if something is looking at the date of the symlink, that's from September.

So the first question is... why is Dovecot trying to write the binary file?

Newer versions of Pigeonhole may use a different version of the compiled binary format. So, for some upgrades it may be necessary to recompile.

I dug into the Pigeonhole code... I think, but am certainly not sure, that lda_sieve_open() in pigeonhole/src/plugins/lda-sieve/lda-sieve-plugin.c is the relevant function calling lda_sieve_binary_save(). At the end of the function, it has:

    if (!recompile)
            lda_sieve_binary_save(srctx, sbin, script);

This seems odd to me. Why is it trying to save in the "!recompile" case? It seems like it should be saving in the "recompile" case. If I'm reading this code right, recompile is set when it loads a corrupt sieve binary script and needs to recompile from text.

That part of the code is only relevant for binaries that are seen to be corrupt at runtime, not when they are just perceived to be out-of-date. I'll be reviewing this code soon anyway, because there are some known problems with the up-to-date check itself (file time stamp race condition). I'll be reviewing this as well.

Anyway, for now you should be helped by just manually recompiling.

Regards,

Stephan.