What is the proper permission configuration of sendmail

Question

This question comes from a problem much similar to this https://serverfault.com/questions/320607/ubuntu-jaunty-sendmail-php-mail-premission-errors

But those answers don't solve my problem

I have a php application which is using PHPMailer to send emails.

I installed sendmail on my ubuntu 12.04 LTS with

sudo apt-get install sendmail
sudo sendmailconfig

But the application failed to send any mail. In the mail.err it says:

Apr 14 00:31:42 AY sendmail[32241]: NOQUEUE: SYSERR(www-data): can not chdir(/var/spool/mqueue-client/): Permission denied

while www-data is the username of apache2.

Then I followed some guides from internet, add www-data to smmsp group:

sudo usermod -a -G smmsp www-data

Now when I

groups www-data

I get

www-data : www-data smmsp

and the line in the /etc/group is:

smmsp:x:114:www-data

Also I made sure of access to /var/spool/mqueue-client/ is 770

/var/spool]$ ls -la
total 28
drwxr-xr-x  7 root   root  4096 Apr  2 00:21 .
drwxr-xr-x 11 root   root  4096 Apr 14 03:30 ..
drwxr-xr-x  5 root   root  4096 Aug  6  2012 cron
lrwxrwxrwx  1 root   root     7 Aug  6  2012 mail -> ../mail
drwxr-s---  2 smmta  smmsp 4096 Apr 14 06:25 mqueue
drwxrws---  2 smmsp  smmsp 4096 Apr 14 06:25 mqueue-client
drwxr-xr-x  2 root   root  4096 Apr 13  2012 plymouth
drwxr-xr-x  2 syslog adm   4096 Mar 31  2012 rsyslog

/]$ ls -ld /var/spool/mqueue-client/ /usr/sbin/sendmail
lrwxrwxrwx 1 root  root    26 Apr  2 00:21 /usr/sbin/sendmail -> /etc/alternatives/sendmail
drwxrws--- 2 smmsp smmsp 4096 Apr 14 06:25 /var/spool/mqueue-client/

But I still get error when I try to send mail

Apr 14 03:26:57 AY sendmail[6131]: NOQUEUE: SYSERR(www-data): can not write to queue directory /var/spool/mqueue-client/ (RunAsGid=33, required=114): Permission denied

while 33 is gid of www-data

www-data:x:33:

What should I do to get sendmail work but keep the security? Further, What is the proper permission configuration (user, group, and directories access etc) of sendmail in a production environment ?

Answer 1

Standard installation of sendmail-8.12+ requires to install sendmail binary as set group id.
(/usr/sbin/sendmail -> ... -> /usr/lib/sm.bin/sendmail in you case)

-rwxr-sr-x 1 root smmsp ...

In case of your softlinks chain try:

 chown root:smmsp /usr/lib/sm.bin/sendmail
 chmod 2555 /usr/lib/sm.bin/sendmail

---

Recommended permissions are described in SECURITY file in sendmail distribution. On my debian the file is installed as /usr/share/doc/sendmail-doc/sendmail/SECURITY.gz by sendmail-doc package.

Answer 2

So-- if you have inherited a system and you want to change the location of /var/spool/mqueue to someplace other than that and when you modify your sendmail.mc and re-make sendmail.cf or edit the sendmail.cf directory and you start sendmail and it complains "Permission denied" and none of the above helps-- try this.

I have gone through all of the above and numerous systems over the years and no matter what the user is, what the setgid is on sendmail, or what the permissions and ownership information is on any directory I still get the error. In every case I found it was something with the existing installed version of sendmail. Even if it is the latest. In every case I was able to overcome the problem by:

1. make a backup of sendmail.mc or sendmail.cf if you do not build from the mc file
2. make a backup of aliases, virtusertable, etc... all of them because sometimes the reinstall over-writes them (it usually saves them, but...)
3. uninstall sendmail (e.g., "yum remove sendmail -y" or "apt remove sendmail -y")
4. reinstall sendmail (e.g., "yum install sendmail sendmail-cf -y" or "apt install sendmail sendmail-cf -y"

The reinstallation seems to fix the issue.

You might need to update /etc/sysconfig/sendmail with location of your sendmail.cf file with the changed QUEUEDIR and then possibly run "journalctl daemon-reload" to fix that, then it should work.

It is some kind of issue with the OEM install version of sendmail such as missing user/group smmsp, etc.... but this is the easiest way to overcome this problem on a modern linux installation.