It has been running flawlessly for quite some time until the update.

Global scripts were compiled:

/usr/local/etc/dovecot/sieve # ls 10-move-spam.sieve 10-move-spam.svbin

However, I ran sievec again and tried saving a modified script and got the same:

shiofuki dovecot: lda(gessel@blackrosetech.com): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) 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) Dec 9 11:30:39 shiofuki 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

I use Thomas Schmid's Sieve 0.2.3d add on to Thunderbird, if that might have any significance.

Compiling with sievec shouldn't change the permission error, which I still don't understand.

-------- Original Message -------- Subject: Re: Sieve permissions issue following update From: Pascal Volk user+dovecot@localhost.localdomain.org To: Dovecot Mailing List dovecot@dovecot.org Date: Tue Dec 09 2014 20:45:00 GMT+0300 (Arabic Standard Time)

On 12/09/2014 05:35 PM, David Gessel wrote:

...

I recently updated dovecot and my sieve filters stopped working. Checking the logs I see:

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)

Dec 9 00:09:59 mailhost dovecot: lda(gessel@domain.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

As mentioned in the error message from your logs and in the wiki http://wiki2.dovecot.org/Pigeonhole/Sieve/Usage#Manually_Compiling_Sieve_Scr...:

To mitigate this problem, the administrator must manually pre-compile global scripts using the sievec command line tool.

Regards, Pascal

-------- Original Message -------- Subject: Re: Sieve permissions issue following update From: Pascal Volk user+dovecot@localhost.localdomain.org To: Dovecot Mailing List dovecot@dovecot.org Date: Wed Dec 10 2014 00:00:04 GMT+0300 (Arabic Standard Time)

On 12/09/2014 07:50 PM, David Gessel wrote:

...

It has been running flawlessly for quite some time until the update.

Global scripts were compiled:

/usr/local/etc/dovecot/sieve # ls 10-move-spam.sieve 10-move-spam.svbin

However, I ran sievec again and tried saving a modified script and got the same:

shiofuki dovecot: lda(gessel@blackrosetech.com): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) 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) Dec 9 11:30:39 shiofuki 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

I use Thomas Schmid's Sieve 0.2.3d add on to Thunderbird, if that might have any significance.

Compiling with sievec shouldn't change the permission error, which I still don't understand.

...

[TOFU snipped}

/usr/local/etc/dovecot/sieve is not the user's sieve_dir; see http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration.

The GLOBAL sieve scripts (see your error message above) is manged by the system administrator. Adnmins are using their favorite $EDITOR, the chmod(1) and chown(1) commands. They don't need a ManageSieve client.

Pascal,

Thank you very much for your prompt assistance. I apologize that I haven't been able to use your advice to sort out the issues, but I'm either not getting it or it is tangential to the problem I'm having. I apologize if I haven't provided enough information.

90-sieve.conf's specification of those file locations for global and user scripts (relevant lines from the config below):

sieve = ~/.dovecot.sieve sieve_dir = ~/sieve #sieve_global_dir = sieve_before = /usr/local/etc/dovecot/sieve/

I brought up the plugin only because only two things have touched any part of the dovecot/sieve configuration between "working" and "not working" states:

• An update using portmaster to dovecot2-2.2.15_1/dovecot-pigeonhole-0.4.6 and
• an edit via the Sieve plugin/Managesieve.

One of the two has broken sieve. Unfortunately I did take note of the last working version of dovecot/dovecot-pigeonhole, but it could not be more than a few months old as I update ports fairly regularly and my last buildworld wasn't that long ago.

It is consistent with the errors and my understanding that user scripts are not the likely culprit: I included the information for the sake of completeness, which can now be dismissed. Moving back to the logged warnings:

Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) failed:

• this seems to me to indicate that sieve tried to write "10-move-spam.svbin.shiofuki.blackrosetech.com.96421" in the directory /usr/local/etc/dovecot/sieve/

Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve

• I read this as sieve determining that "vmail" is not permitted to write to /usr/local/etc/dovecot/sieve

we're not in group 6(mail), dir owned by 143:6 mode=0775)

• and giving a very helpful bit of advice that "we're" not in group 6(mail) - which I'm reading as "vmail" not being in group "mail" - and that the target directory is owned by 143:6 0775. The latter is consistent with the OS's reporting of the directory:

drwxrwxr-x 2 dovecot mail 4B Dec 9 11:27 sieve

from /etc/group mail:*:6:postfix,clamav,vscan,dovecot,vmail,spamd dovecot:*:143:

