Redirecting emails with dovecot + sieve produce an error in postfix

English Applications
1

I am running a Leap 15.2 server with dovecot supporting the IMAP service. Incoming email retrieved with fetchmail is passed to dovecot as the MDA and which invokes sieve. The sieve script redirects a specific address as follows:

if address :is "to","cc","bcc"] "skylabdown@mydomain.com"
{
    redirect "email@anotherdomain.com";
}

This gives the following error:

sendmail: fatal: execvp /usr/sbin/postdrop: Permission denied
sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1

The permissions for postdrop are:

-rwxr-sr-x 1 root maildrop 14512 Dec 9 22:54 /usr/sbin/postdrop

It does not matter if I run the fetchmail command as either root or the intended user. The error is the same.

My gut feel is that it’s going to be a group permission or something like that but I don’t know what they should be.

I have other filters later on in the script and they all run fine.

Any clues?

Thanks.

2

I don’t really know the answer, and it is many years since I last played with sendmail configuration.

From the error message, it looks as if there is a problem with “/usr/sbin/postdrop”. I don’t have that file here, probably because I have not installed “dovecot”.

Maybe try:

file /usr/sbin/postdrop

to see what kind of file this is. Perhaps it is not an actual executable file.

3

man postdrop says:

The command is designed to run with set-group ID privileges, so that it can write to the maildrop queue directory and so that it can connect to Postfix daemon processes.

Check the destination of your stuff. On my machine this would be something in /var/spool/postfix/maildrop/ as I found by running ‘postdrop -v’.

4

If that were the problem, I would expect a message from “postdrop”. But the error message appears to be from “execvp”, which suggests that “postdrop” cannot even be started.

5

Thanks for the suggestions. Opened up the permissions on /var/spool/postfix/maildrop but no change.

output from “postdrop -v” was as follows:

postdrop: name_mask: ipv4
postdrop: name_mask: ipv6
postdrop: name_mask: subnet
postdrop: inet_addr_local: configured 5 IPv4 addresses
postdrop: inet_addr_local: configured 6 IPv6 addresses
postdrop: been_here: 127.0.0.0/8: 0
postdrop: been_here: 192.168.25.0/24: 0
postdrop: been_here: 10.0.0.0/24: 0
postdrop: been_here: 192.168.100.0/24: 0
postdrop: been_here: 192.168.102.1/32: 0
postdrop: been_here: ::1]/128: 0
postdrop: been_here: [2a00:23c5:b39c:9501::]/64: 0
postdrop: been_here: [2a00:23c5:b39c:9501::]/64: 1
postdrop: been_here: [fe80::]/64: 0
postdrop: been_here: [fe80::]/64: 1
postdrop: been_here: [fe80::]/64: 1
postdrop: mynetworks_core: 127.0.0.0/8 192.168.25.0/24 10.0.0.0/24 192.168.100.0/24 192.168.102.1/32 ::1]/128 [2a00:23c5:b39c:9501::]/64 [fe80::]/64 
postdrop: chdir /var/spool/postfix
postdrop: open maildrop/43317107D56
postdrop: send attr queue_id = 43317107D56
queue_id43317107D56

So I don’t think the issue is with postdrop but rather the permissions that are used to invoke it.

6

I think the following permissions are correct:

**erlangen:~ #** ll /usr/sbin/postdrop         
-rwxr-sr-x 1 root maildrop 18600 Jan 26 15:21 /usr/sbin/postdrop 
**erlangen:~ #**

However Wietse Venema says: Apparmor or some other system call filter is interfering." For testing this you may disable apparmor temporarily.

7

Those are the permissions I have too. Apparmor is disabled.

I have setup dovecot on another server and it works fine and there are virtually no differences in the configs. All permissions and users/groups are the same.

8

Ok - I thought Apparmor was disabled … I had disabled it in the past and somehow it’s gotten re-enabled!!!

So yes, it was Apparmor defending me from what I wanted!

Thanks everyone who has taken time to read my problem.

9

Thanks for the feedback!