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 at 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 at blackrosetech.com): sieve:
msgid=<9e56b4975f015949469c6e5400c32bfb.6925371.5157717 at
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 at 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:
1) 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.
2) 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 at smail.inf.fh-brs.de>
To: David Gessel <gessel at 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 at blackrosetech.com): sieve:
msgid=<CAFOe2y4kDushW=u6_cN1JmsP1FF63BzJ5O8=VjquHNaNAnskFw at
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 at 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
>