The sendmail program can be an open door to abuse. Unless the administrator is careful, the misuse or misconfiguration of sendmail can lead to an insecure and possibly compromised system. Since sendmail is usually installed to run as an suid root process, it is a prime target for intrusion. The "Internet worm," for example, used a flaw in old versions of sendmail as one way to gain entry to thousands of machines.  If sendmail is not properly installed, external probes over networks can be used to gain information that is valuable in attempting entry. Once inside, improper file permissions can be used to trick sendmail into giving away root privilege. Even email cannot be trusted, and forged email can cause some users to give away their passwords.
In this chapter we present several ways to protect your site from intrusion via sendmail . Most are just good common sense, and the experienced system administrator may be offended that we state the obvious. But not all system administrators are experienced, and not all who administer systems are system administrators. If you fall into the latter category, you may wish to keep keep a good, general UNIX reference by your side to better appreciate our suggestions.
One common complaint about sendmail centers on the fact that it must usually be run suid root (that is, run as root no matter who actually runs it).  But for the most part it is necessary for sendmail to run as root to satisfy the legitimate needs of users. Consider the following:
Some folks have been tempted to run sendmail as an untrusted pseudo-user (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. 
Clearly, many of sendmail 's duties require it to run as root . As a corollary, however, whenever sendmail does not need to be root , it should become the appropriate nonprivileged user. It does this by using the following bit of logic:
Note that setreuid (3) is preferred over seteuid (3)  and setuid (3) because it allows sendmail to temporarily give away both its real and effective root privilege, then to get it back again. To illustrate the need for this behavior, consider processing a mailing list that saves mail to two different files:
/u/bill/archive owned by the user bill, mode 4600 /u/alice/archive owned by the user alice, mode 4600
Further consider that these files both have permissions of suid to the individual users  and are writable only by the individual users. To perform delivery in this instance, sendmail must  first become bill (this requires root privilege to do). When it is done, sendmail must become root again so that it can next become alice . By retaining a real uid of root (with the seteuid (3) routine), sendmail is able to change its effective uid back and forth between users and root as needed.
See the description of the test directory in Section 18.8.55 for more on this subject.