# ls -ald / /etc /etc/mail /etc/mail/private /etc/mail/private/mailhost.key.pem
drwxr-xr-x 29 root root 4096 Aug 11 09:10 /
drwxr-xr-x 124 root root 12288 Aug 11 12:50 /etc
drwxr-sr-x 10 smmta smmsp 4096 Aug 11 12:52 /etc/mail
drwx------ 2 root smmsp 4096 Aug 11 12:44 /etc/mail/private
-r-------- 1 root smmsp 1679 Jul 7 11:10 /etc/mail/private/mailhost.key.pem
I think the reason it’s not working is sendmail changes it’s effective uid to
smmta or smmsp (depending on whether its an mta or msp).
/etc/mail/private probably should be owned by smmta. And/or group readable and
searchable (g+rx) by group smmsp.
I ran across a similar permissions problem when using certs from
letsencrypt/certbot. I got around it by
1. Adding smmta,smmsp to the ssl-cert group in /etc/group:
ssl-cert:x:114:smmta,smmsp
2. Creating a post-hook script for certbot to run after it renews a cert:
chgrp -R ssl-cert /etc/letsencrypt/archive
find /etc/letsencrypt/archive -name privkey\* -exec chmod o-rw {} \;
# the find is because cerbot seems to create world readable private keys which
sendmail complains about
I started to think that maybe adding something to /usr/share/sendmail/update_mk
which creates /etc/mail/Makefile to do this chown/chmod of /etc/mail/private
and the keys/certs in there. But I don’t have /etc/mail/private on my Debian
install, and don’t see it in any of the packages, did I miss something?
So unless I’ve misunderstood and /etc/mail/private is not part of sendmail,
maybe all you need to do is:
chown -R smmta /etc/mail/private
chmod g+rx /etc/mail/private
chmod g+r /etc/mail/*
This is how I would fix it on my own system, if someone has a better, more
secure solution, I’d love to know it.
Michael Grant
