Eric Allman Speaks

Eric Allman Speaks

I have to admit that I'm surprised by how well sendmail has succeeded. It's not because of a large marketing organization or a deep-pockets budget. I think there are three reasons.

First, sendmail took the approach that it should try to accept, clean up, and deliver even very "crufty" messages instead of rejecting them because they didn't meet some protocol. I felt this was important because I was trying to gateway UUCP to the ARPAnet. At the time, the ARPAnet was small, UUCP was anarchy , and Unix mail programs generally didn't even understand headers. It was harder to do, but after all, the goal was to communicate, not to be pedantic.

Second, I limited myself to the routing function ”I wouldn't write user agents or delivery back-ends. This was a departure from the dominant thought of the time, in which routing logic, local delivery, and often the network code were incorporated directly into the user agents. But it did let people incorporate their new networks quickly.

Third, the sendmail configuration file was flexible enough to adapt to a rapidly changing world: the 1980s saw the proliferation of new protocols, networks, and user agents.

And, of course, it didn't hurt that it was free, available at the right time, and did what needed to be done.

Configuring sendmail is complex because the world is complex. It is dynamic because the world is dynamic. Someday sendmail , like X11, will die ”but I'm not holding my breath . In the meantime, perhaps this book will help.

When I started reviewing Bryan's first-edition manuscript, I had been avoiding any major work on sendmail . But then I started reading about various petty bugs and annoyances that all seemed easy to fix. So I started making small fixes, then larger ones; then I went through RFC1123 to bring the specs up-to-date, cleaned up a bunch of 8-bit problems, and added ESMTP. It would be fair to say that the first book and sendmail Version 8 fed on each other ”each improving the other.

Organization

We've divided this book into one introduction and four parts , each addressing a particular aspect of sendmail .

Chapter 1 will be of special help to the new user . It covers the basic concepts underlying mail delivery and the roles sendmail plays in that delivery.

Part I covers compilation, installation, and configuration of sendmail , and the other programs supplied with the sendmail source.

Part II for more experienced users, covers general administration, including performance tuning, handling spam, rule testing, and more.

Part III covers all aspects of the configuration file in detail, and includes complete reference sections.

Part IV contains the appendices.

Audience and Assumptions

This book is primarily intended for system administrators who also administer email. But not all Unix systems are managed by administrators. Many are managed by programmers, network engineers , and even inexperienced users. It is our hope that this book satisfies all of you, no matter what your level of experience.

The true beginner should begin with Part I, skipping ahead as needed.

The beginning system administrator should probably start with Part I to learn how to build and install sendmail , then read Part II for help in understanding how to administer sendmail . Note that Part II and Part III will reveal answers to many nagging questions that seem to be otherwise unanswered.

The experienced system administrator who wants to install and manage V8 sendmail should read Part I and Part II first to gain the needed background. Then read Part III.

Unix gurus and sendmail specialists should find Part III to be of value (even Eric keeps a copy on his desk). In it, every arcane detail of sendmail is listed alphabetically . For example, in Part III you'll find a single chapter dedicated to options, with every option listed and explained.

No matter what your level of expertise, the sheer size of this book forces us to assume that you are familiar with the day-to-day system workings of Unix. If you aren't, you must learn Unix elsewhere.