Bug #78916 [Com]: php-fpm 7.4.0 don't send mail via mail()

Edit report at https://bugs.php.net/bug.php?id=78916&edit=1 ID: 78916 Comment by: ilya at ilya dot pp dot ua Reported by: ilya at ilya dot pp dot ua Summary: php-fpm 7.4.0 don't send mail via mail() Status: Open Type: Bug Package: *Configuration Issues Operating System: systemd/linux PHP Version: 7.4.0 Block user comment: N Private report: N New Comment: I have a policy of trying to implement as much functionality as possible using the basic features of a programming language. I use third-party only when the necessary functionality is beyond the scope of this programming language (for example, export to pdf or xls). Sending mail is necessary for any programming language aimed at server-side web scripts. I did not know that sendmail needed root privileges to work (from the console, and from other scripts, I always sent mail via sendmail from a regular user without problems). If the basic mail () function written in C has such problems, and a third-party function written in PHP is better and safer, then why shouldn't the PHP developers rewrite it safely, possibly even preserving its interface? In C, can it be better and more productive, and most importantly, without third-party code? Or am I not understanding something? Previous Comments: ------------------------------------------------------------------------ [2019-12-06 07:48:42] fgfgfgfdf at somewhere dot com what about trying to understand what's going on when using mail()? the sendmail command forkend in the background with *root privileges* do what you want, the "Lenart NotABag Pottering" gave you the capabilities to make your system as unsecure as you want within /etc/systemd/system/servicename.service.d/ defaults have to be secure, if you know what you are doing which i doubt make it unsecure as you want ------------------------------------------------------------------------ [2019-12-06 07:42:58] ilya at ilya dot pp dot ua For 20 years we lived without systemd and without their limitations and everything was fine, but Lenart NotABag Pottering came and brought its democracy to our sinful land ... By default, NoNewPrivileges=false and in php 7.3.11 it is also disabled. In the migration instructions for php 7.4, not a word about the need to coordinate reconfigure the systemd file! I am not saying that NoNewPrivileges=true is not necessary at all. If there is another safe way to solve my problem without turning it off, I will only be glad. But for now I do not know how. I suspect that this could break any call to system(). As for mail() - it was there and remains the standard, basic, recommended way to send mail in php. The only thing it is not suitable for mass mailings, which I know very well. But if calling mail() is not safe this is a php bug. ------------------------------------------------------------------------ [2019-12-06 07:27:19] retertertert at fgfgfg dot com or just don't use mail() - where i work that's a forbidden and disabled function for 20 years now for security reasons and before i remove "NoNewPrivileges=true" for the sake of calling sendmail i commit suicide https://github.com/PHPMailer/PHPMailer ------------------------------------------------------------------------ [2019-12-06 07:18:34] ilya at ilya dot pp dot ua -NoNewPrivileges=true -RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX +RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK Solves my problem. ------------------------------------------------------------------------ [2019-12-05 18:37:03] ilya at ilya dot pp dot ua After -RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX +RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK Error in postfix log: fatal: mail_queue_enter: create file maildrop/508120.1166: no permission warning: command "/usr/sbin/postdrop -r" exited with status 1 fatal: info@gricargo.com(467): unable to execute /usr/sbin/postdrop -r: Success nginx log is empty. What else needs to be changed in this systemd file? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78916 -- Edit this bug report at https://bugs.php.net/bug.php?id=78916&edit=1