People of ACM - Eric Allman
January 9, 2014
Eric Allman developed sendmail and its precursor delivermail in the late 1970s and early 1980s at the University of California, Berkeley. The program was designed to deliver email over the still relatively small ARPANET network, and supports a variety of mail transfer protocols, including SMTP, ESMTP, and DECnet's Mail-11. In 1998, he founded Sendmail, Inc.
He serves on the editorial board of ACM Queue magazine, the ACM Council, and the Board of Trustees for Cal Performances. Previously, he was Vice President and Treasurer of USENIX. He was awarded the Telluride Tech Festival Award of Technology in 2006 in Telluride, Colorado, and in 2009 he was recognized as a Distinguished Engineer by ACM. The University of California, Berkeley named Allman a Distinguished Alumnus in Computer Science in 2013.
Allman co-wrote the O'Reilly book Sendmail with Bryan Costales, and contributed a chapter to The Architecture of Open Source Applications. He frequently speaks and writes about issues relating to email, open source, and the Internet.
Since Sendmail Inc. with its core technology for Internet email, which you developed as an open source project, was recently acquired by Proofpoint, how do you see this technology evolving?
The open source sendmail code is an MTA (Mail Transfer Agent) with a plugin architecture (which sendmail calls "milter," a portmanteau of "mail filter") to allow on-the-fly processing of messages, for example, for spam filtering. Sendmail itself doesn't handle these higher level services. For the most part, development is happening in these milters. Although some new MTA extensions may be necessary, most of the evolution will happen in milters.
As an original member of the ACM Queue Advisory Board, what in your view is the most significant impact of this publication on the computing practitioner community?
Our goal in creating Queue was to fill the gap between the research journals (where ACM is a clear leader) and the trade publications, which are all too often little more than collections of press releases and have their editorial policy influenced by advertisers. We try to cover the technologies that are upcoming but still haven't hit the general consciousness. Also, our independence permits us to question assumptions. Given our strong readership, Queue is succeeding in meeting our goal.
What influence did your early exposure at Berkeley to computing legends like Ken Thompson, Bill Joy, and Eric Schmidt have on your career trajectory?
If you throw in the UNIX operating system, it had almost everything to do with my career trajectory. I consider myself extraordinarily fortunate to have entered Berkeley at the same time as UNIX. Folks like Bill, in particular, encouraged a "get your hands dirty" attitude, which enabled me to learn an immense amount. Bill's work on UNIX must have been part of Ken Thompson's decision to take his sabbatical at Berkeley. While he was there he led an unofficial night class as a guided read through of the 6th Edition kernel. The group was small enough to fit in a tiny classroom. I originally wrote delivermail (the predecessor to sendmail) as a tool to join the Arpanet with BerkNET, which by the way was written by Eric Schmidt, but Bill was the one who encouraged me to make the (quite large) leap to do sendmail, which was needed for the Internet transition; without him I probably wouldn't have done it.
As an accomplished computer practitioner, what advice would you give to young people just getting started in the open source world?
That's hard to answer, because so much depends on your circumstances. Realistically, it's hard to create a project from scratch and have it take off, so it's a good idea to get involved with an existing project that is looking for volunteers. Some projects (FreeBSD comes to mind) have a mentoring program to help teach new people the ropes. Others won't have an official program set up, but I still recommend finding a mentor if possible. I recommend working on something you really care about, something you want to use yourself if possible, because in most cases you aren't being paid. If you're writing code, plan on coding more cleanly than you would for a class or even a paid job. Remember, your reputation is going to be on the line, and open source hackers tend to have a very low tolerance for poorly written, undocumented code. And remember, you don't have to be writing code — most projects have a serious need for people to write documentation, do build engineering, and test the code.
One thing that too often goes unnoticed is what kind of software you want to work on, which generally falls into three classes: code that interfaces directly with end users, usually with a graphical user interface; library and framework code, that needs to be very portable, run in a generalized environment, and will be used by other programmers; and non-interface code such as some command line programs and pretty much all system daemons.
If it's important to you to be able to point to something and say "I wrote that," then the first class may work best for you. Either of the second two requires a very different attitude: if your code is working properly, people will forget that it exists. For example, in addition to sendmail, I wrote syslog, and although pretty much every system supports it now (including things like HP printers), it just kind of disappears into the woodwork to everyone except people trying to debug or monitor some service. Pick a project that matches your personality — if you work on something that doesn't suit you, you're unlikely to do a good job.