Dovecot with Pigeonhole problems

Tristan

Tristan

Verified User
Joined
Feb 11, 2005
Messages
684
Location
The Netherlands
Hi there,

also posted this here:

http://forum.directadmin.com/showthread.php?t=47640&p=244845#post244845

but this might be a more appropriate forum. We're getting lots of Pigeonhole (version 0.4.2) related errors nowadays with at least Dovecot 2.2.6, 2.2.7 and 2.2.8 as well now:

Code: 
Nov 18 14:32:45 server22 dovecot[28771]: lmtp(29023, [email protected]): Error: Z9GKF/kWilJfcQAAt4jBDg: sieve: binary save: failed to create temporary file: open(/var/lib/dovecot/sieve/default.svbin.server22.prism.nl.29023.) failed: Permission denied (euid=1035(dtestmadmin) egid=8(mail) missing +w perm: /var/lib/dovecot/sieve, dir owned by 0:0 mode=0755)
Nov 18 14:32:45 server22 dovecot[28771]: lmtp(29023, [email protected]): Error: Z9GKF/kWilJfcQAAt4jBDg: sieve: the lda sieve plugin does not have permission to save global sieve script binaries; global sieve scripts like /var/lib/dovecot/sieve/default.sieve;name=main script need to be pre-compiled using the sievec tool
Nov 18 14:32:46 server22 dovecot[28771]: lmtp(29023, [email protected]): Z9GKF/kWilJfcQAAt4jBDg: sieve: msgid=<314b172955ab583e9013524fb7b5c5fcacb.20131118112732@mail.extserver.net>: stored mail into mailbox 'INBOX'

Could this be a problem with the build script for Pigeonhole?

Thanks for any help!
 
You were spot on there toml! A simple:

Code: 
sievec /var/lib/dovecot/sieve/

did the trick, but shouldn't that be part of the build script?
 
It is:
Code: 
        if [ ! -d /var/lib/dovecot/sieve ]; then
                mkdir -p /var/lib/dovecot/sieve >/dev/null 2>&1
                touch /var/lib/dovecot/sieve/default.sieve
                sievec /var/lib/dovecot/sieve/default.sieve
                chown mail:mail /var/lib/dovecot/sieve/default.sieve
        fi
I assume you already had that directory and/or your default.sieve changed but didn't recompile.
 
Strange, this was a server installed from scratch with CB2.0 maybe the Dovecot install already created that /var/lib/dovecot/sieve dir?
 
Try this:

