Forwarded to devs Dovecot Sieve filtering broke after upgrading from 17.5.3 to 17.8.11

[burnley]

TITLE:

Dovecot Sieve filtering broke after upgrading from 17.5.3 to 17.8.11​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx Version 17.8.11 Update #54, last updated on May 27, 2019 10:26 PM
‪CentOS Linux 7.6.1810 (Core)‬​

PROBLEM DESCRIPTION:

We're using Dovecot Sieve filtering capabilities to report spam/ham messages and after upgrading from 17.5.3 to 17.8.11 we started seeing errors like these in maillog:

[...]
May 28 14:14:31 plesk journal: plesk sendmail[9740]: cannot create temporary file - (30) Read-only file system
May 28 14:14:31 plesk journal: plesk sendmail[9740]: Unable to save stdin content to temporary file
May 28 14:14:31 plesk dovecot: imap: Error: plesk sendmail[9740]: cannot create temporary file - (30) Read-only file system
May 28 14:14:31 plesk dovecot: imap: Error: plesk sendmail[9740]: Unable to save stdin content to temporary file
May 28 14:14:31 host09 dovecot: report-spam.sh: Called for mailbox [email protected], Subject: Re: domain.com: Trouble Managing Your Social Media?
May 28 14:14:31 host09 dovecot: service=imap, [email protected], ip=[x.x.x.x]. sieve: pipe action: piped message to program `report-spam.sh'
[...]

The Sieve script for spam reporting is /usr/lib64/dovecot/sieve/report-spam.sieve and reads:
---CUT HERE---
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables", "mime"];

if environment :matches "imap.user" "*" {
set "username" "${1}";
}

if header :matches "Subject" "*" {
set "subject" "${1}";
}

pipe :copy "report-spam.sh" [ "${username}", "${subject}" ];
---CUT HERE---

And the called script, /usr/lib64/dovecot/sieve/report-spam.sh:
---CUT HERE---
#!/bin/bash
/usr/sbin/sendmail -f "noreply@plesk" "[email protected]"
exec /usr/bin/logger -p mail.notice -t "dovecot: `basename $0`" Called for mailbox $1, Subject: ${@:2}
---CUT HERE---

I see 17.8.11 has introduced sendmail changes:
1. Sendmail on 17.5.3
# ls -l /usr/sbin/sendmail*
lrwxrwxrwx 1 root root 21 Feb 28 22:08 /usr/sbin/sendmail -> /etc/alternatives/mta
-rwxr-xr-x 1 root postdrop 247960 Oct 31 2018 /usr/sbin/sendmail.postfix
# ls -l /etc/alternatives/mta
lrwxrwxrwx 1 root root 45 Feb 28 22:08 /etc/alternatives/mta -> /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
# ldd /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
linux-vdso.so.1 => (0x00007ffc8f7ba000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00002b62615f1000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00002b6261a53000)
libc.so.6 => /lib64/libc.so.6 (0x00002b6261d08000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b62620d5000)
libz.so.1 => /lib64/libz.so.1 (0x00002b62622d9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b62624ef000)
/lib64/ld-linux-x86-64.so.2 (0x00002b62613cd000)

2. Sendmail on 17.8.11
# ls -l /usr/sbin/sendmail*
lrwxrwxrwx 1 root root 21 May 27 22:20 /usr/sbin/sendmail -> /etc/alternatives/mta
lrwxrwxrwx 1 root root 46 May 27 22:20 /usr/sbin/sendmail.postfix -> /usr/lib64/plesk-9.0/sendmail/sendmail.postfix
# ls -l /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
-r-sr-xr-x 1 root root 89336 Sep 27 2018 /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
# ldd /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
linux-vdso.so.1 => (0x00007ffd5f6c2000)
libboost_filesystem-plesk.so.1.65.1 => /usr/lib64/libboost-plesk-1.65/libboost_filesystem-plesk.so.1.65.1 (0x00002ab21910b000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00002ab219326000)
libboost_system-plesk.so.1.65.1 => /usr/lib64/libboost-plesk-1.65/libboost_system-plesk.so.1.65.1 (0x00002ab219690000)
libboost_regex-plesk.so.1.65.1 => /usr/lib64/libboost-plesk-1.65/libboost_regex-plesk.so.1.65.1 (0x00002ab219895000)
libz.so.1 => /lib64/libz.so.1 (0x00002ab219ba0000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00002ab219db6000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00002ab21a06b000)
libmariadb.so.1 => /usr/lib64/libmariadbclient-plesk-1.0/libmariadb.so.1 (0x00002ab21a4cd000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00002ab21a70d000)
libidn.so.11 => /lib64/libidn.so.11 (0x00002ab21a933000)
libicuuc.so.50 => /lib64/libicuuc.so.50 (0x00002ab21ab66000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ab21aedf000)
libstdc++.so.6 => /usr/lib64/c++-plesk-6.3.0/lib64/libstdc++.so.6 (0x00002ab21b116000)
libm.so.6 => /lib64/libm.so.6 (0x00002ab21b498000)
libgcc_s.so.1 => /usr/lib64/c++-plesk-6.3.0/lib64/libgcc_s.so.1 (0x00002ab21b79a000)
libc.so.6 => /lib64/libc.so.6 (0x00002ab21b9b1000)
librt.so.1 => /lib64/librt.so.1 (0x00002ab21bd7e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ab21bf86000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ab21c1a2000)
libicudata.so.50 => /lib64/libicudata.so.50 (0x00002ab21c3a6000)
libicui18n.so.50 => /lib64/libicui18n.so.50 (0x00002ab21d978000)
libssl.so.10 => /lib64/libssl.so.10 (0x00002ab21dd77000)
libfreebl3.so => /lib64/libfreebl3.so (0x00002ab21dfe9000)
/lib64/ld-linux-x86-64.so.2 (0x00002ab218ee7000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00002ab21e1ec000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00002ab21e439000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002ab21e722000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00002ab21e926000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00002ab21eb59000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002ab21ed69000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00002ab21ef6d000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ab21f186000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00002ab21f3ad000)

How can I tell where is /usr/lib64/plesk-9.0/postfix-sendmail-wrapper trying to write the temporary files?​

STEPS TO REPRODUCE:

Configure Sieve filtering in 17.5.3, then upgrade from 17.5.3 to 17.8.11. If the filter relies on executing /usr/sbin/sendmail, it'll fail after upgrade.​

ACTUAL RESULT:

See above​

EXPECTED RESULT:

No failure.​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

Please check that /usr/local/psa/handlers/spool/ directory does not reside on a partition mounted read-only, intentionally or remounted by kernel due to some hardware problems. Please, inspect mount output, realpath may be useful as well if the path specified above contains symlinks.

EROFS = 30 suggests that the problem may be specific to the particular server configuration, not to the product in general.

 

[burnley]

Thanks Igor, the mount points/options have got nothing to do with the issue. It looks like Plesk decided for 17.8 to hide the original /usr/bin/sendmail.postfix and /usr/sbin/postdrop under /usr/lib64/plesk-9.0/sendmail/ owned by rootlesksendmail, 750 access mode. They've been replaced by a symlink for /usr/bin/sendmail.postfix and a wrapper for postdrop. Because of the change, even after using the original sendmail.postfix binary I was still getting errors like "warning: command "/usr/sbin/postdrop -r" exited with status 126" or "/usr/sbin/postdrop: line 3: exec: /usr/lib64/plesk-9.0/sendmail/postdrop: cannot execute: Permission denied". After changing the access mode on /usr/lib64/plesk-9.0/sendmail/ to 755 the errors have disappeared.
Why would Plesk move these 2 binaries in such a location? Is there any documentation on this change?

 

[IgorG]

From developer:

STEPS TO REPRODUCE:

Tried to do it but could not confirm the problem. A couple of minor issues I have met:

• /etc/dovecot/conf.d/90-plesk-sieve.conf where I put configuration as a quick solution got overwritten during upgrade.
• require [ "imapsieve" ] used in .sieve script causes the following error
  
  

  Error: sieve: report-spam: the imapsieve extension cannot be used outside IMAP

  
  so I removed this extension.

As soon as I restored sieve plugin configuration after upgrade, sieve filter became active again.

Please, do not make sendmail.postfix and postdrop world-executable. Note that even in 17.5 their permissions are

-rwxr-x---. 1 root postdrop 247960 Oct 30 2018 /usr/sbin/sendmail.postfix
-r-xr-s---. 1 root postdrop 218632 Oct 30 2018 /usr/sbin/postdrop

it is done to prevent security vulnerabilities, it was announced in release notes just as "security improvements". For the same reason the /usr/lib64/plesk-9.0/sendmail directory in Plesk-17.8 must not be world-executable.

The "public" interface is /usr/sbin/sendmail, I did not get the point with location of sendmail.postfix, it should not matter.

plesk version
Product version: Plesk Onyx 17.5.3 Update #73
Update date: 2019/05/29 15:18
Build date: 2018/12/14 14:00
OS version: CentOS 7.6.1810
Revision: 55d1b49a272f44666e1920eca8b6e4da449a38cd
Architecture: 64-bit
Wrapper version: 1.2

readlink -f /usr/sbin/sendmail
/usr/lib64/plesk-9.0/postfix-sendmail-wrapper

md5sum /usr/sbin/sendmail.postfix
20b427d71324f236a823e4e497c80b68 /usr/sbin/sendmail.postfix

plesk version
Product version: Plesk Onyx 17.8.11 Update #54
Update date: 2019/05/29 16:31
Build date: 2019/05/16 14:25
OS version: CentOS 7.6.1810
Revision: 161ebcd802c2e9a1feeef25c9264230f4aa68ea6
Architecture: 64-bit
Wrapper version: 1.2

readlink -f /usr/sbin/sendmail
/usr/lib64/plesk-9.0/postfix-sendmail-wrapper

ls -ld /usr/lib64/plesk-9.0/sendmail
drwxr-x---. 2 root plesksendmail 44 May 29 16:25 /usr/lib64/plesk-9.0/sendmail

ls -l /usr/lib64/plesk-9.0/sendmail
total 460
-rwxr-sr-x. 1 root postdrop 218632 Oct 30 2018 postdrop
-rwxr-xr-x. 1 root root 247960 Oct 30 2018 sendmail.postfix

md5sum /usr/lib64/plesk-9.0/sendmail/sendmail.postfix
20b427d71324f236a823e4e497c80b68 /usr/lib64/plesk-9.0/sendmail/sendmail.postfix

• postfix-sendmail-wrapper is used both by Plesk-17.5 and Plesk-17.8
• The file sendmail.postfix is the same however resides in different locations
• In 17.8 sendmail.postfix and postdrop are protected through /usr/lib64/plesk-9.0/sendmail directory permissions.

I still suggest to check that /usr/local/psa/handlers/spool/ is writable for popuser, especially that partition has not been remounted due to problems with filesystem.

 

[burnley]

Thanks Igor. There's nothing wrong with /usr/local/psa/handlers/spool, it's owned by popuseropuser. If it wasnt, or if there were write issues due to filesystem being mounted read-only we'd have had much bigger issues, no local delivery would have worked
stat /usr/local/psa/handlers/spool
File: ‘/usr/local/psa/handlers/spool’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: ca01h/51713d Inode: 1610871197 Links: 2
Access: (0770/drwxrwx---) Uid: ( 30/ popuser) Gid: ( 31/ popuser)
Access: 2019-05-30 11:52:17.379713226 +1000
Modify: 2019-05-30 11:51:19.340345394 +1000
Change: 2019-05-30 11:51:19.340345394 +1000
Birth: -

The issue, again, only replicates on the servers that have been upgraded from 17.5 to 17.8, at which point the sendmail & postdrop binaries were moved under /usr/lib64/plesk-9.0/sendmail. Also, if I stop using the original sendmail.postfix binary and switch back to the plesk sendmail wrapper I get:
May 30 12:40:41 plesk dovecot: imap: Error: plesk sendmail[2551]: cannot create temporary file - (30) Read-only file system
May 30 12:40:41 plesk dovecot: imap: Error: plesk sendmail[2551]: Unable to save stdin content to temporary file
May 30 12:40:41 plesk dovecot: report-ham.sh: Called for mailbox [email protected], Subject: Never miss a delivery again
May 30 12:40:41 plesk dovecot: service=imap, [email protected], ip=[x.x.x.x]. Error: sieve: pipe action: failed to pipe message to program `report-ham.sh': refer to server log for more information. [2019-05-30 12:40:41]
May 30 12:40:41 plesk dovecot: service=imap, [email protected], ip=[x.x.x.x. Error: sieve: Execution of script /usr/lib64/dovecot/sieve/report-ham.sieve failed

Here are the 2 sendmail wrappers, both 17.5 (pre-upgrade, working sieve filter) and 17.8 (post-upgrade, broken sieve filter):

1. 17.5:
[[email protected] ~]# readlink -f /usr/sbin/sendmail
/usr/lib64/plesk-9.0/postfix-sendmail-wrapper
[[email protected] ~]# ls -l /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
-r-sr-xr-x 1 root root 80976 Apr 18 2018 /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
[[email protected] ~]# md5sum /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
dd27bdc828ae49a84d5396c479a43367 /usr/lib64/plesk-9.0/postfix-sendmail-wrapper

2. 17.8:
[[email protected] ~]# readlink -f /usr/sbin/sendmail
/usr/lib64/plesk-9.0/postfix-sendmail-wrapper
[[email protected] ~]# ls -l /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
-r-sr-xr-x 1 root root 89336 Sep 27 2018 /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
[[email protected] ~]# md5sum /usr/lib64/plesk-9.0/postfix-sendmail-wrapper
a45e37a293fda543340624babac309f6 /usr/lib64/plesk-9.0/postfix-sendmail-wrapper

 

[IgorG]

From developer:

The issue, again, only replicates on the servers that have been upgraded from 17.5 to 17.8

That is exactly what I did yesterday. I setup a sieve filter and pipe command from your post (with minor modifications, e.g. set my test email address) for Plesk-17.5 and upgraded it to Plesk-17.8.

I can confirm that md5 sums for postfix-sendmail-wrapper on your servers are correct.

Does the following command work if executed from shell directly?

# /usr/sbin/sendmail -f "noreply@plesk" "[email protected]"

It should use the same stacks of sendmail wrapper and related utilities and invoke the same sendmail.postfix binary.

There are can be some specific dovecot settings you have on your server but missed in my minimal setup. Dovecot daemons may be restricted through .service files. You can add dumping of environment variables, working directory, mount points to some file to report-ham.sh.

You may contact support (referencing the forum thread) and provide ssh access to your server. Since simple scenario does not allow to catch the problem, some subtle configuration option on a particular server may be involved.

 

[burnley]

It works from cli Igor, as root:

echo "test" | /usr/sbin/sendmail -f "[email protected]" "[email protected]"
[root@plesk ~]#

May 30 15:30:47 plesk postfix/pickup[1838]: 83D47954A07: uid=0 from=<[email protected]>
May 30 15:30:47 plesk postfix/qmgr[32372]: 83D47954A07: from=<[email protected]>, size=414, nrcpt=1 (queue active)


As as user popuser after briefly changing its shell to /bin/bash:
su - popuser
Last login: Thu May 30 15:32:30 AEST 2019 on pts/0
-bash-4.2$ echo "test" | /usr/sbin/sendmail -f "[email protected]" "[email protected]"
-bash-4.2$

May 30 15:32:49 plesk postfix/pickup[1838]: 98FDF954A07: uid=110 from=<[email protected]>
May 30 15:32:49 plesk postfix/qmgr[32372]: 98FDF954A07: from=<[email protected]>, size=429, nrcpt=1 (queue active)

This makes me think that the sieve script is perhaps executed as another user instead of popuser? And it just happens to work in 17.5.3, but not anymore on 17.8.11 after tightening the sendmail access.

 

[IgorG]

You could add something like

envfile=`mktemp -t sieve-report-spam.XXXXXXXXXX`
echo "--- id ---" >>"$envfile" 2>&1
id >>"$envfile" 2>&1
echo "--- env ---" >>"$envfile" 2>&1
env >>"$envfile" 2>&1
echo "--- pwd ---" >>"$envfile" 2>&1
pwd >>"$envfile" 2>&1
echo "--- mountinfo ---" >>"$envfile" 2>&1
cat /proc/self/mountinfo >>"$envfile" 2>&1

to report-spam.sh to determine the exact environment.

 

[burnley]

Good idea, instead of writing to tmpfile I'm using syslog and here's what I got:
May 31 14:47:25 host01 dovecot: report-spam.sh: id=uid=110(popuser) gid=31(popuser) groups=31(popuser),97(dovecot) env=HOST=plesk [email protected] PWD=/mnt/xvda3/qmail/mailnames/domain.com/spamcop_spam SHLVL=1 HOME=/var/qmail/mailnames/domain.com/spamcop_spam _=/usr/bin/env pwd=/mnt/xvda3/qmail/mailnames/domain.com/spamcop_spam

The logger line I use in the script is:
/usr/bin/logger -p syslog.info -t "dovecot: `basename $0`" id=`id` env=`env` pwd=`pwd`

And /proc/self/mountpoint:
417 135 202:1 / / rw,relatime shared:114 master:1 - ext4 /dev/xvda1 rw,data=ordered
418 417 0:6 / /dev rw,nosuid shared:387 master:2 - devtmpfs devtmpfs rw,size=16459412k,nr_inodes=4114853,mode=755
419 418 0:19 / /dev/shm rw,nosuid,nodev shared:388 master:3 - tmpfs tmpfs rw,size=16288624k,nr_inodes=4072156
420 418 0:20 / /dev/pts rw,nosuid,noexec,relatime shared:389 master:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
421 418 0:17 / /dev/mqueue rw,relatime shared:390 master:21 - mqueue mqueue rw
422 418 0:34 / /dev/hugepages rw,relatime shared:391 master:23 - hugetlbfs hugetlbfs rw,pagesize=2M
423 417 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:400 master:5 - proc proc rw
424 423 0:33 / /proc/sys/fs/binfmt_misc rw,relatime shared:401 master:20 - autofs systemd-1 rw,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct
427 424 0:40 / /proc/sys/fs/binfmt_misc rw,relatime shared:402 master:542 - binfmt_misc binfmt_misc rw
428 417 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:403 master:6 - sysfs sysfs rw
429 428 0:7 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:404 master:7 - securityfs securityfs rw
430 428 0:22 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:405 master:8 - tmpfs tmpfs ro,size=16288128k,nr_inodes=4072032,mode=755
431 430 0:23 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:406 master:9 - cgroup cgroup rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
432 430 0:25 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:407 master:10 - cgroup cgroup rw,freezer
433 430 0:26 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:408 master:11 - cgroup cgroup rw,cpu,cpuacct
434 430 0:27 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:409 master:12 - cgroup cgroup rw,perf_event
435 430 0:28 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:410 master:13 - cgroup cgroup rw,devices
436 430 0:29 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime shared:411 master:14 - cgroup cgroup rw,net_cls
437 430 0:30 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:417 master:15 - cgroup cgroup rw,cpuset
438 430 0:31 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:432 master:16 - cgroup cgroup rw,memory
439 430 0:32 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:438 master:17 - cgroup cgroup rw,blkio
440 428 0:24 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:447 master:18 - pstore pstore rw
441 428 0:8 / /sys/kernel/debug rw,relatime shared:524 master:22 - debugfs debugfs rw
442 428 0:42 / /sys/fs/fuse/connections rw,relatime shared:541 master:520 - fusectl fusectl rw
450 417 0:21 / /run rw,nosuid,nodev shared:556 master:19 - tmpfs tmpfs rw,size=16288200k,nr_inodes=4072050,mode=755
470 417 202:3 / /mnt/xvda3 rw,relatime shared:558 master:24 - xfs /dev/xvda3 rw,attr2,inode64,noquota
587 418 0:43 / /dev rw,nosuid shared:392 - tmpfs tmpfs rw,mode=755
588 587 0:20 / /dev/pts rw,nosuid,noexec,relatime shared:393 master:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
589 587 0:19 / /dev/shm rw,nosuid,nodev shared:396 master:3 - tmpfs tmpfs rw,size=16288624k,nr_inodes=4072156
590 587 0:17 / /dev/mqueue rw,relatime shared:397 master:21 - mqueue mqueue rw
591 587 0:34 / /dev/hugepages rw,relatime shared:398 master:23 - hugetlbfs hugetlbfs rw,pagesize=2M
592 587 0:6 /log /dev/log rw,nosuid shared:399 master:2 - devtmpfs devtmpfs rw,size=16459412k,nr_inodes=4114853,mode=755
593 417 202:1 /tmp/systemd-private-3aa3f01606ee43aeaa554ebeea67ba90-dovecot.service-gcyR6c/tmp /tmp rw,relatime shared:567 master:1 - ext4 /dev/xvda1 rw,data=ordered
594 417 202:1 /var/tmp/systemd-private-3aa3f01606ee43aeaa554ebeea67ba90-dovecot.service-lisAVL/tmp /var/tmp rw,relatime shared:568 master:1 - ext4 /dev/xvda1 rw,data=ordered
595 417 202:1 /boot /boot ro,relatime shared:569 master:1 - ext4 /dev/xvda1 rw,data=ordered
596 417 202:1 /etc /etc ro,relatime shared:571 master:1 - ext4 /dev/xvda1 rw,data=ordered
598 417 202:1 /usr /usr ro,relatime shared:572 master:1 - ext4 /dev/xvda1 rw,data=ordered
388 450 0:41 / /run/user/0 rw,nosuid,nodev,relatime shared:359 master:241 - tmpfs tmpfs rw,size=3018112k,mode=700

The way I read all the information so far it looks like plesk-sendmail-wrapper on 17.8 can't run the read sendmail, or run postdrop to place the mail in the queue, because the 2 binaries are hidden away from popuser user.

 

[IgorG]

From developer:

Output of my script:

--- id ---
uid=30(popuser) gid=31(popuser) groups=31(popuser) context=system_u:system_r:dovecot_deliver_t:s0

context is missed in your case, so I assume, you do not have SELinux enabled, so it can not block file access (no entries in audit.log or journalctl output), improper selinux policies version should not be an issue as well.

Concerning env, Accordingly to Pigeonhole/Sieve/Plugins/Pipe - Dovecot Wiki

Directly forked programs are executed with a limited set of environment variables: HOME, USER, SENDER, RECIPIENT and ORIG_RECIPIENT. Programs executed through the script-pipe socket service currently have no environment set at all.

I have e.g. ORIG_RECIPIENT in my logs but do not see the value in yours.

The only difference I have noticed is that mailboxes are resided directly in /var/qmail/mailnames/, you have customized path /mnt/xvda3/qmail/mailnames unsure if it cause some problems.

The most puzzling is that you can send messages using

su - -s /bin/bash popuser
echo test | /usr/sbin/sendmail -f ...

that should mean that everything is set up correctly, sendmail wrapper works as expected.

I hope you do not have your own sendmail wrappers to log&block messages sent from php code. Such scripts sometimes have problems with passing of arguments. /usr/lib64/plesk-9.0/postfix-sendmail-wrapper, that is /usr/sbin/sendmail symlink target, has set UID bit so /usr/lib64/plesk-9.0/sendmail is not hidden from popuser.

You sendmail command is static, so should not cause any problem. I may ask you to add more logging: command line arguments passed to the script, process PID and process tree during script invocation ps axuwf, but likely you should contact support otherwise it would be difficult to find the difference with a working test server.