Re: Sieve permissions issue following update

2015-02-01 Thread Stephan Bosch
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 
>>> 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.


Re: Sieve permissions issue following update

2015-01-26 Thread Olaf Hopp

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

Pigeonhole 0.4.5
Dovecot2.2.15
CentOS 6.6

Regards,
Olaf

--
Karlsruher Institut für Technologie (KIT)
ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik

Dipl.-Geophys. Olaf Hopp
- Leitung IT-Dienste -

Am Fasanengarten 5, Gebäude 50.34, Raum 009
76131 Karlsruhe
Telefon: +49 721 608-43973
Fax: +49 721 608-46699
E-Mail: olaf.h...@kit.edu
atis.informatik.kit.edu

www.kit.edu

KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum 
in der Helmholtz-Gemeinschaft




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Sieve permissions issue following update

2015-01-01 Thread Stephan Bosch
On 1/1/2015 4:17 PM, Robert Blayzor wrote:
> On Jan 1, 2015, at 9:58 AM, Robert Blayzor  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.


Re: Sieve permissions issue following update

2015-01-01 Thread Robert Blayzor
On Jan 1, 2015, at 9:58 AM, Robert Blayzor  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.

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

--
Robert


Re: Sieve permissions issue following update

2015-01-01 Thread Robert Blayzor
On Jan 1, 2015, at 9:50 AM, Stephan Bosch  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


Re: Sieve permissions issue following update

2015-01-01 Thread Stephan Bosch
On 1/1/2015 2:36 PM, Robert Blayzor wrote:
> On Jan 1, 2015, at 8:10 AM, Stephan Bosch  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)

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?

Regards,

Stephan.


Re: Sieve permissions issue following update

2015-01-01 Thread Robert Blayzor
On Jan 1, 2015, at 9:12 AM, Gene Heskett  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


Re: Sieve permissions issue following update

2015-01-01 Thread Gene Heskett
On Thursday 01 January 2015 08:36:40 Robert Blayzor did opine
And Gene did reply:
> On Jan 1, 2015, at 8:10 AM, Stephan Bosch  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)

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

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS


Re: Sieve permissions issue following update

2015-01-01 Thread Robert Blayzor
On Jan 1, 2015, at 8:10 AM, Stephan Bosch  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)


Re: Sieve permissions issue following update

2015-01-01 Thread Stephan Bosch
On 12/31/2014 5:05 PM, Robert Blayzor wrote:
> On Dec 10, 2014, at 1:52 AM, Steffen Kaiser  
> wrote:
>
> I've been following this thread and have been seeing a similar problem.  
> Dovecot 2.2.5 and pigeonhole-0.4.6
>

> Yet, dovecot still tries to compile it under the user in that path.
>
>
> Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: binary save: failed to 
> create temporary file: 
> open(/etc/dovecot/sieve/default.svbin.localhost.87581.) failed: Permission 
> denied (euid=1002(fred) egid=1002(fred) missing +w perm: /etc/dovecot/sieve, 
> dir owned by 26:0 mode=0755)
> Dec 31 15:55:11 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
> Dec 31 15:55:11 dovecot: lda(fred): sieve: 
> msgid=<63706cea-e77f-45be-b848-1e664773e...@inoc.net>: stored mail into 
> mailbox 'INBOX'

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

Regards,

Stephan.


Re: Sieve permissions issue following update

2014-12-31 Thread Robert Schetterer
Am 31.12.2014 um 18:36 schrieb Robert Blayzor:
> On Dec 31, 2014, at 11:18 AM, Robert Schetterer  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


Re: Sieve permissions issue following update

2014-12-31 Thread Robert Blayzor
On Dec 31, 2014, at 11:18 AM, Robert Schetterer  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


Re: Sieve permissions issue following update

2014-12-31 Thread Robert Schetterer
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


Re: Sieve permissions issue following update

2014-12-31 Thread Robert Blayzor
On Dec 10, 2014, at 1:52 AM, Steffen Kaiser  
wrote:
> 
>> 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:
> 
> 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.
> 
> Did _you_ _manually_ run:
> 
> cd /usr/local/etc/dovecot/sieve
> rm 10-move-spam.svbin
> sievec -D 10-move-spam.sieve
> 
> ? And, is the sievec command displaying the Pigeonhole version you have 
> installed?


I've been following this thread and have been seeing a similar problem.  
Dovecot 2.2.5 and pigeonhole-0.4.6

The problem I'm having is with "sieve_default" script that's in a directory 
users have no permission to:

  sieve = ~/.dovecot.sieve
  sieve_dir = ~/.sieve.d
  sieve_default = /etc/dovecot/sieve/default.sieve


My sieve.default only has "keep;" and I manually removed and compiled it.  

sievec(root): Debug: sieve: Pigeonhole version 0.4.6 (3e924b1b6c5c+) 
initializing
sievec(root): Debug: sieve: include: sieve_global is not set; it is currently 
not possible to include `:global' scripts.
sievec(root): Debug: sieve: file storage: Using script storage path: 
default.sieve
sievec(root): Debug: sieve: file script: Opened script `default' from 
`default.sieve'
sievec(root): Debug: sieve: Script `default' from default.sieve successfully 
compiled


ls -l
-rw-r--r--  1 root  wheel6 Dec 31 15:54 default.sieve
-rw-r--r--  1 root  wheel  142 Dec 31 15:54 default.svbin


