On Mon, May 11, 2026 at 00:41:17 +0000, Andy Smith wrote: > I still don't actually understand how the mail delivery part of postfix > inherits the systemd restrictions of the process *submitting* the mail > (monit), but that's probably because I'm not a user of postfix. It's > clearly what is happening.
I'm somewhat new to Postfix, so I don't have a full understanding either, but just going through the man pages: "man postfix" takes me to postfix(1) which mentions sendmail(1). sendmail(1) says it relies on postdrop(1) to create a queue file. greg@remote:~$ ls -l /usr/sbin/postdrop -r-xr-sr-x 1 root postdrop 13740 Jan 28 2024 /usr/sbin/postdrop The setgid bit is critically important there. Putting this all together, it looks like the OP's program (which is under restrictions) tries to send mail, and it does this in the normal Unix way, by invoking /usr/sbin/sendmail (either directly, or by calling an MUA). sendmail(1) calls postdrop(1) which is setgid, and writes the message directly into the Postfix queue, rather than communicating with some sort of queue-controlling daemon. I wonder whether a similar problem occurs if the system uses exim4 or sendmail (etc.), rather than Postfix. I'm guessing there's at least one MTA that doesn't have this problem, and that's what the monit maintainer uses. I'm uncertain what the best fix is. Telling monit's systemd unit to allow the Postfix queue directory will obviously only fix it on a system that uses Postfix. That may be fine for the OP, but probably wouldn't be the preferred solution for the monit maintainer. Then again, maybe just un-blocking *every* MTA's queue directory (among the MTAs that have this issue) might end up being the least bad answer.
