Deleting the .svbin and recreating the .svbin script seems to have changed something, but didn't solve the whole problem (or not quite?). I still read the error messages incorrectly, but more on that below. I have a bit more data on the problem preventing sorting.
Sieve scripts are failing only for my auto-filing system for mailing lists which uses a sub-directory system, as in:
Lists/LowVol Lists/Dovecot etc.
(please note that this worked fine before the recent update to 0.4.6)
The scripts that fileinto a top level directory such as "Spam" work fine, the ones that fileinto a second level directory barf out. All of them give the errors as below, but I see now that messages that are supposed to go to the lists directory ALSO give this error (which was a bit obfuscated):
"sieve: Execution of script /mail/blackrosetech.com/gessel//.dovecot.sieve;name=base failed, but implicit keep was successful (user logfile /mail/blackrosetech.com/gessel//.dovecot.sieve.log may reveal additional details)"
which tells me that error: msgid=548991BC.3060002@uti.at: failed to store into mailbox 'Lists/Libtech': Invalid mailbox name: Name must not have '/' characters.
(apparently a new requirement, because the script was definitely working before the update: much mail properly sorted). Now to look up the new sub-directory delimiter: and "." works. SOLVED for realz this time.
I believe this is true: depending on the dovecot storage mode, if you were successfully sieving into sub-directories delimited by "/" and it stopped working recently, try "." as the delimiter, so instead of
fileinto "directory/subdirectory";
use
fileinto "directory.subdirectory";
But I still get the permission errors in my logs.
Dec 11 10:21:11 shiofuki dovecot: lda(gessel@blackrosetech.com): sieve: msgid=9e56b4975f015949469c6e5400c32bfb.6925371.5157717@ets099.teensywrite.us: stored mail into mailbox 'Junk'
Now I would argue that at this point both the first error and second error are factually wrong, though I could be misinterpreting things, and I suspect that some bug was introduced in the update I applied that is at the root of the problems as I haven't changed anything in my mail configuration: merely
Working fine -update using portmaster -Rafd Sieve is not working (with the errors above).
As for the reported errors, and I realize I may be completely reading this wrong, but I would parse the error messages as:
"Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.60095.)"
-> This seems to indicate that sieve tried to save the file /usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.60095 and an error condition resulted which is being reported as not being able to save the file.
"failed: Permission denied"
-> This seems to indicate that sieve believes there is a permissioning problem.
"(euid=5000(vmail) egid=5000(vmail)"
-> I interpret this as reporting the user that sieve thinks should have permission to write to the target directory, which is what I would expect it to be.
"missing +w perm: /usr/local/etc/dovecot/sieve"
-> I could be totally wrong here, but I read this as sieve believing that the "vmail" user does not have write permission in the directory "/usr/local/etc/dovecot/sieve" which is incorrect. I am not sure how this can be other than an sieve bug.
"we're not in group 6(mail)"
-> I'm reading "we're" as referring to user "vmail," which is also incorrect. "vmail" is in group 6(mail). I am not sure this can be other than a sieve bug.
"dir owned by 143:6 mode=0775"
-> This is correct: the directory /usr/local/etc/dovecot/sieve is owned by 143:6. But user "vmail" is in group 6.
Next, dovecot reports an error on behalf of sieve. This seems to be a continuation of the original error in that it also references what reads as the same "permission error" but comes to a different conclusion as to the cause of the error - that the global script needs to be compiled with sievec.
"dovecot: lda(gessel@blackrosetech.com): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool"
"The LDA Sieve plugin does not have permission to save global Sieve script binaries"
-> this is the reported error condition - a permissions problem which is probably coming from sieve, but is incorrect. Sieve does have permission to write to the folder.
"global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool"
-> I'm sure this is true, but since the underlying problem was not fixed by deleting the svbin file and recreating it with sievec, I think we can be confident that the prescription for the reported permission error will not fix the error.
Testing whether this is really a new and somewhat improperly reported permissioning problem, I changed the permissions of /usr/local/etc/dovecot/sieve/ to 777 and the errors went away.
I could be wrong, but I think this proves that:
The first warning from sieve about a permission error is correct but the proposed solution, that vmail should be in group 6 that owns the directory and does have write permission is wrong. Sieve is now (since the update?) trying to write to the directory as some user other than "vmail" since vmail definitely is in group 6, group 6 has write permissions, and changing folder permissions to 777 from 775 makes the error go away.
The second warning from dovecot about a permission error is also correct, but the proposed solution, that scripts need to be complied, is not actually relevant.
Now to try to figure out what user sieve is operating as...
... and I haven't a clue other than vmail.
Is it possible that the new upgrade changed the name of the user that is being tested against the permissions of the target folder and that is causing sieve to fail? Is it possible that the target folder for the temporary file that needs to be written has changed? Perhaps that this temporary directory is called on during a "fileinto" command? And perhaps that it isn't the global script that is the problem, but rather in user scripts? (or that it was both, but the global script was fixed by deleting it and recompiling it)?
While it is reasonable to presume that there's an easy fix, or that I'm doing something stupid (especially as it doesn't seem that anyone else is having problems), there was a big change in the storage code between 0.4.3 and 0.4.4 and minor changes between 0.4.4 and 0.4.6. I would have been running 0.4.3 before I updated based on the release dates to FreeBSD ports.
-David
-------- Original Message -------- Subject: Re: Sieve permissions issue following update [solved] From: Steffen Kaiser skdovecot@smail.inf.fh-brs.de To: David Gessel gessel@blackrosetech.com Date: Thu Dec 11 2014 13:01:23 GMT+0300 (Arabic Standard Time)
On Thu, 11 Dec 2014, David Gessel wrote:
and watching the logs: dovecot: lda(gessel@blackrosetech.com): sieve: msgid=CAFOe2y4kDushW=u6_cN1JmsP1FF63BzJ5O8=VjquHNaNAnskFw@mail.gmail.com: stored mail into mailbox 'INBOX'
Success!
:-)
The permissions correction portion of the error below still seems wrong though, isn't it? And if so, a little misleading.
Dec 9 00:09:59 mailhost dovecot: lda(gessel@domain.com): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
Well, the error is not wrong by itself. An user gets a new message, in order to run the user's Sieve script, the LDA must load the sieve_before script. This is out-of-sync currently, because of the upgrade, and hence must be re-compiled and its binary form storred there.
One could argue, if:
a) in case of failure the binary should be written somewhere else, e.g. a temporary location and re-compiled each time a message arrives, or into the user's home dir, or ... The current way tells the admin, that something is wrong.
Something is definitely wrong, that's true, but the reported error is misleading. It is very clear about what the problem is interpreted to be, which is just as clearly wrong.
b) sieve_before/after scripts chould be textually merged with user's scripts and storred as one combined binary in the user's directory. A change of a global script would impact all user scripts then, a message to everyone would require quite a bit CPU.
Does it seem reasonable to let the port maintainer know to submit a request to include instructions in /usr/ports/UPDATING for recompiling global scripts when necessary (and how to do it)? I checked before posting to the list and the last entry for sieve is this one:
You could file a bug report in your distro's bug tracking software. If these are standard locations - I mean, you did not changed the paths to point somewhere else -, the upgrade should recompile shared Sieve scripts.
-- Steffen Kaiser