Introduction

Security is essential. Security is so important that it is touched upon many times in this book. In fact, several earlier chapters are really about security, such as Chapter 7 and Chapter 8. But even the chapters on relaying and spam control are really chapters about security because theft of service is just as big of a security problem for sendmail as system and data integrity.

A sendmail server requires all of the security precautions used on any networked system, and then some. By its very nature, a sendmail server must accept connections and data from unknown remote hosts , while many other network servers offer their services to a limited set of clients . The system running sendmail must be secured against attack, and the sendmail service must be secured against exploitation. General system security is beyond the scope of this book. For that, use a good security reference, such as Practical UNIX and Internet Security , by Simson Garfinkel and Gene Spafford (O'Reilly), or Computer Security Basics , by Debbie Russell and G.T. Gangemi (O'Reilly). This book focuses on only those things that are specific to sendmail security.

sendmail's file and directory permissions are one area of general system security that is specific to sendmail. All of the directories used for sendmail's administrative files should only be writable by the TrustedUser (usually root ), and all of the parents of those directories back to the root should only be writable by root ” none of those directories should have group or world write permissions. The file permissions used by sendmail are defined by confTEMP_FILE_MODE and confQUEUE_FILE_MODE . Don't change these permissions. sendmail comes with these permission set as tight as possible.

Despite a spotty security reputation, out-of-the-box sendmail uses tight security settings. Take care not to compromise security when configuring sendmail. Some configuration changes reduce security, as explained in Introduction to Chapter 3. For example, the confDONT_BLAME_SENDMAIL define accepts more than 40 arguments that relax sendmail's normally strict security.

On occasion, a sendmail administrator is forced to relax security in order to gain flexibility. Many of the recipes in this chapter take the opposite tack ”increasing security even at the cost of flexibility. You won't see any DontBlameSendmail options used. You will see restrictions of the files sendmail can write and the SMTP commands the server will support ”all done to increase security.

Don't undertake these security recipes lightly. Increasing security at the cost of utility and flexibility should be done only after careful study. Be sure that the cure is not worse than the disease. All sites can benefit from keeping sendmail software updated as described in Recipe 10.3 and Recipe 10.4. Most sites can benefit from limiting the number of systems that accept inbound mail from the network, as described in Recipe 10.1 and Recipe 10.2. Many may benefit from using smrsh , as covered in Recipe 10.6. But some of the recipes in this chapter provide more security than the average site needs, particularly when you consider that the enhanced security comes at the cost of utility. These recipes are not suggesting that you should do such things as disable delivery to files or disable the VRFY command; they are telling you how to do these things if you decide that it is necessary for your system. For most sites, sendmail's standard security is more than adequate.