One common complaint about sendmail centers on the fact that it is often run, set-user-id root (that is, run as root no matter who actually runs it). Beginning with V8.12, the default is to run sendmail as a user other than root. The listening daemon needs to be root, but sendmail itself no longer needs to be set-user-id root.
For the most part, it is necessary for sendmail to run as root to satisfy legitimate needs. Consider the following:
Users want ~/.forward files to work even when their home directory is set to mode 700. The sendmail program requires root privilege so that it can temporarily become the user to read and process the ~/.forward file.
Users want :include: mailing-list files readable only by themselves and sendmail. The sendmail program requires root privilege so that it can temporarily become the owner of the list.
Users want programs that run on their behalf to run as themselves. This requires root privileges, and running as anything else would be potentially very dangerous.
Users want sendmail to listen on TCP/IP ports that are common (ports 25 and 587). The sendmail program requires root privilege so that it can initiate listening connections to privileged ports.
Some folks have been tempted to run sendmail as an untrusted pseudouser (such as nobody). But this doesn’t really work. For example, it causes programs in users’ ~/.forward files to be run as nobody, and it requires the queue to be owned by nobody. Consequently, such a scheme allows any user to break into and modify the queue.
 ‡ Contrary to popular belief, sendmail does not run as root to handle local delivery (except that sendmail can deliver directly to files when necessary, but that is not directly germane to this discussion). Local delivery is handled by delivery agents (such as /bin/mail), which may run set-user-id root themselves (or set-group-id mail as in SysV).
 * But note that V8.8 sendmail has loosened the latter for use on firewall machines, where it won’t complain about non-root qf files if it is not running as root.