IF I'm reading "we're" as "vmail" correctly, this is incorrect ("we're not in group 6(mail)). vmail IS in group "mail" and group "mail" does have write permissions to /usr/local/etc/dovecot/sieve/ (group is rwx). Perhaps "we're" now refers to another user? I see from top (I realize this is unlikely):

96387 dovenull 1 20 0 29120K 6080K kqread 7 0:00 0.00% managesieve-login

As for the error

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 reported error is consistent with the previous - a newly minted permission problem that seems to have come with the update. In this case the advice given about precompiling global scripts seems misplaced. The script is compiled, as reported by the error immediately preceding (10-move-spam.svbin, the svbin suffix is added by the compilation process) and just to be sure I ran seivec again and #service dovecot restart without changing the error.

My inexpert intuition is that the latest update introduced a bug that is manifesting itself as a permission error.

-------- Original Message -------- Subject: Re: Sieve permissions issue following update From: Steffen Kaiser skdovecot@smail.inf.fh-brs.de To: David Gessel gessel@blackrosetech.com Date: Wed Dec 10 2014 09:52:57 GMT+0300 (Arabic Standard Time)

Actually this "ls" output and the last sentence does not indicate that the Sieve script had been compiled: a) after changing 10-move-spam.sieve _and_ b) after the upgrade with the new Sieve tools.

Good point.

Did _you_ _manually_ run:

cd /usr/local/etc/dovecot/sieve rm 10-move-spam.svbin

Ut oh... I did not rm the existing svbin.

sievec -D 10-move-spam.sieve

? And, is the sievec command displaying the Pigeonhole version you have installed?

And the -D directive is very useful, thanks:

# rm 10-move-spam.svbin # sievec -D 10-move-spam.sieve sievec(gessel): Debug: sieve: Pigeonhole version 0.4.6 (3e924b1b6c5c+) initializing sievec(gessel): Debug: sieve: include: sieve_global is not set; it is currently not possible to include :global' scripts. sievec(gessel): Debug: sieve: file storage: Using script storage path: 10-move-spam.sieve sievec(gessel): Debug: sieve: file script: Opened script 10-move-spam' from 10-move-spam.sieve' sievec(gessel): Debug: sieve: Script 10-move-spam' from 10-move-spam.sieve successfully compiled

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)

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:

20090828: AFFECTS: users of mail/dovecot and mail/dovecot-sieve AUTHOR: yds@CoolRat.org

dovecot-sieve has been updated to a new implementation compatible with dovecot 1.2.x. For details of what this means please refer to:

http://wiki.dovecot.org/LDA/Sieve/Dovecot#Migration_from_CMUSieve

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:

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@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

see

Am 31.12.2014 um 17:05 schrieb Robert Blayzor:

missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

Am 31.12.2014 um 18:36 schrieb Robert Blayzor:

On Dec 31, 2014, at 11:18 AM, Robert Schetterer rs@sys4.de wrote:

...

Am 31.12.2014 um 17:05 schrieb Robert Blayzor:

...

missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)

Best Regards MfG Robert Schetterer

Which is correct. Dovecot-lda is running as the local user account, the default is not owned by them and the local user cannot write into the global/default sieve location. The path has a precompiled default sieve script that the user does not own, it's a default.

So why is trying to compile the script (which is already compiled) in the default location? That is the problem.

-Robert

However logs mostly tells truth , you have a permission problem Happy New Year

Best Regards MfG Robert Schetterer

-- [*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

On Jan 1, 2015, at 8:10 AM, Stephan Bosch stephan@rename-it.nl wrote:

Could you enable mail_debug? That should show why it is trying to recompile the Sieve script.

Well, that it does! And it's saying the script is "not up to date" and tries to recompile it. However, I'm not sure why it would say it's NOT up to date, it most certainly was manually compiled by me and not touched afterwards. Would commented likes, starting with "#" in the script have anything to do with it?

Jan 01 13:32:30 lda(rt): Debug: sieve: file storage: Using script storage path: /etc/dovecot/sieve/default.sieve Jan 01 13:32:30 lda(rt): Debug: sieve: file script: Opened script default' from /etc/dovecot/sieve/default.sieve' Jan 01 13:32:30 lda(rt): Debug: sieve: Using the following location for user's Sieve script: /etc/dovecot/sieve/default.sieve Jan 01 13:32:30 lda(rt): Debug: sieve: Loading script /etc/dovecot/sieve/default.sieve Jan 01 13:32:30 lda(rt): Debug: sieve: Script binary /etc/dovecot/sieve/default.svbin is not up-to-date Jan 01 13:32:30 lda(rt): Debug: sieve: Script `default' from /etc/dovecot/sieve/default.sieve successfully compiled Jan 01 13:32:30 lda(rt): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.dogpile.devnull.us.679.) failed: Permission denied (euid=1002(rt) egid=1002(rt) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)

