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.