Sendmail: The Vietnam of Berkeley Unix 63 one. Mail sorta works, most of the time, and given the time I have, that is great. Good Luck. Stephen Silver Writing a mail system that reliably follows protocol is just not all that hard. I don’t understand why, in 20 years, nobody in the Unix world has been able to get it right once. A Harrowing History Date: Tue, 12 Oct 93 10:31:48 -0400 From: dm@hri.com To: UNIX-HATERS Subject: sendmail made simple I was at a talk that had something to do with Unix. Fortunately, I’ve succeeded in repressing all but the speaker’s opening remark: I’m rather surprised that the author of sendmail is still walking around alive. The thing that gets me is that one of the arguments that landed Robert Morris, author of “the Internet Worm” in jail was all the sysadmins’ time his prank cost. Yet the author of sendmail is still walking around free without even a U (for Unixery) branded on his forehead. Sendmail is the standard Unix mailer, and it is likely to remain the stan- dard Unix mailer for many, many years. Although other mailers (such as MMDF and smail) have been written, none of them simultaneously enjoy sendmail’s popularity or widespread animosity. Sendmail was written by Eric Allman at the University of Berkeley in 1983 and was included in the Berkeley 4.2 Unix distribution as BSD’s “internetwork mail router.” The program was developed as a single “crossbar” for interconnecting disparate mail networks. In its first incarnation, sendmail interconnected UUCP, BerkNet and ARPANET (the precursor to Internet) networks. Despite its problems, sendmail was better than the Unix mail program that it replaced: delivermail. In his January 1983 USENIX paper, Allman defined eight goals for send- mail: 1. Sendmail had to be compatible with existing mail programs.

64 Mail 2. Sendmail had to be reliable, never losing a mail message. 3. Existing software had to do the actual message delivery if at all possible. 4. Sendmail had to work in both simple and extremely complex environments. 5. Sendmail’s configuration could not be compiled into the program, but had to be read at startup. 6. Sendmail had to let various groups maintain their own mailing lists and let individuals specify their own mail forwarding, without having individuals or groups modify the system alias file. 7. Each user had to be able to specify that a program should be executed to process incoming mail (so that users could run “vacation” programs). 8. Network traffic had to be minimized by batching addresses to a single host when at all possible. (An unstated goal in Allman’s 1983 paper was that sendmail also had to implement the ARPANET’s nascent SMTP (Simple Mail Transport Proto- col) in order to satisfy the generals who were funding Unix development at Berkeley.) Sendmail was built while the Internet mail handling systems were in flux. As a result, it had to be programmable so that it could handle any possible changes in the standards. Delve into the mysteries of sendmail’s unread- able sendmail.cf files and you’ll discover ways of rewiring sendmail’s insides so that “@#$@$^%@#) at @$%#^!” is a valid e-mail address. That was great in 1985. In 1994, the Internet mail standards have been decided upon and such flexibility is no longer needed. Nevertheless, all of sendmail’s rope is still there, ready to make a hangman’s knot, should any- one have a sudden urge. Sendmail is one of those clever programs that performs a variety of differ- ent functions depending on what name you use to invoke it. Sometimes it’s the good ol’ sendmail other times it is the mail queue viewing program or the aliases database-builder. “Sendmail Revisited” admits that bundling so much functionality into a single program was probably a mistake: certainly the SMTP server, mail queue handler, and alias database management sys- tem should have been handled by different programs (no doubt carrying through on the Unix “tools” philosophy). Instead we have sendmail, which continues to grow beyond all expectations.