Issue Qmail / Dovecot - mail forwarding fails endlessly

[mborsig]

Hi,
after a lot of testing and config changing I decided to post the following issue here, hoping that anybody has a helping idea.

Situation:
I use Qmail and Dovecot at the latest Plesk Onyx Version with Centos 7. Sending and receiving mail works as well as the access via IMAP & POP3.
I now created a simple sieve rule for the local mailadress [email protected] that forwards every email containing special characters in subject to the external mailadress [email protected]. Creating the rule via roundcube works fine, the following is written in die sieve file in the users maildir:
if header :comparator "i;ascii-casemap" :contains "Subject" "A" {
redirect "[email protected]";
stop;
}
I don't use SElinux or AppArmor, so I assume it's not an audit related problem.

Problem:
The mail forward is working, but an error message appears in maillog and the mail stays in the local qmail queue. This results in forwarding the mail again and again with every qmail queue run - endlessly!
Error message in maillog:
Aug 28 02:30:53 mailserver dovecot: service=lda, [email protected], ip=[]. Error: sieve: msgid=<trinity-d6494239-8a9e-4b2f-8707-1f1a4b8e9a06-1535403770111@sender-server-01>: failed to redirect message to <[email protected]>: Failed to execute sendmail (temporary failure)
Aug 28 02:30:53 mailserver dovecot: service=lda, [email protected], ip=[]. Error: sieve: Execution of script /var/qmail/mailnames/localmail.com/user/.dovecot.sieve was aborted due to temporary failure (user logfile /var/qmail/mailnames/localmail.com/user/.dovecot.sieve.log may reveal additional details)
This message occures shortly (~20 sec) after the mail has been received and successfully forwarded and again after every new forward. The dovecot.sieve.log contains the same error again.

What I've done so far?
- Looking into mailqueue with qmail-qread shows the mail staying there endlessly with the same id.
- enabled debug mode in dovecot, don't got any additional useful information
- Sending a local mail by invoking /usr/sbin/sendmail directly from command line works fine, no problems.
- Setting sendmail_path in dovecot directly to sendmail wrapper has no effect
- Disabling NoNewPrivileges in /usr/lib/systemd/system/dovecot.service has no effect

Any help, ideas or suggestions would be appreciated!

 

[mborsig]

Small update from me, but still no solution:

Dovecot calls /usr/lib64/plesk-9.0/qmail-sendmail-wrapper during the mail delivery. This is a wrapper for /var/qmail/bin/sendmail.
I now modified the qmail-sendmail-wrapper a bit to see what it's doing via strace. The result is taht it wants to change his gid and call /var/qmail/bin/sendmail, all fails:
wait4(9145, plesk sendmail[9145]: Failed to change gid (1): Operation not permitted
plesk sendmail[9146]: my_popen(): execve(/var/qmail/bin/sendmail) failed: Permission denied [13]
plesk sendmail[9146]: Unable to execute MTA
plesk sendmail[9145]: sendmail unsuccessfully finished with exitcode 70
Unfortunately I can't see who wants to change a GID to what target ID! I already changed the set gid bit for both files, without any result.
The only thing that helps is if I do a chmod 777 on /var/qmail/bin/sendmail. Then the qmail-sendmail-wrapper can execute ist, but the progress stops at the next execution (which is qmail-inject) with the same error.

 

[mborsig]

Looks like a serious bug in permission management of plesk
Made a complete fresh test installation and saw the same problem.
Debugged a bit and found out that /usr/sbin/sendmail (which is a link to /usr/lib64/plesk-9.0/qmail-sendmail-wrapper) set his group id to 30 (popuser) during execution.
Before calling /var/qmail/bin/sendmail it tries to switch his group id to 2520 (qmail), which is of course not allowed, even with the setgid bit set. Because /var/qmail/bin/sendmail is only executable for group qmail, the execution will fail!

Plesk developers - now it's up to you!

 

[MarkM]

I'd submit it over here;

Reports

 

[mborsig]

I now created a bug report, let's see what happens ...

 

[mw004]

Two years later, there is no solution to the problem...