Code: 
[COLOR=#666666]mkdir -p /var/lib/dovecot/sieve/
[/COLOR]touch /var/lib/dovecot/sieve/default.sieve
sievec /var/lib/dovecot/sieve/default.sieve
chown mail:mail /var/lib/dovecot/sieve/* -R
 
When I make a "tail -f /var/log/maillog" it still don't seem to work. Here is the output:

Feb 19 00:37:07 server spamd[24765]: prefork: child states: II
Feb 19 02:22:23 server spamd[1942]: logger: removing stderr method
Feb 19 02:22:25 server spamd[1955]: spamd: server started on port 783/tcp (running version 3.3.2)
Feb 19 02:22:25 server spamd[1955]: spamd: server pid: 1955
Feb 19 02:22:25 server spamd[1955]: spamd: server successfully spawned child process, pid 1962
Feb 19 02:22:25 server spamd[1955]: spamd: server successfully spawned child process, pid 1963
Feb 19 02:22:25 server spamd[1955]: prefork: child states: IS
Feb 19 02:22:25 server spamd[1955]: prefork: child states: II
Click to expand...

Any advice?
 
Is that debian? I don't get why there are logged lines of spamassassin in /var/log/maillog?
And do you have any issues with sending or recieving emails?
 
I was setting up new Centos 6.6 servers with Custombuild 2.0 and its plugin - doing everything by the book with no real command line hacking but I still had the seive errors.

I followed Alex's suggestion but still had errors like this:

Apr 24 15:32:08 ns113 dovecot[28101]: lmtp([email protected]): Error: oB9UCGjEOlWAdAAA+4UX/g: sieve: binary save: failed to create temporary file: open(/var/lib/dovecot/sieve/default.svbin.ns113.101sitehosting.net.29824.) failed: Permission denied (euid=759(qca) egid=12(mail) missing +w perm: /var/lib/dovecot/sieve, dir owned by 8:12 mode=0755)
Apr 24 15:32:08 ns113 dovecot[28101]: lmtp([email protected]): Error: oB9UCGjEOlWAdAAA+4UX/g: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/var/lib/dovecot/sieve/default.sieve' need to be pre-compiled using the sievec tool

I then followed the hints in the errors in the logs in /var/log/maillog searching for "missing +w perm"

This is how I fixed the file permissions and recompiled what I needed to make it work and to address the 2 errors shown in my example above.


Code: 
mkdir -p /var/lib/dovecot/sieve/
chmod 777 /var/lib/dovecot/sieve
sievec /var/lib/dovecot/sieve/
touch /var/lib/dovecot/sieve/default.sieve
sievec /var/lib/dovecot/sieve/default.sieve


then check with:
tail -f /var/log/maillog

same email account after this change, shows this instead with no errors.
Apr 24 15:41:52 ns113 dovecot[28101]: lmtp(30756): Connect from local
Apr 24 15:41:52 ns113 dovecot[28101]: auth-worker(4100): shadow([email protected]): unknown user
Apr 24 15:41:52 ns113 dovecot[28101]: lmtp([email protected]): 233VDLDGOlUkeAAA+4UX/g: sieve: msgid=<[email protected]>: stored mail into mailbox 'INBOX'
Apr 24 15:41:52 ns113 dovecot[28101]: lmtp(30756): Disconnect from local: Successful quit
 
Last edited:
Just a guess. If it's not a temp file /var/lib/dovecot/sieve/default.svbin.ns113.101sitehosting.net.29824, then you could try this:

Code: 
touch /var/lib/dovecot/sieve/default.svbin.ns113.101sitehosting.net.29824
sievec /var/lib/dovecot/sieve/default.svbin.ns113.101sitehosting.net.29824
chown mail:mail /var/lib/dovecot/sieve/* -R
 
Please post us the output of:
Code: 
ls -l /var/lib/dovecot/sieve

Before applying any changes to it. It should use global file (/var/lib/dovecot/sieve/default.svbin) by default, and not to create a per-user file (in your case qca user tries to create a file in /var/lib/dovecot/sieve). Moreover, directory should not need mail ownership, because LMTP process runs under root privileges.
 
It looks like these commands fix this for me on Debian, as suggested by Martynas:

Code: 
sievec /var/lib/dovecot/sieve/default.sieve
chown mail:mail /var/lib/dovecot/sieve/default.sieve

so the default.sieve file should be owned by mail I guess. Will this be part of an updated version of the CB script in the future?
 
Martynas,

I agree with you - it doesn't create a per-user file but it does seem to create a file with permissions for the first person who uses it.

Here is the contents of my folder.

smtalk said:
Please post us the output of:
Code: 
ls -l /var/lib/dovecot/sieve

Before applying any changes to it. It should use global file (/var/lib/dovecot/sieve/default.svbin) by default, and not to create a per-user file (in your case qca user tries to create a file in /var/lib/dovecot/sieve). Moreover, directory should not need mail ownership, because LMTP process runs under root privileges.
Click to expand...


[root@expiryda103 dovecot]# ls -la
total 24
drwxr-xr-x 3 root root 4096 Apr 25 17:57 .
drwxr-xr-x 21 root root 4096 Apr 8 12:06 ..
-rw-r--r-- 1 root root 62 Apr 25 17:57 instances
-rw-r--r-- 1 root root 9 Apr 25 17:57 mounts
drwxrwxrwx 2 root root 4096 Apr 25 17:51 sieve
-rw-r--r-- 1 root root 230 Apr 3 10:47 ssl-parameters.dat
[root@expiryda103 dovecot]# pwd
/var/lib/dovecot
[root@expiryda103 dovecot]# ls -l /var/lib/dovecot/sieve
total 4
-rw-r--r-- 1 mail mail 0 Apr 25 17:50 default.sieve
-rw-r--r-- 1 passincn mail 164 Apr 25 17:51 default.svbin



as you can see the dovecot folder is root and the contents of the /var/lib/dovecot/sieve folder are automatically assigned mail and one of my user's names for ownership. I don't understand that as it seems to work for everyone but it seems the first person to call the sieve is that one assigned to default.svbin.

The center of that contents of that file looks like this @^@^Dfile^@^@$/var/lib/dovecot/sieve/default.sieve^@^@^ and apparently refers to the other empty file in that folder.
 
I wonder why passincn is the owner of default.svbin file. Isn't your dovecot configuration custom?
 
smtalk said:
I wonder why passincn is the owner of default.svbin file. Isn't your dovecot configuration custom?
Click to expand...

I wonder as well - I didn't set it to passincn - per server it is a different user from that specific server.
On each new custombuild 2.0 server I simply followed the path for Custombuild 2.0 install from a fresh CentOS 6.6 server and this is where it ended up. I then imported sites from the old servers and they work fine but somehow Seive chose those random users as owner for that file.

Gerry
 
You must log in or register to reply here.
Back
Top