Yet, dovecot still tries to compile it under the user in that path.


Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: binary save: failed to create 
temporary file: open(/etc/dovecot/sieve/default.svbin.localhost.87581.) failed: 
Permission denied (euid=1002(fred) egid=1002(fred) missing +w perm: 
/etc/dovecot/sieve, dir owned by 26:0 mode=0755)
Dec 31 15:55:11 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
Dec 31 15:55:11 dovecot: lda(fred): sieve: 
msgid=<63706cea-e77f-45be-b848-1e664773e...@inoc.net>: stored mail into mailbox 
'INBOX'


Ideas?


Re: Sieve permissions issue following update [solved]

2014-12-11 Thread Steffen Kaiser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 11 Dec 2014, David Gessel wrote:


and watching the logs:
dovecot: lda(ges...@blackrosetech.com): sieve: 
msgid=: 
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(ges...@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.

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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBVIlrdHz1H7kL/d9rAQLYBAf/bzt+3OLt6f236hd4N8fWOjo6dXJ5Cc5X
EJOHKcyMeHIzVSl2GkM6ckKkfRuIIjmK5DW3h36JhaIx7wh2nQJZnNPj0xCub6hK
4xE/HRoqfpnhW36Z5XvPZc656N8ut+gx0phnHxk11K1iV8kPHQsNy29d9213UWVP
yoVzaVLMBHYBRSMGIpU+10MRiSfFAbBce4mBWZ5Dt0bSUHXs5cDGRnRwH7HAvr6l
k2xeBmLf4oME7Y6/Ja75CWcHnnMlTMCp4J//zfHQnsrV7nFjEMiESU8MH3Z0IXqL
z4t9MVRdGWb17Sa4W22/LdainnxFcSKWR4dGX6bNu6qYLdApKXHzkQ==
=4TlD
-END PGP SIGNATURE-


Re: Sieve permissions issue following update [solved]

2014-12-10 Thread David Gessel


 Original Message 
Subject: Re: Sieve permissions issue following update
From: Steffen Kaiser 
To: David Gessel 
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(ges...@blackrosetech.com): sieve: 
msgid=: 
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(ges...@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: y...@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


Re: Sieve permissions issue following update

2014-12-09 Thread Steffen Kaiser

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 9 Dec 2014, David Gessel wrote:


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:


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.


Did _you_ _manually_ run:

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

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



 Original Message 
Subject: Re: Sieve permissions issue following update
From: Pascal Volk 
To: Dovecot Mailing List 
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(ges...@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(ges...@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_Scripts>:

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


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBVIftyXz1H7kL/d9rAQLoLwf/bA1r7DR5AVxBUYT2R54eM8yALRJL3PLJ
IfZzIAaqeoZj5JtKR84F3ApDpLRYaLw2juXeEAELV+2GJXThDIEyLzbkhA3xwPOb
TViaaN1Htz3H+Scz3MDC/fxGAiNGNENGNj1GP4VJGM7DibrDOcd/pxePJjBvdKFS
YzhYxAng94UZqy23CZRvsbZiHnsh1ph2C3yXhxES3Ycvgg/ETBIz98DVTfJ74b4J
AEEUVnKIefWGun+WxWNgyI+p/aOSE3PyrHhmZx5ttgHhqU8KnmiKpWMaTUlpUmVb
U5ddZndFIERBfuDaGUdMsW0sDORJ/XswF6O/Gp3UF4NbFmNGQv8MZg==
=k9Fz
-END PGP SIGNATURE-


Re: Sieve permissions issue following update

2014-12-09 Thread David Gessel


 Original Message 
Subject: Re: Sieve permissions issue following update
From: Pascal Volk 
To: Dovecot Mailing List 
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(ges...@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(ges...@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  200 29120K  6080K kqread  7   0:00   0.00% 
managesieve-login

As for the error 

dovecot: lda(ges...@blackrosetech.com): Error: 

Re: Sieve permissions issue following update

2014-12-09 Thread Pascal Volk
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(ges...@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(ges...@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
.

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.


Regards,
Pascal
-- 
The trapper recommends today: fabaceae.1434...@localdomain.org


Re: Sieve permissions issue following update

2014-12-09 Thread David Gessel
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(ges...@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(ges...@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 
To: Dovecot Mailing List 
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(ges...@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(ges...@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_Scripts>:
> 
>   To mitigate this problem, the administrator must manually
>   pre-compile global scripts using the sievec command line tool.
> 
> 
> Regards,
> Pascal
> 


Re: Sieve permissions issue following update

2014-12-09 Thread Pascal Volk
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(ges...@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(ges...@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
:

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


Regards,
Pascal
-- 
The trapper recommends today: defaced.1434...@localdomain.org


Sieve permissions issue following update

2014-12-09 Thread David Gessel
I recently updated dovecot and my sieve filters stopped working.  Checking the 
logs I see:

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


However this fairly clear advice on the failure seems to be contradicted by:

 # id vmail
uid=5000(vmail) gid=5000(vmail) groups=5000(vmail),6(mail)

?


dovecot-pigeonhole-0.4.6   =   up-to-date with index
dovecot2-2.2.15_1  =   up-to-date with index


uname -a
FreeBSD host.domain.com 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268932: Mon Jul 21 
15:51:38 PDT 2014 
ges...@host1.domain.com:/usr/obj/usr/src/sys/BARCELONA-13-08  amd64