On Jan 1, 2015, at 9:12 AM, Gene Heskett gheskett@wdtv.com wrote:

Obviously, the last 3 lines are showing a perms problem.

Yes, I know it's a permissions problem. But there should be NO permissions problem as it should not be trying to recompile the script. The script was already pre-compiled and has not changed. (though it thinks it's "out of date" ?). The only "fix" would be to chmod 777 the directory where the default script is so that EVERYONE could compile it at the location. (even though it shouldn't need to be because it was already precompiled) But that would be rather silly now, wouldn't it?

These are default sieve scripts that are not in the users homedir, so they have no permission to compile and write them in a directory they don't own.

-Robert

On Jan 1, 2015, at 9:50 AM, Stephan Bosch stephan@rename-it.nl wrote:

Hmm. This smells like a bug. I notice that your modification times of the .sieve and .svbin file are exactly the same (that is somewhat unusual). I'm looking at a potential bug that would explain your problem.

To confirm, could you try running sievec again, so that the .svbin is actually newer than the .sieve?

Sorry about that. ls -l was only showing minutes the actual file mtime *is* newer:

ls -l -rw-r--r-- 1 root wheel 168 Jan 1 13:37 default.sieve -rw-r--r-- 1 root wheel 300 Jan 1 13:37 default.svbin

stat -f %Sm default.sieve Jan 1 13:37:42 2015

stat -f %Sm default.svbin Jan 1 13:37:51 2015

I did just run it again... same problem:

-rw-r--r-- 1 root wheel 168 Jan 1 13:37 default.sieve -rw-r--r-- 1 root wheel 300 Jan 1 14:55 default.svbin

Jan 1 14:56:52 dovecot: lda(fred): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.localhost.1435.) failed: Permission denied (euid=1002(fred) egid=1002(fred) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755) Jan 1 14:56:52 dovecot: lda(fred): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/etc/dovecot/sieve/default.sieve' need to be pre-compiled using the sievec tool

TIA

On 1/1/2015 4:17 PM, Robert Blayzor wrote:

On Jan 1, 2015, at 9:58 AM, Robert Blayzor rblayzor.bulk@inoc.net wrote:

...

...

Hmm. This smells like a bug. I notice that your modification times of the .sieve and .svbin file are exactly the same (that is somewhat unusual). I'm looking at a potential bug that would explain your problem.

To confirm, could you try running sievec again, so that the .svbin is actually newer than the .sieve?

If it makes any difference at all... I only see this using "dovecot-lda". If I change my Exim transport to use Dovecot's LMTP, I do not see this problem.

That is odd.

You can try the latest version. I've added some more debugging regarding the up-to-date check.

For the record also, the script DOES still execute (the compiled version that exists), even after the error...

It compiles, so it can be executed. It just cannot store the binary for future use. So, it will work as normal, but it is not efficient as it compiles the Sieve script for every incoming message.

Regards,

Stephan.

On 1/26/2015 3:43 PM, Olaf Hopp wrote:

On 01/01/2015 05:22 PM, Stephan Bosch wrote:

...

On 1/1/2015 4:17 PM, Robert Blayzor wrote:

...

On Jan 1, 2015, at 9:58 AM, Robert Blayzor rblayzor.bulk@inoc.net wrote:

...

...

Hmm. This smells like a bug. I notice that your modification times of the .sieve and .svbin file are exactly the same (that is somewhat unusual). I'm looking at a potential bug that would explain your problem.

To confirm, could you try running sievec again, so that the .svbin is actually newer than the .sieve?

If it makes any difference at all... I only see this using "dovecot-lda". If I change my Exim transport to use Dovecot's LMTP, I do not see this problem.

That is odd.

Hi Stephan and Robert, the same issue here and I'm using Exim with dovecot-lmtp and not with dovecot-lda. So it doesn't seem to be a problem of LDA vs. lmtp

Do you have the opportunity to test this with the latest Mercurial revision? This adds a bit more debug information on the up-to-date check.

Otherwise, you'll need to wait until the next release is done.

Regards,

Stephan.