Bug 186917

Looks like it was the patch for sendmail security bug (RHSA-2006:0264-8  
Critical: sendmail security update) that caused this.  One system did not
download this update and /bin/mail on this host is still functioning normally.

This problem also affects FC4 (both i686 and x86_64) and FC5t3 boxes.

I was invited to this bug report but I can't reproduce it anywhere on my testing
machines with standard sendmail and mailx configuration. CC'ing sendmail
maintainer, he might know if this is a regression or some unhealthy setting.

Hmm, I was able to produce very similar error by removing setgid bit from
/usr/sbin/sendmail.sendmail and adding access to /var/spool/clientmqueue for
others, which definitely isn't a sane configuration. Then, if and only if I run
the command as non-root I get:

$ mail root < /etc/motd
$ WARNING: RunAsUser for MSP ignored, check group ids (egid=100, want=51)
can not write to queue directory /var/spool/clientmqueue/ (RunAsGid=100,
required=51): Permission denied

Though the difference between this and your output is that the numbers in the
second parentheses are RunAsGid = GID of the user running mail(1) and required =
GID of smmsp, while in your case RunAsGid = root's GID and required = 25,
apparently GID of user running mail(1).

Bevis, could you check permissions and ownership of /usr/sbin/sendmail.sendmail
and /var/spool/clientmqueue anyway, please?

A colleague writes:
Finally got a chance for a quick look at this and I think it is still a
perms problem caused by the difference in the smmsp NIS entry in passwd
and group and the local /etc/passwd,group files.

Here is some stuff from one of the failing servers. Note this server is running
with uid 51 and group 51 which is local passwd ids. Ls lists the sendmail and the
clientmqueue as smmsp but using ls -ln - we can see that the
clientmqueue is really 25 group.

- So the issue basically seems to be that this update has caused our mail system
GIDs from the NIS no longer work wnen they did previously.  This has killed
almost all email service on most of our machines, so it's really bad news
operationally.

Results:
-rwxr-sr-x  1 root smmsp 733912 Mar 20 11:57 /usr/sbin/sendmail.sendmail
-rwxr-sr-x  1 0 25 733912 Mar 20 11:57 /usr/sbin/sendmail.sendmail

and:
drwxrwx---  2 smmsp smmsp 4096 Mar 20 11:57 /var/spool/clientmqueue
drwxrwx---  2 51 25 4096 Mar 20 11:57 /var/spool/clientmqueue

More comments from our local discussion which are pertinent:
OK, hold on the remove the NIS smmsp as that is the normal default for
sendmail and is the account used by solaris sendmail - why is
the local passwd/group on RHEL 51?

I've temporarily fixed the server we were testing with 

chgrp 51 /var/spool/clientmqueue
chmod g+s /usr/lib/sendmail

as Simon had done on SuSE. This sets it correctly. The question is which is
easier to change, RHEL local passwd group from 51 to 25 or solaris/CSW
from 25 to 51 OR move solaris ids to local files and remove smmsp from
nis.

---- 
I would imagine other people with both Solaris and RHEL4 boxes running from the
same NIS could be in trouble with this.

Reassigning to sendmail, then.

As for eventual changes in UIDs/GIDs in RHEL, GID 25 is already reserved for
bind (see /usr/share/doc/setup-2.5.37/uidgid).

I am sorry, but I can not change the uid or gid for smmsp in RHEL.

Closing as "not a bug".