The Technical Development of

Craig Partridge BBN Technologies

Development and evolution of the technologies and standards for Internet email took more than 20 years, and arguably is still under way. The protocols to move email between systems and the rules for formatting messages have evolved, and been largely replaced at least once. This article traces that evolution, with a focus on why things look as they do today.

The explosive development of networked Each subsystem internally has a rich set of electronic (email) has been one of the protocols and services to perform its job. For major technical and sociological develop- instance, the UA typically includes network ments of the past 40 years. A number of protocols to manage mailboxes kept on remote authors have already looked at the develop- storage at a user’s Internet service provider or ment of email from various perspectives.1 The place of work. The MHS includes protocols to goal of this article is to explore a perspective reliably move email messages from one MTA to that, surprisingly, has not been thoroughly another, and to determine how to route a examined: namely, how the details of the message through the MTAs to its recipients. technology that implements email in the TheUAandMHSmustalsohavesome Internet have evolved. standards in common. In particular, they need This is a detailed ’s plumb- to agree on the format of email messages and ing. One might imagine, therefore, that it is the format of the metadata (the so-called only of interest to a plumber. It turns out, envelope) that accompanies each message on however, that much of how email has evolved its path through the network. has depended on seemingly obscure decisions. The focus of this article is how these Writing this article has been a reminder of different pieces incrementally came into being how little decisions have big consequences, and exploring why each one emerged and how and I have sought to highlight those decisions its emergence affected the larger email system. in the narrative. In the interests of space, this survey stops around the end of 1991. That termination date Architecture of email leaves out at least four stories: (1) the develop- In telling the story of how email came to ment of graphics-based user interfaces for look as it does today, we start by describing (in personal computers and the incorporation of broad strokes) today’s world, so that the steps those interfaces into web browsers; (2) the rise in the evolution can be marked more clearly. of UA protocols such as the Today’s email system can be divided into (POP)2 and IMAP3 (these protocols existed two distinct subsystems. One subsystem, the prior to 1991, but much of their evolution message handling system (MHS), is responsible occurred later); (3) the continuing efforts to for moving email messages from sending users further internationalize email (e.g., allowing to receiving users, and is built on a set of non-ASCI characters in email addresses); and servers called message transfer agents (MTAs). (4) the rise of unwanted email (dubbed The other subsystem, which we will call the ‘‘spam’’) and tools that sought to diminish it. user agent (UA), works with the user to receive, Furthermore, in the interests of space, I do not manage (e.g., delete, archive, or print), and consider the development of technical stan- create email messages, and interacts with the dards for the support of email lists. MHS to cause messages to be delivered. Readers may recognize this terminology as First steps being roughly that developed by the X.400 Electronic mail existed before networks did. email standardization process. In the 1960s, time-shared operating systems

IEEE Annals of the History of Computing Published by the IEEE Computer Society 1058-6180/08/$25.00 G 2008 IEEE 3 The Technical Development of Internet Email

developed local email systems delivering mail had received local email. In TENEX, they got a between users on a single system.4 The ‘‘You have mail’’ message when they logged importance of this work is that email requires in. Mail was read by viewing or printing the a certain amount of local infrastructure. There file, usually with the TYPE command. needs to be a place to put each user’s email. (Almost immediately, TYPE MAILBOX was There needs to be a way for a user to discover replaced with a TENEX macro READMAIL). that he or she has new email. By the early Messages were deleted by deleting the relevant 1970s, many operating systems had these lines with a text editor. facilities. Tomlinson made two important contribu- In July 1971, Dick Watson of SRI Interna- tions. First, he found a way to express the tional published an Internet Request for networked email address. He chose to use the Comments5 (RFC-196) describing what he ‘‘@’’ sign to divide the user’s account name called ‘‘A Mail Box Protocol.’’ The idea was to from the name of the host where the account provide a mechanism where the new Network resided, resulting in the now ubiquitous 11 Information Center (NIC) could distributed user@remote format. Second, SNDMSG was the documents to sites on the Arpanet. Watson first MTA—it took a message and delivered it described a way to send files (documents) to a (using the CPYnet protocol) to a remote user’s teletype printer, with different mailboxes for mailbox. different types of printers. Mailbox 0 was a Observe that the last contribution is a teletype surprise. We might imagine that the first program was more of a user agent (UA) than assumed to have a print line 72 characters a message transfer agent (MTA). But SNDMSG wide, and a page of 66 lines. The new line could only deliver mail, it could not receive convention will be carriage return (X90D9) mail, and it delivered the email all the way to followed by line feed (X90A9) … The standard the recipient’s mailbox. Therefore, SNDMSG was printer will accept form feed (X90C9)as much closer in spirit to an MTA (and, indeed, meaning move paper to the top of a new as we shall see, was used as an MTA for a page.6 number of years). At the same time, SNDMSG was primitive. If there were multiple email of Bolt Beranek and New- recipients on the same host, it copied the man (now BBN Technologies or BBN) read message once for each recipient. If the remote Watson’s memo and reacted that ‘‘it was host was down, SNDMSG simply returned a overly complicated because it tried to deal failure message—it made no effort to retrans- with printing ink on paper with a line printer mit. and delivered the paper to numbered mail- Despite its primitive nature, Tomlinson’s 7 boxes.’’ In Tomlinson’s view, the correct creation took off. The next few years saw it approach was to send documents to a user’s mature from a fun idea to a central feature of electronic mailbox and let the user decide if the Arpanet (and later the Internet). the document merited printing.8 So Tomlin- son set out to see if he could send email this From primitive to production 9 way between two TENEX systems over the By late 1973, email was widely used on the Arpanet. His approach was simple. Arpanet. What happened after Tomlinson’s TENEX already had an existing local email experiment to make this happen? Obviously, 10 program called SNDMSG, which, given a mes- email met a need. But there were also technical sage, appended that message to a file called steps: standardization of the transfer protocol MAILBOX in a user’s directory. TENEX also had a and the development of user interfaces. homegrown file transfer service called CPYnet (written by Tomlinson). In a passive mode, A standard transfer protocol CPYnet listened at a particular address for First, the community replaced CPYnet with requests to read, write, or append to a particular a standardized file transfer service, the first local file. Email was achieved by incorporating generation of the File Transfer Protocol (FTP). CPYnet into SNDMSG.IfSNDMSG was given a This process took a while. In 1971, FTP was message addressed to a user at a remote host, it simply a set of rather complex ideas written up opened a CPYnet connection to the remote in a set of RFCs by a team led by Abhay host and instructed CPYnet to append the Bhushan of the Massachusetts Institute of message to the user’s mailbox on that host. Technology (MIT).12 The goal behind these Users learned that they had received net- ideas was to create a general tool to manage work email the same way they learned they files (including deleting and renaming files) on

4 IEEE Annals of the History of Computing remote machines and to do it in a way that name (local to the remote host). The user id met the needs of any envisioned application.13 could also be left out, in which case the mail At the same time, Dick Watson’s mailbox was to be delivered to a printer. After the MLFL idea was continuing to mature. In November command was accepted, the email file was 1971, a team including Watson proposed a transmitted over an FTP data channel (with way to enhance (the still nascent) FTP with the end of the file indicating the end of the an explicit MAIL command to support message). The file was required to be in ASCII. appending a file to a mailbox. They further A separate copy of the file was sent for each proposed that email be simply ASCII strings recipient at a host. of text (no binary images) and that mailbox MLFL was an important step. A key flaw in numbers be replaced with text user identi- Tomlinson’s prototype email was that you had fiers. The identifiers were ‘‘NIC handles.’’ NIC to know where in the receiving host’s file handles were given out by the Network system a user’s mailbox was located, so that Information Center to authorized network you could append to it.18 This limitation users (and were used as login IDs on Arpanet probably explains why most of the email terminal servers, called TIPS). This idea, of activity in 1971 and 1972 appears to have course, meant that every host would need to taken place between TENEX systems, where the maintain a table mapping NIC handles of file name for the mailbox was consistent. local users to the location of their mailbox MLFL adopted Watson’s notion that mailbox- file. Retaining Watson’s original idea of acc- es are symbolic names that the receiving essing a printer, the MAIL command could be system translates into an appropriate user given the name ‘‘Printer’’ instead of a NIC mailbox file and thereby freed email from handle and the file would be printed. system-specific limitations. Concurrently, Tomlinson distributed An interactive command, MAIL, was also SNDMSG to other TENEX systems and people defined, so that users logged into a TIP could began to get hands-on experience with email. type in an email message using only FTP’s TENEX was the most common operating system control connection. In this case, a line with a on the Arpanet at the time, and so probably at single dot (‘‘.’’) on it marked the end of the least half the Arpanet users had access to message. Ending a message with a single dot is SNDMSG. still how email is moved over the Internet today. In April 1972, most of the interested parties, The MAIL—and, more important, MLFL— including both Tomlinson and Watson, met at commands remained the way email was MIT to discuss revisions to the File Transfer delivered between systems for several years. Protocol. The meeting made several decisions, In the fall of 1972, Bob Clements of BBN at least one of which proved to have a long- updated SNDMSG to use the new commands. term impact: the group agreed to use text Several other email-cognizant FTP implemen- (ASCII) commands and replies (previous ver- tations appeared. The most notable is probably sions of FTP had used binary commands) to aid the system for MIT’s . Ken Pogran interactive use.14 To this day, the Internet uses wrote the FTP implementation and Mike text commands to transfer email (and the Padlipsky wrote the NETML program that tradition lives on in much later protocols, such handled email.19 Multics was exceptional for as the Web’s transfer protocol, HTTP). A new the time because it had good security includ- version of the FTP specification, based on these ing user file privileges, so Padlipsky had to ideas and written by Bhushan, came out in invent a special user (ANONYMOUS) to receive July 1972.15 email and distribute it to users.20 The concept The new specification envisioned that email of an anonymous login account caught on as a would be delivered via the APPEND command, way to permit FTP access to users who did not which appended data to a file. Discussions have an account and remains a central feature about FTP and email continued, however, and of FTP to this day. a month later, Bhushan issued a revision to the FTP specification16 to include a new com- First user agents mand, MLFL (Mail File). It is said Bhushan The second development of 1972 and 1973 came up with MLFL because, one evening was the creation of tools to create and manage whilehewaswritingtherevision,afellow email. Here the center of innovation was graduate student at MIT stopped by to suggest within the Advanced Research Projects Agency that a better solution was required for email.17 (ARPA) itself. Larry Roberts, head of the ARPA MLFL took one argument, a user id, which office funding Arpanet, was an early and could either be a NIC handle or a local user aggressive user of email. Early in 1972, Stephen

April–June 2008 5 The Technical Development of Internet Email

Lukasik, the head of ARPA, also began using email and that induced a number of others, including the ARPA department heads, to use One challenge in RD and email too.21 Soon Lukasik became frustrated with READ- NRD was the lack of a MAIL, which forced him to read through all the messages in his mailbox in order. Lukasik standard format for email liked to keep copies of email he received, which made the problem worse. He appealed messages. Headers varied. to Roberts for something better. One night in July, Roberts wrote a tool It was hard to find where using macros for the TECO (Text Editor and COrrector22) text editor to manage a mail- one message ended and box.23 The tool was dubbed RD. RD made it possible to list the messages in the mailbox, to the next one started. pick which message to read next, and to print individual messages. Roberts’ colleague at ARPA, Barry Wessler, Headers varied. It was hard to find where one promptly rewrote RD as a standalone program message ended and the next one started. in the programming language SAIL and added Wessler remembers trying to get NRD to find additional features for usability. Improve- the start of headers, but it was too hard because ments in Wessler’s ‘‘New RD’’ or NRD included messages routinely had other messages em- the ability to manage more than one file of bedded in them. Therefore, NRD (and RD and messages, and mechanisms to file, retrieve, BANANARD) relied on the receiving system to and delete messages. RD and NRD were the place a start-of-message delimiter before each first mailbox management tools, the first true message in the mailbox.26 The delimiter had user agents. four SOH (Start Of Header, also known as Wessler’s NRD was not distributed outside Control-A) bytes followed by information ARPA. (RD was.) In early 1973, Martin Yonke about the message (initially just a byte count, was a graduate student intern at the University 27 of Southern ’s Information Sciences later somewhat more information). In one of Institute (ISI) and looking for something to do. those odd quirks, part of the start-of-message of ARPA gave Yonke a copy of delimiter has lived on. While some present- day email systems parse for a header, others Wessler’s code (which ran on TENEX)and suggested Yonke look at improving it. Yonke still expect messages separated by a line with added command completion (type the first four consecutive SOH bytes. letter or two of a command and the rest of the name would be filled in) and a help interface. Transitions A user could type a question mark in most In March 1973, another meeting of people places in a command to learn what the choices working on FTP was held, to try to clarify issues 24 were. The revised NRD was dubbed BANANARD. lingering from the April 1972 meeting. It (At the time, ‘‘banana’’ was technical slang for marked a subtle transition. ‘‘cool’’ or ‘‘better’’.) Yonke distributed and Originally, clarifying and improving the maintained BANANARD for a bit less than a year support for email in FTP was part of the 28 although it remained in use for several years agenda. Yet the meeting was ambivalent more. about the relationship between FTP and email. Among the amusing stories from that year, Prodded by a late-in-the-meeting arrival of one concerned mailbox sizes: BANANARD kept an ARPA’s Steve Crocker, who asked how they index of messages in a file, so Yonke had to were doing on email support, the group estimate how big the index (which was read decided to formally incorporate the MLFL into memory) might be. Yonke estimated the and MAIL commands into the new specifica- largest possible mailbox size, doubled that, tion29 (recall that the commands had previ- and concluded that assuming a mailbox was ously been in a separate addendum). Between never larger than 5,000 messages was safe. the meeting and the issuances of the new FTP Within a few months, Steve Crocker exceeded specification, it was decided that email should the limit. So did John Vittal.25 really be a separate, auxiliary protocol.30 Email One challenge in RD and NRD was the lack had become important (or complex) enough of a standard format for email messages. to merit distinction.

6 IEEE Annals of the History of Computing Second, the community was shifting. Al- nights and weekends), and when he left ISI for though both meetings had over 20 attendees, BBN in 1976, he took MSG with him. they were different sets of people. Only five MSG was, in fact, surprisingly simple. It was people31 attended both meetings.32 Abhay a stand-alone program with its own set of Bhushan, who had been driving the develop- commands. There were just 30 commands, ment of and writing the specifications for FTP, named such that their first letter uniquely would soon move on to other things. Nancy identified all but six. Combined with a Neigus of BBN wrote the new FTP specifica- command-completion scheme, this usually- tion. unique-on-first letter approach permitted con- The research focus was also changing. By cise typing by experienced users. (Many early year’s end, Larry Roberts (probably email’s computer users were hunt-and-peck typists, so most important early adopter) would leave keeping commands to a letter or two in length ARPA, and under his successor, , was a big time-saver.) ARPA’s networking focus would change to Of these 30 commands, several were new developing networks over media other than from BANANARD.Somewereminor,suchasa telephone wires (e.g., satellites and radios) and command to toggle the user interface between the problems of interconnecting those net- a concise and a verbose mode. However, three works. commands reflect important changes: Finally, at least from a standards perspec- tive, the protocol for delivering email enters a N Move reflected Vittal’s attention to user kind of limbo. The auxiliary protocol specifi- behavior. He noticed that one of the most cation for email envisioned in the new FTP common activities was to save a message in specification never appeared. After three years, a file and then delete the message from the wrote a two-page memo that never inbound mailbox. Vittal created the com- appeared online, documenting the, by then bined Save/Delete command, Move. well-established, practice of using MAIL and N Answer (now usually called ‘‘reply’’) is MLFL. The memo suggests some sites had not widely held to be Vittal’s most insightful bothered to update their FTP from before the and important invention. Answer exam- 1973 FTP meeting.33 There were multiple ined a received message to determine to attempts to allow FTP to send a single copy whom a reply should be sent, then placed of a message to multiple recipients. All of them these addresses, along with a copy of the 34 apparently failed. It would take seven years original SUBJECT field, in a responding from the FTP meeting before the community message. Among the challenges Vittal had seriously returned to the problems of a new to solve were the varying email-addressing email protocol.35 Innovation over the next few standards and what options to give a user years would come from user agents and a long- (reply to everyone? reply only to the sender running debate over the format of email of the note?). It took three implementa- messages, especially email headers. tions to get right.36 N The wonder of Answer is that it suddenly Rise of the user agent made replying to email easy. Rather than In early 1974, John Vittal worked in the manually copying the addresses, the user office next door to Martin Yonke’s office at ISI. could just type Answer and Reply. Users at Vittal had helped Yonke with BANANARD,and the time remember the creation of Answer about the time Yonke stopped working on as transforming—converting email from a BANANARD so he could finish his graduate system of receiving memos into a system degree, Vittal took a copy of the code and for conversation. (There are anecdotal began to think about building an improved reports that email traffic grew sharply user agent. shortly after Answer appeared.37) N Forward provided the mechanism to send MSG an email message to a person who was not Vittal called his new program MSG. In it already a recipient. How much of an he sought to write a user agent that was simple innovation Forward was is unclear. Barry yet did all the things a user needed it to do. It Wessler had to struggle with messages had roughly the same functionality as BANA- embedded in messages in NRD. But the NARD, but the structure of its commands reflect- formalization of the idea was new. ed feedback Vittal sought out from users about how they wanted to manage their email. MSG MSG became the Arpanet’s most popular user was a personal effort by Vittal (writing code on agent and remained so for several years.

April–June 2008 7 The Technical Development of Internet Email

Hermes and MH MS was a user agent for the operating About the same time Vittal was starting system (apparently the first Unix user agent). work on MSG, Steve Walker at ARPA created a MS was funded by Steve Walker at ARPA and new committee called the ‘‘Message Services was created by William Crosby, Steven Tepper, Committee,’’ charged with thinking about and Dave Crocker.42 MS’s defining character- email issues. Its focus was on user agents (Al istic appears to have been that it supported Vezza of MIT remembers a push to get user multiple user interfaces, including one that agents to support command completion) and sought to mimic a Unix command shell and email headers. In the summer of 1975, Walker another that mimicked MSG. also created the MsgGroup mailing list, to Soon after MS was working in 1977, Stock encourage greater discussion.38 Gaines and Norm Shapiro of RAND wrote an Motivating these efforts was an ARPA internal memo suggesting that MS was incon- program called the Military Message Experi- sistent with the style of other Unix pro- ment (MME) to make email into a useful grams.43 Unix encouraged the use of many service to the military. As part of this program, small programs, each of which did something between 1975 and 1979, ISI, BBN, and MIT (in well and creating metaprograms by combining an advisory role) sought to create user agents the small programs together using a mecha- designed for the needs of the military. The nism called ‘‘pipes.’’44 Gaines and Shapiro initial goal was a system for personnel at the suggested the same approach for email: a set office of the Navy Commander in Chief for the of small programs that managed email, where 39 Pacific (CINCPAC). In a related effort, RAND email messages were stored as separate files in Corporation was funded to develop a Unix a user’s directory. email user agent.40 Two years after the memo, a new RAND Hermes (a BBN project) and MH (at RAND) employee, Bruce Bordon, was assigned to were products of this program. Another sys- upgrade MS. He recommended to his manage- tem, called SIGMA, was developed by ISI for ment that rather than upgrade MS, he should CINCPAC but never used elsewhere. They illus- implement Gaines and Shapiro’s idea. The trate some of the diversity of user agents of the result was MH. time. (An interesting side note is that John ThevirtueofMHisthatitmakesemailpart Vittal worked on both SIGMA and Hermes, of the user’s larger environment.45 Output of while continuing his work on MSG. So Vittal’s email display programs can be filtered through personal project was competing with the in- search programs such as grep or simply sent to house official product. At both ISI and BBN, the printing program. MH, in some ways MSG won.) anticipated today’s world, where clicking on Hermes was designed for an office (or an attachment opens the correct program. command) environment where much of the Culturally, in Unix, rather than clicking on an email received was kept for reference. It attachment, one pipes data from one program contained a sophisticated set of mechanisms to the next to produce the desired result. for filing and searching for messages, including Because MH puts every message in a a database that recorded key fields from each separate file in a folder (directory), it is easy message to make searches fast. Hermes also to manipulate both individual messages and provided a high degree of customization. folders. Accordingly, MH (unlike MS46)has Readers could create a template of how powerful tools to sort folders and to search, messages should be displayed, how they should mark, and label messages. be printed, and even how they should be Through most of the 1980s, MH was created (what fields a user should be prompted maintained by Marshall Rose, with help from for). To support this customization, Hermes a number of people, most notably John had a per-user configuration file (called a Romine, Jerry Sweet, and .47 profile) remembered as having been large and Others have picked up the task since and MH complex, though documentation suggests it (much evolved in its code, but still recogniz- was far simpler than the MH profile file became able as Bordon’s suite of programs) continues by the mid-1980s.41 Initially known as the to be widely used today. MAILSYS project, the Hermes team at various times included Jerry Burchfiel, Ted Meyer, Message formats and headers Austin Henderson, Doug Dodds, Debbie When Ray Tomlinson sent his email be- Deutsch, Charlotte Mooers, and John Vittal. tween TENEX systems, he used a format similar MH (‘‘Mail Handler’’) was the successor and to a business memo. But there was no standard response to an earlier RAND system, called MS. format for email messages and creating and

8 IEEE Annals of the History of Computing revising standards for email message formats line)? Or was it ‘‘PDL@MIT-DMS’’ (picking up would consume a tremendous amount of the host from the ‘‘From: JFH@MIT-DMS’’ effort over the next several years. elsewhere in the header)? Various mail programs adopted different such ‘‘abbreviations’’ which drove me crazy. First message format standard … To handle all of this protocol chaos, I wrote Abhay Bhushan, Ken Pogran, Ray Tom- (and rewrote, and tweaked) a sizable (for a linson, and Jim White (of SRI) took the first LISPish world) chunk of code to try to deduce step to standardize email headers in RFC-561, the precise meaning of each message header published in September 1973.48 Their proposal contents and semantics based on where the was mild. Every email message should have message came from. Different mail programs three fields (FROM,SUBJECT, and DATE)atthe had different ideas about the interpretation of start. Additional fields were permitted, one per fields in the headers. line, with each line starting with a single word That code first tried to figure out where an (no spaces) followed by a colon (:). The end of incoming message had come from. This was not so obvious as it might seem because of this header section was marked by a single redistribution and forwarding of messages, blank line, after which came the contents of and differences in behavior of various versions the message. of the other guy’s software. So it wasn’t The proposed standard was forward looking enough to just look to see if you were talking even as it lacked some basic features. The to MIT-MULTICS. I remember having condi- ability to make any word into a header field tional clauses that in essence said ‘‘If I see a was progressive and left plenty of room for pattern like such-and-such in the headers, this experimentation. The date field was surpris- is probably a message from version xx.yy of ingly precise, specifying the time to the Ken Pogran’s Multics mailer.’’ With enough such tests, it formed an opinion about which minute and the time zone. The blank line mail daemon it was talking with, and which after the header remains a feature of email mail UI program had created a message. today. Yet there was no TO field, so a recipient Having hopefully figured out the other wouldn’t necessarily know who else was to guy’s genealogy (and therefore protocol dia- receive the message, and, while use of the @ lect), the code then acted based on a painfully sign was already common, the address format collected set of observations about how that required using the word ‘‘at,’’ as in TOMLIN- system behaved.52 SON AT BBN-TENEX, with the odd conse- quence that for several years, people would RFC-680 is notable for documenting the send using ‘‘at’’ in the FROM (and soon, increase in header fields that had taken place TO) field and yet within the message itself list over two years. It defined a number of widely their email address with an ‘‘@.’’ used but not standardized header fields, including most notably, the TO field, but also Partial progress CC (carbon copy), BCC (blind carbon copy), IN- In 1975, a team of people working on email REPLY-TO,SENDER, and MESSAGE-ID. Introduction systems at BBN sought to update RFC-561 with of the TO field meant a format needed to be RFC-680.49 The work was produced under the chosen for sending to multiple recipients. The auspices of ARPA’s Message Services Commit- proposal called for multiple email addresses in tee.50 The RFC authors were Ted Meyer and a field separated by commas. The RFC also Austin Henderson, but email on the documented the use of @ instead of ‘‘at.’’ MsgGroup mailing list suggests Charlotte RFC-680 was a clear step forward from RFC- Mooers51 also played a major role. RFC-680 561. Still, RFC-680 had limitations. It was set out to document a large number of fields, based on practices on TENEX systems, which many of which were already in widespread but were not always representative of the Arpanet informal use, and to standardize their formats community as a whole. (For example, the in a way that computer programs (e.g., user decision to separate addresses in the TO field agents) could easily parse. with commas was a TENEX convention.) Its That the header standard needed updating syntax had bugs (it unintentionally permitted was becoming increasingly clear. Jack Haverty ‘‘@’’ and comma in mailbox names). Further- offered the following example from his time more, pragmatically, RFC-680, while intended maintaining the MIT-ITS mailer. to become a standard, was never officially issued as a standard.53 [A] field like ‘‘To: PDL, Cerf@ISIA’’ was In addition, RFC-680 revealed a philosoph- ambiguous was ‘‘PDL’’ really ‘‘PDL@ISIA’’ ical split between members of the Message (picking up the host from the end of the Services Committee. The MIT members (Vezza

April–June 2008 9 The Technical Development of Internet Email

and Haverty) felt email headers were primarily The MsgGroup discussion raised two issues. of use to the email handling programs and First, was the new RFC going to cause much should be designed to be machine-readable. longer message headers that users would have Others felt that headers should focus on being to see? Second, wasn’t the major issue simply a human readable. RFC-680 tried to strike a desire to embed users’ real names into TO and compromise, which apparently pleased nei- FROM fields and, in that light, were all the other ther side.54 header fields necessary? The conclusion was The result was confusion. Some sites up- that extra header information simply reflected dated their mailers to conform to RFC-680 the reality of what had already happened, and while others continued to follow RFC-561. the desire not to see them pointed to a need for user agents to edit header information, and A new standard that yes, adding names mattered. Sometime in 1976, the Message Services The Header-People debate was rooted in Committee was replaced by the ARPA Com- specification details. The best example of the mittee on Human-Aided Communication.55 tenor of discussion is a multiday argument One of the new committee’s early actions was (rich with ad hominem remarks) about wheth- to seek to clarify the state of standards for er to use 12-hour or 24-hour times in the DATE email message formats. A vigorous email field, with much debate about whether discussion on the Header-People mailing list ‘‘12am’’, ‘‘12pm’’, or ‘‘12m’’ was the correct in the fall of 1976 led to a new proposed abbreviation for midnight. The upshot was to 58 standard in RFC-724 (‘‘Proposed Standard for eliminate support for 12-hour times. Message Format’’) written by Ken Pogran The result was RFC-733, a revision (by the (MIT), John Vittal (now at BBN), Dave Crocker, same authors) of RFC-724. The major improve- and Austin Henderson.56 It came out in early ment in the revision (beyond the date field) 1977. was a clear statement of how to include names The RFC-724 authors, like the RFC-680 with email addresses. The format was to put authors, sought mostly to document current the email address in angle brackets (,.)asin practice. Vittal nicely summarized the goals as: ‘‘David H. Crocker’’ ,crocker@rand-unix., and if the text before the brackets contained to take RFC680 plus what we felt were things any special characters such as punctuation or which people were already doing that were control characters, it had to be in quotes. The useful to most, take out some things that RFC also made clear that mailing lists looked 59 weren’t terribly useful and probably shouldn’t like any other mailbox. Issued in November have been in 680 in the first place, and come 1977, RFC-733 was the official standard for up with a new specification. There were message formats for five years, and a de facto several things that some systems were already standard well into the mid-1980s. doing: comments (e.g. the day of week in parentheses), association of people names Today’s standard with user names (like at places like Stanford, In 1982, as the email community was CMU and MIT, also using parenthesization), preparing to transition to the Internet, the random date format preferences (Multics vs Tenex, etc.), and so on. Elements of 680 which authors of RFC-733 were asked to update it. were not perceived as necessary were mostly The authors of 733 had several conversations the military-like field names such as prece- about what the changes should be, but only dence, as well as syntactic inconsistencies Dave Crocker (who had become a graduate (bugs), and syntactic limitations. These could student at the University of Delaware) had the all be accomplished by using the notion of time to undertake the revisions. Several fea- user-defined fields.57 tures of RFC-733 that had failed to win popular acceptance were deleted, and three new fields, RFC-724 defined a text-only message format. FORWARDED,RESENT-FROM, and RESENT-TO,were The message header and contents were ASCII. added (to support the common practice of The authors observed that, at some point in forwarding an email message to someone else). the future, clearly email would use richer A more startling feature (in retrospect) was binary formats, but that was beyond the the addition of the RECEIVED field. RECEIVED is immediate need. odd because it, alone of all the fields in the The new RFC provoked a tremendous message header, was created by MTAs rather amount of debate on Header-People and a than UAs. Every MTA was required to insert a more focused (and very distinct) discussion on RECEIVED field into the message, to track the MsgGroup. message’s path through the network. Looking

10 IEEE Annals of the History of Computing back, this is an odd and subtle architectural and they used it.64 By the mid-1970s, imple- change that made MTAs responsible for menting an MTA was getting harder, not understanding the format of messages, which because email had become more difficult, but previously (ignoring the practical problem of because the profusion of slightly different address rewriting; see the next section) MTAs MTAs meant that everyone’s MTA had to be had not needed to understand. programmed to deal with the differences. The result, written by Crocker and pub- For example, there was considerable dis- lished in August 1982, was RFC-822. RFC-822, agreement about whether one had to login to or more commonly, simply 822 format, the remote system (FTP had a login command remains the basic standard a quarter century called User) before trying to deliver email with later. (An updated version appeared as RFC- MLFL. Multics required a login. TENEX did not. 2822 in 2001, but the basic format is un- So MTAs had to include code to recognize 60 changed.) when they were talking to Multics and when Before we leave the discussion of the to TENEX and adapt their behavior accordingly. evolution of message formats, a few observa- SMTP, because it was well-specified, even- tions are in order. First, developing a message tually solved this problem (see the ‘‘SMTP and format was a difficult intellectual problem. avoiding second system syndrome’’ section). RFC-822 is 47 pages long and a combination of Unfortunately, by this point, a new problem an augmented Backus-Naur notation that had arisen: multiple email networks. defined each field’s format and briefly stated each field’s semantics. It is comparable in Bitnet, CSnet, and UUCP complexity to the computer language specifi- Between 1978 and 1981, three major email cations of the time. Second, it is hard to networks were created. Although the Internet understate the importance of RFC-733. RFC- remained the largest network throughout the 733 came out early enough to become the de 1980s, these three networks (UUCP, CSnet, facto standard for email message formats and Bitnet) would grow big enough to influ- throughout much of the world. The UUCP ence email standards. The UUCP network was network, the Computer Science Network comparable to the Internet in size. And, almost (CSnet) and Bitnet all ended up using RFC- 61 from the start, the four networks were inter- 733 format for their email messages. connected,65 creating massive challenges for MTAs of routing between four networks (not Evolving the MTA counting the smaller networks that appeared) SNDMSG was the earliest MTA. It simply with different address formats. delivered the message or returned an immedi- ate error message saying it had failed. After about a year, Bob Clements enhanced SNDMSG UUCP network. The UUCP network to retransmit messages if the remote host was (named for the Unix-to-Unix CoPy program 62 down. About two years later, SNDMSG was over which it was built) began inside AT&T in 66 updated to place each message in a file in the 1978. It used dial-up telephone links to user’s directory (one file per email) and a new exchange files and within a few months was program, called MAILER, would periodically moving email. AT&T soon distributed the pick up and deliver email files in the user’s software and the UUCP network, made up of directory.63 (Observe that this change convert- cooperating sites, was off and running. Over ed SNDMSG to a user agent, with MAILER taking thenextdecadeitgrewataprodigiousrate, on the role of MTA.) such that by 1990, its population was estimat- In a nutshell, that incremental evolution ed at a million users—comparable to the describes the experience of developing MTAs Internet’s population.67 in the 1970s. Each operating system would The UUCP network was a multihop net- implement an MTA, which was then refined work. To reach machine V, an email from over the years to deal with environmental machine M might have to pass through conditions. intermediate systems Q and T. The motivation Unfortunately, the different MTAs evolved for this approach was to minimize phone bills. differently. The underlying problem was that In the 1970s and early 1980s, long distance email via FTP was underspecified. (It is useful to calls were expensive, and the rates differed by observe that the specification for email delivery hour (with evening and night rates being with FTP was two pages long, while the SMTP sharply lower). were slow (a couple specification, when it appeared, was 68 pages hundred bytes per second was considered long.) Implementers had considerable latitude, good) and files were (relatively speaking) large.

April–June 2008 11 The Technical Development of Internet Email

So the typical operating mode at any UUCP site was to save up all email until 5 p.m., then call a nearby UUCP site to forward email along CSnet was designed to and receive inbound email. Indeed, over the course of the night, several phone calls would become self-supporting. be made to push outbound mail and receive inbound mail. Depending on the calling The ARPA and NSF fund- schedules and the connectivity of the ma- chines, email could travel a few or several hops ing was only to provide before the nightly calling frenzy ended. Initially, the person composing the email start-up capital and an had to spell out the entire path a piece of email needed to take through the network. In the initial operations budget. UUCP network, the hops were separated by exclamation points (‘‘!,’’ pronounced as ‘‘bang’’). So, someone mailing the author via CSnet was designed to become self-support- UUCP from UC Berkeley in the 1980s would ing. The ARPA and NSF funding was only to send it to ucbvax!ihnp4!harvard!bbn!craig (in provide start-up capital and an initial operations which each text string followed by a ‘‘!’’ is budget. For the first two years, CSnet operations known as a hop; this example has four hops). were distributed between the University of In 1982, Steve Bellovin wrote pathalias, a Wisconsin and the University of Delaware, with tool designed to compute paths from a help from RAND (which ran a gateway on the network map. He refined it with Peter Honey- West Coast). Beginning in 1983, the network man.68 Pathalias was distributed widely. Now, was operated by BBN, where a team of roughly by keeping a map of regional connectivity, it 10 people provided technical support (includ- became possible to email via landmark sites ing writing or maintaining much of the email and have them fill in the missing hops. So, for software used by CSnet members), user services, instance, the author’s address could be re- and did marketing and sales. By 1988, CSnet was duced to ihnp4!bbn!craig and the harvard hop self-supporting and had approximately 180 would be dynamically inserted. members, most of them computer science In 1984, Mark Horton began an effort to departments in North America. create a complete UUCP network map, which Technologically, CSnet did everything pos- reached fruition about 1986. After that, UUCP sibletomakeitsmembersfeelpartofthe users could simply type sitename!user, and Internet community. Initially, connectivity pathalias would compute a path to sitename for them. An even fancier trick was to add a was almost entirely email only, using dial-up network domain to the sitename, such as phone service. Over time, direct access via IP bbn.arpa!craig,andpathalias would compute a was also supported over a variety of media, including IP over X.2571 and the first dial-up IP path to an email gateway between the UUCP 72 network and the Internet. network. After 1983, email in CSnet all went through CSnet. By the late 1970s, the computer a single email gateway, CSNET-RELAY, which sat science research community realized that the on both CSnet and the Internet. Email was Arpanet was changing how people did re- routed by addressing it to the relay, with the search. Researchers who had access to a user address being the target address on the network got information more quickly, and other network. The syntax used a percent sign could collaborate and share work more easily. (%) to divide the next hop user name from Thus was identified the first ‘‘digital divide’’— relay address. So, to get from the Internet to a between computer science departments that CSnet host, one emailed to user%host.@ had access to Arpanet and those that did csnet-relay.arpa. From CSnet, one emailed not.69 user%[email protected]. Email was for- The goal of the Computer Science Network matted according to RFC-733 and 822 stan- (CSnet) was to bridge that gap. Created in 1981 dards. by the National Science Foundation in coop- eration with ARPA, CSnet linked computer Bitnet. Bitnet was established in the science departments and industrial research same year as CSnet, but with a different laboratories to the Arpanet (and then the driving force. Bitnet (‘‘Because It’s There’’ or, Internet).70 later, ‘‘Because It’s Time’’) was created by

12 IEEE Annals of the History of Computing university computer centers (now information instance, if someone told you he was bob@ technology offices) to interconnect their com- princeton, one had to immediately ask ‘‘which puting facilities with email and file transfer. network’’ because princeton. and princeton. Because the centers typically used IBM main- csnet were different machines and were not frames running the VM operating system, interconnected. If a user forgot, or her email Bitnet was constructed from low-speed leased software removed the network appellation lines running IBM networking software, on (e.g., .csnet)theemailwouldbedeliveredto which email was overlaid. the bob@princeton in whichever network the Like CSnet, Bitnet used Internet email sender was in. standards (with the %-hack in the email The second problem was that, even if one address for gatewaying). Unlike CSnet, Bitnet knew which network an email address was in, did not have a central management or support getting it there was not easy. To take a center. Instead, most functions were volunteer relatively common example, consider the activities, with coordination provided by following four addresses: Educom (Interuniversity Communications ihnp4!ucbvax!bob%princeton.csnet@ Council). In mid-1988, Bitnet had nearly 400 csnet-relay.arpa member sites. bob%princeton.csnet%csnet-relay.arpa@ The boards of Bitnet and CSnet overlapped wiscvm and the two networks eventually merged, so bob%[email protected] one may wonder why they were distinct in the bob@princeton first place. The distinction lies in the relation- ship, often contentious, between computer These represent the four likely addresses for science departments and computing centers in reaching bob at Princeton’s CSnet host, from the 1970s and 1980s. Computer science depart- the UUCP network, Bitnet, the Internet, and ments typically maintained their own comput- CSnet respectively. If the examples are not ing facilities, to enable research by computer painful enough, consider the first address and science faculty. Computing centers were uni- how it would be handled in transit. versity-wide resources that sought to provide It starts in the UUCP network and is passed stable computing environments for researchers to ihnp4 (a key UUCP relay at in in other disciplines. The stereotype was that Naperville, Illinois). Ihnp4 must puzzle out computer science departments ran cutting-edge ucbvax!bob%[email protected] and operating systems on and decide if the email address is to the left of workstations while computing centers ran the @ sign (Internet style) or to the right of established commercialoperatingsystemson the bang (UUCP style). As ihnp4 is a UUCP- mainframes. More important, from an institu- only system, it knows to use UUCP ad- tional perspective, the computer science de- dressing and passes the message to ucbvax partment typically provided a haven for those at the University of California at Berkeley. on campus who were (for whatever reason) Ucbvax is a gateway on both the Internet disgruntled with the computing center. Neither and UUCP networks so it must puzzle out partyparticularlywantedtorelyontheotherfor bob%[email protected]. Thank- networkaccess,withtheresultthattherewere fully, ucbvax was not on CSnet and clearly two networks: one for each community. not the same system as csnet-relay.arpa, so bob%princeton.csnet is no good. Thus the Email addressing across networks. The message must be sent to the CSnet relay four networks (including the Internet) period- (and, because Arpanet did not strip mailing ically viewed themselves as competitors. Yet information, it remains bob%princeton.csnet@ the four networks were also committed to csnet-relay.arpa). CSnet’s relay in turn extracts making email work among them. A number of the address to the left of the @ sign, to get sites brought up gateways between the net- bob%princeton.csnet and delivers the email to works. Even more sites made a point of Princeton. residing on more than one network, to ensure Observe that there’s ample chance for ease of mailing for their users. confusion. Another nasty problem was that It is widely agreed that, by the early 1980s, eachmailerhadtomakesurethattheFROM email addresses were a disaster both for users address in the email was updated (and some- trying to email across networks, and network times the TO and CC addresses as well) so that administrators trying to keep the email flowing. the recipient of the email could successfully The disaster had two dimensions. First, one reply to it. Yet another challenge was that, for had to know which network a user was on. For a period, the United Kingdom decided to

April–June 2008 13 The Technical Development of Internet Email

reverse the order of labels in a domain name regarding delivery. If, by some mischance, the (so [email protected]) with the result that message had to be queued, arpa (not deliver- some mailers had to parse names backward mail) would queue it. and forward (‘‘bothways’’ mode) to see if they To parse the address, used the made sense. simple expedient of assuming that an at-sign It is no surprise that the people who made meant Arpanet mail, an exclamation point in major contributions to email MTAs at this the address meant UUCP, and a colon meant time were people closely affiliated with email the local BERKNET protocols. For each address gateways. type, delivermail could be configured either to call a program to deliver the mail, or call a program to relay the mail to the appropriate delivermail, , and mmdf gateway (one email gateway per type). The appearance of new email networks The delivermail MTAhadapowerfulaliases transformed the complexity of the MTA. Now, features, in which a destination address could at least on systems that were on multiple email be expanded to a list of email addresses. It also networks, the MTA had to understand multiple had a first class logging system (a way to record addressing formats and routing rules and what delivermail did) called syslog. Email competently move messages between the var- systems were developingincreasinglysophis- ious networks as appropriate. One sign that the ticated logging mechanisms; syslog was so good problem of writing an MTA had gotten hard that it eventually became a standard part of wasthatitbecamethesubjectofserious BSD Unix and is now used by a wide range of academic research. The major contributions applications. were made by two graduate students: Eric One surprising feature of delivermail was delivermail send- Allman at UC Berkeley ( and that part of its configuration was compiled mail) and Dave Crocker (who had left RAND to into the program. That is, for each machine, study at the University of Delaware, where he one compiled a custom version of delivermail. mmdf). wrote So, for instance, if the machine was connected Both men were trying to solve essentially the to Arpanet, one compiled delivermail with the same problem: supporting multiple email net- –DHAS_ARPA flag to the C compiler. worksinonesystem.AllmanneededanMTA for UC Berkeley’s main email system, which mmdf. About the same time that Allman served as the university’s email gateway be- was creating delivermail, Dave Crocker was tween the UUCP network and the Arpanet and writing the first version of mmdf (the Multi- local email delivery. Crocker needed an MTA to channel Memo Distribution Facility).74 Rather support local email, Arpanet email, and a new than seek to process each message immediate- phone-based delivery system which eventually ly, as delivermail did, Crocker sought to became CSnet’s PhoneNet protocol. The two decompose the process into multiple stages. men solved the problem very differently. When a message arrived (via the network or from a user agent), the message was given to a delivermail. Allman’s delivermail, the program called submit, which checked that the simplest of these MTAs, was written for message format was correct (here the common Berkeley’s BSD Unix operating system in use of 733 format was a big win) and then 1979 and was a basic program73 not greatly looked at the address to decide what network more complex in its workings than Bob the message was to go out on. The message was Clements’ 1973-vintage SNDMSG. When in- assigned to a ‘‘channel.’’ Each channel had its voked by a user agent (or the inbound FTP own queue: a directory where messages and server), delivermail expected to be given a their ‘‘envelopes’’ (control information) were message, which it would either deliver or stored. Simply, submit placed the message in return an error message. The big difference the right queue. was that delivermail implemented a layer of Another program, called deliver, was regu- indirection. Rather than delivering the mes- larly scanning the queues for messages. When sage to a mailbox or a remote system, deliver- a new message appeared, deliver called on a mail looked at the destination address and channel-specific program (e.g., mmdf’s equiv- then picked a program to deliver the message alent of delivermail’s arpa program for Arpanet to. So, for instance, to deliver Arpanet mail via email) to deliver the message. If message FTP, delivermail called an auxiliary program delivery failed, submit wascalledtosendthe called arpa and passed the mail to the arpa message back to its sender. If there was a program and waited for a (real-time) response transient error (e.g., the remote host was

14 IEEE Annals of the History of Computing down), the message was left in the queue and N The address parsing rules and message deliver would try it again later. delivery rules were defined by a grammar The mmdf MTA also supported aliases and in the configuration file. had a fine logging system. N sendmail now maintained its own message An important contribution of mmdf was queue. achieving an effective split of the message N Certain delivery programs (most notably delivery process. Diagnosing email problems email delivery via SMTP) were compiled (whether configuration problems or problems into sendmail instead of client programs with particular messages) was cleanly com- (e.g., arpa). partmentalized. Similarly, submit prevented junk from entering the system; deliver handled But this list understates the transformation problems in delivery. An operator knew where from delivermail to sendmail: sendmail was the problem was by seeing which program was almost an order of magnitude more complex complaining in the logs. (measured in lines of code) and tremendously Another contribution was restriction of more flexible. privileges. One of the key problems in any The changes had an interesting mix of con- mail system is that whatever program delivers sequences. Probably the most important conse- mail to the user’s mailbox needs special quence was flexibility. Placing address parsing privileges. In mmdf, that was one small and configuration rules in a grammar made it program, the local channel delivery process. possible to dynamically configure sendmail for All the other processes could be run as a regular arbitrarily complex email environments. user (usually called ‘‘mmdf’’). Another consequence was a reinforcement The channel model also proved flexible. A of delivermail’s approach of putting all the message could go through multiple channels email expertise into one program. SMTP was before leaving a system. Soon, mmdf developed now embedded in sendmail. So too was queue a ‘‘list’’ channel to handle mailing lists. A management. It made sendmail acomplex message was placed in the list channel to have program and hard to change. Allman later its destination address expanded. It exited the noted that sendmail should have been better list channel by being placed in one or more decomposed into constituent functions, even channels to be delivered to members of the if only internally.76 mailing list. Later, when MX resource records An unexpected consequence was that craft- were introduced (see the ‘‘Email routing with ing and debugging sendmail’s single configu- domain names’’ section), they introduced a ration file (sendmail.cf) became a central new error: a domain name that (because of preoccupation (some would say headache) DNS problems) could not currently be looked for system administrators over the next several up. In mmdf this was trivially handled by years. A properly working email system re- creating a new channel, where submit placed quired the configuration file be right. And messages whose addresses could not be re- sendmail’s grammar (with a fondness for solved at the moment. single-letter tokens, which made mnemonic Adownsideofmmdf was that rather than naming impossible) gave administrators many one configuration file, there were several, opportunities to make a mistake. scattered in different places. While each con- figuration file was simple (a list of attribute: Evolution and perspective value pairs), the sheer number of them could Over the 1980s, both sendmail and mmdf prove frustrating. prospered: mmdf was substantially reworked by Crocker, Doug Kingston (of the Army’s sendmail. Based on experience with deli- Ballistic Research Laboratory), Steve Kille (of vermail, decided to write a new University College London), and Dan Long MTA for release with the 4.2 version of BSD and me (of BBN) into a new release called Unix. The new MTA was called sendmail. mmdf2, which was used at a number of major Culturally, sendmail was similar to deliver- email centers in the mid- and late 1980s. mail. But from a practical perspective, it was Also, mmdf inspired PMDF, a rewrite of quite different. Major differences included the mmdf in Pascal for the VMS operating system. following:75 The initial implementation was done by Ira Winston at the University of Pennsylvania. It N Configuration was determined by a file, was then maintained and substantially revised called sendmail.cf, rather than being com- by Mark Vassol and (then at piled in. Oklahoma State University). PMDF became a

April–June 2008 15 The Technical Development of Internet Email

popular email system for Digital Equipment but email gateways needed to know the host Corporation’s VMS operating system and, over part to effectively gateway email. Rather than time, became the dominant email system on bite the bullet and accept an Arpanet change Bitnet (where VMS systems were popular) and to FTP to pass the host part, Cerf suggested eventually became a commercial product. that, for compatibility sake, the user part be The sendmail MTA was repeatedly improved standardized across the Arpanet/Internet—in in subtle ways. Over time, as BSD Unix became effect, every system was to know every user’s the most popular operating system on the email name and where to deliver its mail! This Internet, sendmail became the most common idea seems to have been rapidly abandoned. MTA, while the sendmail.cf file continued to In RFC-772, Suzanne Sluizer and Jon Postel build a reputation for being complex. proposed a new ‘‘Mail Transfer Protocol’’ or In the end, sendmail had the last word. MTP.80 Its purpose was to serve as the bridge When the complex mix of email networks protocol for the email gateways between consolidated into a single email network after Arpanet and Internet email protocols.81 What, 1990, it was no longer necessary to write a precisely, the Internet email protocols would sendmail grammar that could handle multiple be was not discussed (though clearly the intent email address formats. The sendmail.cf be- was they would be new protocols capable of came much simpler. Sendmail could be recog- supporting multimedia). Very little thought nized for its flexibility without being forced to had been given to email protocols since the demonstrate its potential complexity. It re- 1973 FTP meeting but MTP tried to take mains a popular MTA to this day. advantage of what little thought had taken place. In particular, MTP sought to provide SMTP and avoiding second better support for delivering email messages to system syndrome multiple users on a single system. By 1980, the Internet protocols were rapidly In community lore, MTP is remembered as maturing, and ARPA (rechristened DARPA an ugly protocol. In truth, it was not ugly, but some years earlier) had started to plan the it was complex. It negotiated two different operational transition from Arpanet to Inter- ways to send email. One could either send the net protocols. Initially, the expectation was message first and then send the destination that Internet email would be multimedia and address, or one could send the destination thus a full-scale replacement of Arpanet email address and then the message. MTP used with Internet multimedia email would be complex commands, which made understand- made.77 However, by May 1980, of ing error codes difficult. For instance, it DARPA had concluded multimedia email was possible to say MAIL ,from@host1. TO would come too late for the Internet transition ,remote@host2. as a single command, which and that the problem of supporting text mail made it hard to parse error messages about and bridging email from systems using the old addresses to determine whether the FROM or Arpanet protocols to systems using the Inter- TO address (or both) was in error. It had an net protocols needed a solution.78 In Septem- approach to email forwarding that permitted ber 1980, three RFCs appeared that were an MTA to announce that it didn’t know how intended to start the process of planning the to forward a message but would hold onto the transition. message anyway until the MTA’s operator The first RFC (RFC-771) was written by Cerf figured out where the message should go—a and Jon Postel (at ISI) and was a plan to make bizarre idea that would have ensured endless the transition from Arpanet email protocols to work for operators. Internet email protocols using designated Some of these problems were noted at the email gateways that operated using both time.82 Nevertheless, MTP soldiered on. At protocol suites.79 least four implementations were made,83 and The other two RFCs are more interesting. the MTP specification was revised in May RFC-773 was an addendum to RFC-771, 1981. The revisions appear to be largely written by Cerf, and sketched out some of cosmetic and the protocol remained complex. the key technical issues in the transition. Cerf The impression is that the email transition was concerned to make the email transition as plans were poorly thought through. Some of simple as possible and to defer hard work until the Internet researchers of the time remember multimedia email was in place on the Internet. that the community viewed email as a distrac- One surprising statement followed the obser- tion—with so many problems in TCP and IP, vation that FTP-based transfer passed only the who needed to look higher in the stack? They user part of user@host to the remote system, give credit to Cerf for forcing them to

16 IEEE Annals of the History of Computing periodically pay attention. Then, late in 1981, These deficiencies are outweighed by things suddenly cleared up. SMTP’s design. Each command has zero or The continuing criticism caused Postel to one arguments. Reply codes are three-digit rethink MTP, and, in November 1981, he numbers, with the first digit standardized.89 A wrote an RFC describing a simpler protocol, positive response or an error can be deter- the ‘‘Simple Mail Transfer Protocol’’ (SMTP). mined by the first digit, even if the particular SMTP was, indeed, simple. Every command error code is novel. Transmission of a message had zero or one arguments. Recipients were typically requires just three commands: MAIL always listed before the message was sent, and FROM, RCPT TO, and DATA. While SMTP each recipient was listed and acknowledged clearly reflects its roots in FTP (which has a separately. A slightly revised version of the similar command style), the complicating specification came out as RFC-821. features of FTP (in particular, features for It is not clear what inspired SMTP’s design, interactive user support) were removed. but there is a hint. Sluizer and Postel published two RFCs documenting their experience im- Domains and a new way to route plementing MTP.84 The first one, RFC-784, From the early days of the Arpanet, the observed that it was convenient to maintain DDN Network Information Center (NIC) two files for each email message: a control file maintained a file, named HOSTS.TXT, which called the envelope and the message itself. At mapped single-word hostnames to network this point, the concept of an envelope was still addresses. This file was copied to every host on relatively new. The term envelope had been the Arpanet and later Internet, so users could coined in 1975 as a way of discussing header use character-based mnemonic hostnames fields that MTAs needed to be able to deliver a such as bbn-loki rather than numeric addresses message,85 but by 1979, its meaning had such as 128.89.1.178. shifted to mean the metadata associated with Unfortunately, the HOSTS.TXT scheme had amessage.86 several limitations. Updates were difficult. The The second RFC, RFC-785, detailed the NIC needed to be notified when a new host internal structure of the envelope file as it was installed or host information was appeared on TOPS-20. Each item of informa- changed, and then every host needed to tion (each email recipient, the email sender, download the new HOSTS.TXT. To minimize etc.) was kept on a separate line. And if one the network load (HOSTS.TXT was a relatively reads the SMTP specification, each command large file and having every host get a copy in SMTP corresponds to adding a line of could cause considerable network load), information in the TOPS-20 envelope file. So HOSTS.TXT was updated just a few times a week. perhaps that is where Postel got his ideas for Simply getting new information propagated SMTP. could take several days. SMTP, with changes, remains the Furthermore, the namespace was flat. Only way email is transferred today, 25 years later. one machine could be named FRODO.Further- In that light, it makes sense to try to assess more, names were relatively short (24 charac- what has made SMTP so long-lived. ters maximum90), so users had to become First, we note that SMTP did (and in some increasingly creative about hostnames as the cases, still does) have deficiencies. Despite network grew. Postel’s interest in the support of multimedia In 1982, the Internet community set out to mail, SMTP was defined to use 7-bit ASCII—a replace HOSTS.TXT with a distributed database. decision that had to be undone a decade later. Zaw-Sing Su and Jon Postel of ISI wrote a SMTP’s request/reply format causes SMTP proposal for a new naming structure. The connections to follow a pattern of many little scheme created hierarchical names, with dif- data exchanges (command/reply, command/ ferent portions of the hierarchy, called do- reply) and then a big transfer of the actual mains, delimited by a dot (‘‘.’’) in the name.91 email message. This pattern turns out to be bad Forexample,underthisscheme,F.ISI,would both for TCP and on network paths with long bethenameofhostFintheISIdomain.The delays. This problem was eventually solved naming scheme was clearly inspired by the with SMTP pipelining.87 RFC-821 had some recently developed Grapevine distributed SMTP commands to send messages directly to naming system developed at Xerox PARC.92 user terminals. These commands were never In November 1983, of ISI implemented widely. In addition, SMTP has a issued two RFCs93 specifying a distributed small race condition, such that email can be database system to support a domain name duplicated.88 system (DNS). Reflecting considerable com-

April–June 2008 17 The Technical Development of Internet Email

mentary on the NameDroppers mailing list, the proposed DNS supported multiple levels of hierarchy (vs. the two levels used by Grapevine Another open question in and suggested by Su and Postel). The DNS stored information as resource records, where late 1985 was what the each record mapped a name to a typed value such as an IP address. A single name could top-level domains would have multiple records (so a host with multiple IP addresses would have one resource record be. As the DNS began to for each IP address). Work began at ISI and UC Berkeley to implement the proposed DNS in work, finalizing top-level TOPS-20 and Berkeley Unix.94 By the summer of 1985, both servers were domain names became an working (at least experimentally). But several deployment issues remained unresolved, at increasingly vital. least two of which were vital: how email was to work with the DNS, and how the namespace should be organized. have one record for mail routing, called a Mail EXchanger (MX) record. I worked through the Email routing with domain names details of the idea and crafted the routing rules In the summer of 1985, I joined the staff for MX resource records. I reported that the of CSnet and was asked to see what modifica- resulting specification was indeed much sim- tions needed to be made to CSnet’s email pler (about half as long as the previous one). software to support the (now working) domain Postel declared a solution had been found, and name system. Mockapetris’s DNS specification asked Mockapetris to update the DNS specifi- had created two resource records to support cation. Mockapetris’ update and my specifica- 99 email routing, but the specification only tion appeared in January 1986. loosely specified how they would be used. MX resource records remain the way email Initially, I thought the problem would be is routed today. The basic idea is simple. A easy95 only to realize a few weeks later that name is associated with one or more MX there was a serious issue.96 resource records. Each resource record has the Mockapetris had defined two email routing name of one host and a preference number. records for the DNS: a Mail Destination (MD) To route to a name, a mailer looks up the record and a Mail Forwarder (MF) record. The name’s MX records and then successively notion was to allow a domain name to specify tries to deliver to the hosts, starting with the that all email addressed to the domain was to host with the lowest (best) preference num- be delivered to a particular host (an MD), or ber, until delivery succeeds or the mailer runs that the email could be relayed via one or more out of MX records. To prevent loops, if the email gateways (MFs). The central idea here mailer is one of the MX hosts listed, it may was new and powerful: under the DNS, the only deliver to MXs with a lower preference rightsideofthe@signinanemailaddresswas value. Despite the simplicity, the scheme no longer the host to which email was to be supports most useful types of email routing delivered, but a name for which email routing easily.100 was specified. I eventually realized that, if a name had Defining the domain name space both MD and MF records, there were situations Another open question in late 1985 was where email could loop or worse, fail to be what the top-level domains would be. Top- delivered.97 I wrote a draft RFC describing a level domains are the last part of a domain complex set of rules that ensured such failures name: thus in example.com the top-level is would not occur and sent it to Jon Postel and .com. As the DNS began to work, and as email Mockapetris. Postel and Mockapetris felt the was being modified to use it, the issue of proposed rules were ugly and burdensome to finalizing top-level domain names became an MTAs. They asked me to work with a small increasingly vital issue. group of people, including Mockapetris, to It soon became clear that the issue tran- find a better solution.98 scended the Internet community. The major After a couple days of discussion, Mock- email networks connected to the Internet saw apetris suggested a potential solution was to a chance to make their naming schemes

18 IEEE Annals of the History of Computing consistent. Indeed, one of the people pushing to add a country code to their email address most vigorously for resolution was Dick was much like forcing them to add a network Edmiston, who led CSnet. name such as .arpa or .bitnet to their email Elizabeth ‘‘Jake’’ Feinler, head of the DDN address. In his view, both practices were ugly NIC, hosted a two-day meeting at SRI Interna- and restrictive.103 He asked why a university tional in late January 1986 to resolve all had to make the top level of its name the outstanding issues. Beyond several Internet country in which the university was situated, representatives, mostly notably Postel, Mock- when clearly the most important aspect of the apetris, and Ken Harrenstein (SRI), the meet- institution was that it was an educational ing included representation from the UUCP organization. Equally vigorously, Postel had community (Mark Horton), Bitnet (Dan no interest in assisting a conversion to X.400. Oberst), and CSnet (Laura Breeden and me), Indeed, he already had taken the step (as the representatives (Kevin Dunlap and Jim Bloom) Internet Assigned Numbers Authority) of from the UC Berkeley BSD Unix project (which assigning control of .us to himself and made maintained sendmail and the bind DNS soft- it clear that his naming structure for .us would ware) and Steve Kille (of University College bear no relationship to anything compatible 101 London). with X.400. Once the meeting began, it was clear that The debate ran, on and off throughout the 102 but for an odd issue about creating .net, the meeting. In the end, the parties agreed to real issue at the meeting was email compati- disagree, but accept that the decision was bility. CSnet used Internet email standards Postel’s. whenever possible and planned to implement At the time, Postel’s intransigence seemed DNS naming throughout its network. The just a stubborn attempt to delay an inevitable UUCP network, limited by its flat namespace, transition to X.400. In retrospect, several also saw an advantage in adopting domain factors were about to converge to make the names. Bitnet was less certain, but still felt debate, arguably, X.4009shighwatermark. domain names were of interest. More general- By standardizing on domain names, the ly, a brief discussion of the routing technolo- meeting created a common email addressing gies of the different networks made clear that it and message format that probably covered was possible to create seamless support for over 90 percent of the email community of the user@domain-name email addresses of the form time. Over the next several years, organiza- that spanned the four networks. The end of tions on CSnet, Bitnet, and UUCP, already the era of ihnp4!ucbvax!bob%princeton.csnet@ using domain names and thus culturally csnet-relay.arpa was visible and exciting. Every- acclimated to the Internet world, would begin one at the meeting agreed to push to get their seamlessly transitioning to the Internet. SMTP, respective software ready. RFC-822, and domain names were about to Except … except that Mark Horton wanted become a technical juggernaut that X.400 compatibility with X.400 email addresses too. would be hard-put to displace. Postel’s deci- (X.400 is described in more detail in the sion to keep .us distinct from X.400 made the ‘‘X.400’’ section). The X.400 naming system process of replacement by X.400 tougher— was known (though not yet working). It used everyone would have to change email address- names that were close to domain names. Steve es (precisely the barrier that the meeting had Kille and Horton had worked out a way to map eliminated for organizations on CSnet, Bitnet, between X.400 addresses to DNS names, if the and UUCP who wished to join the Internet). DNS followed certain naming practices. Hor- If X.400 was to become the next email ton wanted to make it possible for sites to pick standard, it now had to pin its hopes on the domain names that would be compatible with X.400. Those questions led to the question of fact that X.400 supported multimedia while whether there would be a .us domain. X.400 SMTP/RFC-822 did not. names were assigned by country, and thus organizations in the United States, in the Long tough path to multimedia (e)mail X.400 system, would have names ending in Multimedia mail is email that contains a .us. If Kille and Horton were to achieve the goal richer set of objects than simply ASCII text. of compatibility with X.400, there needed to Throughout the 1970s, email on the Arpanet be a .us domain, and names in the .us domain and most other email systems was limited to hadtobegivenoutaccordingtoX.4009srules. ASCII. At the end of the 1970s, researchers and Postel was adamantly opposed to structur- implementers began to think about how email ing .us to fit X.400. He felt that forcing people might be enriched.

April–June 2008 19 The Technical Development of Internet Email

Early multimedia This plan covers only the transition from the In 1977, IFIP created a working group current text computer mail in the Arpanet (WG 6.5) to address the need for standards for environment to text computer mail in an computer-based message systems. Grossly sim- Internet environment. This plan does not address a second transition from text only plifying its charter (which included dealing mail to multimedia mail.108 with issues such as networked messages), the working group was to lay the groundwork Cerf’s commentary on the transition plan for an international standard for email. This noted: effort was eventually to lead to the CCITT/ISO X.400 standards for email. Real work seems to DARPA is beginning a new phase of research have begun sometime in 1978 or 1979. As part into automatic electronic message handling of this effort, Debbie Deutsch and John Vittal systems. Ultimately it is intended that elec- at BBN were thinking about the format of tronic messages incorporate multiple media email messages. such as text, facsimile, compressed digitized Under the auspices of the National Software voice, graphics and so on.79 Works program,104 Jon Postel at ISI started investigating protocols to move multimedia By the start of 1982, there were at least nine messages between systems. In March 1979, Internet multimedia projects at seven institu- Postel published ideas for an ‘‘Internet Mes- tions (CMU, ISI, MIT, COMSAT,BBN,UCL,and sage Protocol.’’105 SRI). The jump in effort was sparked by the In 1978, the UUCP email network began advent of desktop machines with high-quality operation. In 1979, responding to a need for a graphics. Several projects were using the new way to safely send binary files between PERQ workstations, MIT was using Apollo systems, Mark Horton (then a grad student at workstations, SRI was using the Foonly F-5 (a Berkeley) wrote the uuencode program, and it desktop PDP-10 clone), and BBN was using its was distributed with the 4.0BSD distribution of own graphics workstation called the Jericho. the Berkeley Unix operating system. uuencode Most of the research effort was devoted to converted binary files into a formatted ASCII trying to figure out how to encapsulate voice file that could be included in any email and CCITT fax data into email.109 message. A complementary program, uude- Despite the large number of efforts and the code, couldreadtheformattedASCIIand apparent interest in getting multimedia email extract the binary contents. uudecode was working over the Internet, little came of these cleverly designed to skip over any leading text projects. The most successful appears to have until it hit the line encoding the start of a been the Diamond multimedia project led by uuencoded object. So you could include some Bob Thomas and Harry Forsdick at BBN. (Also leading text in the email describing the binary on the team was Ray Tomlinson.) By 1985, object being sent and yet safely feed the entire Diamond had a complete multimedia email email to uudecode to extract the binary. system with user interface, mail transport uuencode’s major contribution to multimedia system, and a multimedia editor to create mail was to demonstrate that people did want documents that blended voice, video, spread- to email around binaries—for years, on the sheets, and other data.110 BBN made Diamond Internet, uuencode was the way binary data was into a product (called Slate) and sold a modest sent.106 number of systems. Oddly, while the work on uuencode, Postel’s Impressive as Diamond was (and the work at ISI, and the work at BBN all led to demos were wonderful), it proved a develop- fruitful results, it is hard to directly trace the mental dead-end for two reasons. The first work in any of them to the final development was simply that Diamond (like the other of Internet multimedia mail. But they created multimedia projects) was too soon. As Cerf’s a milieu in which multimedia mail was comments about incorporating voice and fax anticipated, and finally, after long effort, into regular emails show, there was a shortage achieved. of digital data. The profusion of digital, often graphics-rich, data was still a few years away. Internet multimedia—Round one The second problem was that when digital By 1980, Postel’s work107 on multimedia data became available, users turned out to protocols had created an expectation that the want to pick their own tools. That is, rather Internet would shortly transition to multime- than use Diamond’s built-in spreadsheet dia email. As the introduction to the 1980 editor on a Diamond document, they wanted email transition plan makes clear: to use Excel or Lotus 1-2-3 to create a

20 IEEE Annals of the History of Computing document and then email that document to A good example of the work, and an their colleagues. In short, the challenges for illustration of its quality and some of the multimedia email were not those of creating challenges of the time, is the work on content, but rather those of packaging binary encoding data in messages.113 X.400 chose to objects or ‘‘attachments’’ into regular email, standardize on a binary data format for and how to create open interfaces that messages. That decision created a number of allowed applications (and email user agents) challenges including: to insert and extract those attachments from email easily. N How to represent binary data efficiently on the A slightly later (1987) and more successful network. At the time, network capacity was activity was the messaging system for the extremely expensive, so there was a moti- Andrew Project at CMU. The Andrew project vation to save every possible byte (and bit). was a collaboration between IBM and Carnegie The X.400 team sought a compact data Mellon University to create a powerful and representation. affordable computing environment for stu- N How did applications embed data in messages? dents.111 Andrew sought to create a seamless Theissuehereisthatdataformatson computing environment throughout campus, different computers may be incompatible. where students could log into any machine They were certainly incompatible in the and read and write email, do coursework, or early 1980s, when a byte could be 5, 6, 7, 8, any one of a number of other activities. The 9, or 10 bits long depending on the system. Andrew Message System (AMS) was designed Data to be sent over the network needs a to be a showcase application demonstrating standard, ‘‘external’’ format that is com- the utility of Andrew. puter independent. In the early 1980s this In many ways, AMS was very similar to the concept was alien to most programmers.114 earlier Internet projects (of which its designers The X.400 approach was to encourage appear to have been unaware).112 It had its programmers to define how to move their own multimedia editor, a custom GUI, and data into and out of a generic format called was built atop a sophisticated distributed an external data format. system. But AMS had one important cultural N Data and not garbage. X.400 envisioned a difference: it was designed to coexist with world in which user agents developed new existing email services rather than replace features and new applications would em- them. As a result, AMS’s designer, Nathaniel beddatainadocumentandsothe Borenstein, sought to find ways to make AMS’s receiving user agent might receive an email multimedia messages compatible with send- message that contained header fields it did mail and SMTP. That mind-set was to prove not understand and application data from useful a few years later. an application it had never seen before. How to ensure the user agent didn’t simply X.400 report it had received garbage? The solution Interestingly, the people working on the that X.400 chose to this problem was to CCITT/ISO email standard, called X.400, bet- make the data self-describing. ter understood the multimedia challenges and set out to create an email standard designed to The result was a conceptually elegant encod- carry third-party documents. In many re- ing. Every piece of data is encoded as a triplet spects, X.400 was one of the best CCITT/ISO of a type (for self-description), a length (which networking standards activities. This success permitted compressing data into its shortest may be attributed to several email-savvy representation), and a value. The encoding is people who worked on it including John Vittal recursive, so a structured type is a triplet, and Debbie Deutsch (both at BBN) and Jim whose value field contained triplets for the White (by then at Xerox). individual fields in the type. The X.400 team sought to design a com- This general, self-describing, external data pletely new email system, built on top of the format initially was issued as the CCITT X.409 emerging ISO standards for data networking. standard but soon became the standard known To that end, they created an email delivery as Abstract Syntax Notation 1 (ASN.1). The architecture (defining user agents and message compact self-describing data format was de- transfer agents), and developed protocols for signed by Debbie Deutsch, Bob Resnick, John delivering email from end point to end point, Vittal, and Jan Walker, working under a con- and formats for email addresses and email tract to the National Bureau of Standards.115 To messages. the encoding, Jim White added a formal

April–June 2008 21 The Technical Development of Internet Email

language intended to make it easy to specify much wanted to be able to send email in their a data representation without having to actu- own languages and character sets. At the time, ally write out the bit-by-bit descriptions. SMTP limited them to (essentially) US ASCII. While X.400 did not survive, X.409/ASN.1 At its next meeting in March 1991, the IETF is widely used in network protocols. The effort both made tremendous progress and communal consensus is that the formal lan- stumbled.118 guage is a nuisance and the focus on encoding The progress was to realize that the job was efficiently made the formatting overly com- to extend SMTP and to extend RFC-8229semail plex. But the self-describing triples are elegant message format to support national character and solve many problems. sets and binary (multimedia) material.119 A The X.400 community was justly proud of group to study RFC-822 extensions was creat- their work. An obvious question is why did not ed. It promptly coalesced around a proposal X.400, partly completed in 1984 and updated from a team led by Nat Borenstein and Ned in 1988, become the Internet multimedia Freed. Borenstein, now working at Bellcore, email standard? had both the experience and credibility of The short answer is that it could have.116 having built the Andrew Messaging System. Steve Kille, who had been on the UCL Freed brought several years of experience multimedia project, concluded X.400 was the maintaining PMDF. way to go and invested considerable effort in The IETF’s stumble came in extending trying to make X.400 Internet-ready. However, SMTP. By March 1991, there was uncertainty there were challenges. X.400 was tightly about the goal of the upgrade. The motivation embedded in the ISO standards (which were in December 1990 had been to meet European intentionally different from the Internet stan- needs, but now the new SMTP group (distinct dards), and fitting X.400 into the Internet’s from the 822 group) seemed to think enabling email system was hard. a transition to X.400 was a more important In addition, as the Horton-Postel debate of goal. Further, the details of upgrading the the previous section shows, there were political existing SMTP infrastructure to support 8-bit issues. The ISO/CCITT community was acutely transfers were difficult and fraught with aware that in X.400 they had produced a transition challenges, which worried vendors. cutting-edge data networking standard for the Over the summer of 1991, the two groups’ Internet’s key application (email) and hoped to paths diverged. ride the success of X.400 to convince (force) the The group working on 822 extensions Internet community to adopt the rest of the ISO arguably had the harder problem. It had ‘‘Open Systems Interconnection’’ (OSI) proto- decided to adopt a scheme where binary col suite in place of TCP/IP. Conversely, the objects were encoded as separate sections of Internet community was willing (sometimes the body of an RFC-822 message. This solution grudgingly) to admit that X.400 was a nice required devising a scheme for identifying the piece of work. But most members of the Inter- separate sections (the core idea of the Boren- net community also tarred X.400 as a compo- stein/Freed proposal) and then coming up nent of the unpopular OSI protocol suite. with a uniform naming scheme that made it possible to identify what each binary object was and how it was encoded. The group had to Internet multimedia—Round two resolve problems such as naming schemes for As the 1990s began, the Andrew Messaging 200+ character sets. Yet, the group made swift System was in use at CMU and a derivative was progress and by late 1991 was making largely available from Next Computers as NeXTMail. minor changes to a suite of documents X.400 had undergone a round of revisions in recognizably defining the Multipurpose Inter- 1988. But the Internet still lacked any way to net Mail Extensions (MIME) standard that is send multimedia email. Binary data were, used today. (In one amusing moment, the however, being routinely sent using uuencode. group agreed it did not want to support In its meeting of December 1990, the uuencode coding as it was distasteful, even Internet Engineering Task Force (IETF) decided though uuencode was the default way to send to investigate the possibility of making SMTP binary documents at the time.120) ‘‘8-bit friendly,’’ that is, making it possible to In contrast, the group working on 8-bit move binary information via SMTP.117 Much friendly SMTP floundered. Every solution of the interest in this change came from presented challenges, and the group was Europe. The European portion of the Internet struggling to make a choice. Furthermore, a was growing rapidly, and Europeans very significant part of the group felt that it was

22 IEEE Annals of the History of Computing time to replace SMTP (the ‘‘new protocol’’ limited email expertise,125 subsequent meet- approach) or transition to X.400. The effort ings were typically filled with email experts lacked focus. such as Nathaniel Borenstein, Mark Crispin, At the November 1991 IETF meeting, senior Dave Crocker, Erik Fair, Ned Freed, Christian members of the community stepped forward Huitema, , and Einar Stef- to force a solution. John Klensin, whose ferud.126 networking experience stretched back to early Internet days, was induced to step in as the Closing thoughts group’s chair.121 Klensin had the seniority and One of the interesting things about the credibility to issue an ultimatum: either the history of Arpanet/Internet email is how often group converged immediately on an approach little issues were redirected into bigger, more or the 8-bit SMTP effort would be terminated. important results. Dick Watson wanted to The ultimatum effectively excluded X.400 and print memos on remote printers. Instead, Ray new protocols from the agenda, leaving the Tomlinson created networked email. Vint Cerf group to grapple with the challenges of and Jon Postel wanted to make sure email was extending SMTP. gatewayed between Arpanet and Internet There were two key issues. First, how to protocols, yet the result was replacing FTP transition from 7-bit to 8-bit gracefully. There with SMTP. A desire to support European was much discussion about how 7-bit MTAs character sets started a process that, finally, should interact with 8-bit MTAs and vice versa, caused the Internet to support multimedia including questions of whether 8-bit MTAs email and attachments. A subtext to this needed to be able to convert messages from 8- process is the willingness to discard partial bit to 7-bit representations (a painful idea). In solutions such as MTP, or MD and MF resource the end, the decision was that 7-bit MTAs records, for a better solution. would refuse 8-bit email, and the 8-bit MTA Another observation is the exceptional had the choice of converting from 8-bit to 7- talent that was often involved. Several people bit MIME or returning the email as undeliver- mentioned have received the IEEE Internet able. The choice to permit email to be returned Award (Dave Crocker, Steve Crocker, Paul assumed that the general transition to 8-bit Mockapetris, and Ray Tomlinson), the IEEE SMTP wouldn’t take very long (as, indeed, it Kobayashi Award (Vint Cerf and Van Jacob- didn’t). son), or the ACM SIGCOMM Award (Cerf, The second issue was how to mark email Jacobson, Mockapetris, Jon Postel, and Larry messages as being 8-bit. Initially the idea was Roberts) for their contributions. Many more that SMTP would acquire a new set of are IEEE or ACM fellows. commands to support 8-bit email (distinct from the 7-bit commands). During the winter Acknowledgments of 1992, the group discussed the meanings of In the 1970s, many key ideas never made it commands named CPBL and EMAL to support into an RFC or even an email archive. Thus delivery of 8-bit emails.122 Sometime in the writing this article required help from several spring of 1992, encouraged by Marshall Rose people (in the form of interviews or reviews) to to find a simpler solution, the group members fill in the blanks. Thanks are due to Eric realized that these commands were superflu- Allman, Steve Bellovin, Bob Braden, Jerry ous.123 The existing SMTP commands could be Burchfiel, Noel Chiappa, Dave Crocker, Steve made to work with 8-bit email and all that was Crocker, John Day, Peter Denning, Jake Fein- needed was a message at the start of an SMTP ler, Ken Harrenstein, Mary Ann Horton, Steve interaction to confirm that both ends of the Kille, John Klensin, Alex McKenzie, Mike conversation were 8-bit capable. The EHLO Padlipsky, Suzanne Sluizer, Ray Tomlinson, (extended HELO) message was promptly in- Al Vezza, John Vittal, Steve Walker, Barry vented and the problem of SMTP extensions Wessler, and Martin Yonke. In some situa- was then, largely, solved. RFC-1426 written by tions, recollections differ, and I have been Klensin, Freed, Rose, , and Dave unable to find contemporary documentation Crocker appeared in February 1993.124 With to sort out the differences. Where the recol- modest modifications it defines what is today’s lections are matters of nuance, I sought to standard. present a middle ground. Where the differenc- A subtext to the IETF process is how many es seemed likely to be material for a future senior email experts were pulled into the historian, I have documented differences in process. While the December 1990 decision to the notes. Any errors are, of course, my fault. I update SMTP was made by a group with am intensely grateful to the BBN Library staff

April–June 2008 23 The Technical Development of Internet Email

(Jennie Connolly and Penny Steele-Perkins) He believed the operating system was Berkeley’s for their invaluable assistance finding older SDS-940 system, but the SDS-940 veterans report references. it did not have an email program. 11. The choice of @ did cause some controversy. It References and notes turned out that @ was a reserved character in 1. J.S. Quarterman, The Matrix: Computer Networks Multics that caused all input to that point on a and Conferencing Systems Worldwide, Digital Press. line to be deleted. 1990; P.H. Salus, Casting the Net: From ARPANET 12. A. Bhushan, File Transfer Protocol, Internet Request to Internet and Beyond, Addison-Wesley, 1995; K. for Comments No. 114, 10 Apr. 1971; A. Hafner and M. Lyon, Where Wizards Stay up Late, Bhushan et al., The File Transfer Protocol, Internet Simon & Schuster, 1996; I.R. Hardy, ‘‘The No. 265, 17 Nov. 1971. Evolution of ARPANET Email,’’ Univ. California, 13. A side note: the problem of developing a general Berkeley, master’s thesis, 1996; J. Abbate, distributed file system (which was the goal of the Inventing the Internet, MIT Press, 1999. initial FTP work) turned out to be excruciatingly Quarterman’s book sought to document the state hard and was not solved until the early 1980s and of networking in the world in 1990 and is a required the development of the concept of tremendously valuable testament to a time just remote procedure call (see B.J. Nelson, ‘‘Remote before the Internet took over. The works of Salus, Procedure Call,’’ doctoral dissertation, Carnegie Hafner and Lyon, and Abbate are general histories Mellon Univ., 1981) and distributed transactions in which email plays a modest part—this article is, (W.E. Weihl, ‘‘Transaction Processing in some sense, the fine-grained version of email’s Techniques,’’ Distributed Systems, 2nd ed., S. history. Hardy’s thesis seeks to understand the Mullender, ed., Addison-Wesley, 1993). social dynamics of the community in which email 14. A.K. Bhushan, Data and File Transfer Workshop developed and is a useful complement to this Notes, Internet Request for Comments No. 327, work. T. Haigh, ‘‘The Web’s Missing Links: Search 27 Apr. 1972. Engines and Portals,’’ The Internet and American 15. A.K. Bhushan, File Transfer Protocol, Internet Business, W. Aspray and P. Ceruzzi, eds., MIT Request for Comments No. 354, 8 July 1972. Press, 2008, also has a useful perspective. 16. A.K. Bhushan, Comments on the File Transfer 2. J.K. Reynolds, Post Office Protocol, Internet Request Protocol, Internet Request for Comments No. 385, for Comments No. 918, Oct. 1984; J. Myers and 18 Aug. 1972. Despite the title, it is the M. Rose, Post Office Protocol—Version 3, Internet document that defined MLFL and MAIL and Request for Comments No. 1939, May 1996. (For appears to have been the standard reference for information on retrieving RFCs online, see Ref. 5). the next eight years. 3. M.R. Crispin, Interactive Mail Access Protocol: 17. D. Crocker, personal communication, 26 Apr. Version 2, Internet Request for Comments No. 2006. 1064, July 1988. 18. The Arpanet community eventually developed a 4. T. Van Vleck, ‘‘The History of Electronic Mail,’’ term for this kind of problem: the n 3 m rule. The http://www.multicians.org/thvv/mail-history. n 3 m rule, paraphrased, says that one should html. abhor designing systems where the consequence 5. The Internet Request for Comments series is of adding a new system is that every other system maintained online. To retrieve a particular RFC, needs to learn how the new system works (i.e., use http://www.rfc-editor.org/rfc/rfc#.txt, where where the new system places users’ mailboxes). # is replaced with the one-, two-, three-, or four- 19. A.K. Bhushan, RFC-385; M. Padlipsky, personal digit RFC number. communication, 14 Apr. 2006. 6. R.W. Watson, A Mail Box Protocol, Internet Request 20. M. Padlipsky, ‘‘And They Argued All Night …,’’ for Comments No. 196, 20 July 1971. note at http://www.lafn.org/%7Eba213/allnight. 7. R. Tomlinson, personal communication, 13 Apr. html. 2006. 21. S. Lukasik, oral history interview by J.E. O’Neill, 17 8. A similar line of thinking had led to email in Oct. 1991, Redondo Beach, Calif., OH 232, Multics. wanted a way to send a Charles Babbage Inst. Lukasik guessed he was message to an operator and that idea morphed using email on Arpanet by 1971 (p. 11). That is into sending messages between users. J. Klensin, too early, but 1972 is plausible. personal communication, 10 June 2006. 22. The original name was Tape Editor and COrrector, 9. D.G. Bobrow et al., ‘‘TENEX, a Paged Timesharing but by 1973, the acronym had evolved. Thanks to System for the PDP-10,’’ Comm. ACM, vol. 15, no. Dan Murphy (TECO’s author) and John Vittal for 3, 1972. tracking down when the name changed. 10. SNDMSG’s origins are uncertain. Tomlinson ported 23. Lukasik (Ref. 21) says Roberts produced RD SNDMSG to TENEX from another operating system. overnight. Roberts dates the invention of RD to

24 IEEE Annals of the History of Computing July 1972 in his Internet chronology (http://www. an RFC (J.E. White, Proposed Mail Protocol, packet.cc/internet.html). Internet Request for Comments No. 524, June 24. M. Yonke, personal communication, 26 Apr. 1973), and there’s a strong impression that the 2006. There was an intermediate program community paid very little attention to the issue. between NRD and BANANARD, called WRD (for 36. J. Vittal, ‘‘MSG—A Simple Message System,’’ Wessler’s RD). Yonke recalls it was only around Computer Messaging Systems, R.P. Uhlig, ed., briefly and was largely Wessler’s code with bug North Holland, 1981. fixes, but otherwise unmodified. 37. BBN collected Arpanet traffic measurements 25. M. Yonke, personal communication, 26 Apr. monthly during this time, but I have been unable 2006; S. Crocker, personal communication, 31 to find a copy of them and thus could not verify May 2006; J. Vittal, personal communication, 5 this claim. June 2006; Yonke remembers the index size as 38. S. Walker, ‘‘Message Group Status,’’ email to 5,000 while Crocker remembers it as a much MsgGroup of 7 June 1975. smaller number (a few hundred). Vittal 39. The Navy was a pioneer in the use of email for remembers hitting the limit. operational needs. In 1973, the Navy had 26. B.D. Wessler, personal communication, 17 Apr. inaugurated the ‘‘Navy Communications 2006. Processing and Routing System 27. R. Tomlinson, personal communication, 13 Apr. (NAVCOMPARS),’’ an internal email system to 2006; J. Vittal, personal communication, 5 June distribute orders to shore bases and to ships 2006. (messages to ships were relayed via shortwave 28. The meeting announcement (A. McKenzie, File radio using human operators). NAVCOMPARS Transfer Protocol—Meeting Announcement and a remained a key part of the Navy’s infrastructure New Proposed Document, Internet Request for until it was turned off in 2002. B.M. Hintz, ‘‘The Comments No. 454, 16 Feb. 1973) contains a Naval Communications Processing and Routing draft new specification and includes suggested System: Analysis of an Automated System,’’ improvements to MAIL and MLFL. master’s thesis, Naval Postgraduate School, Mar. 29. J. Day, personal communications, 14 and 16 Apr. 1976. A good description of the system as it was 2006. operating in 1984 can be found in S. Blumenthal 30. N. Neigus, File Transfer Protocol, Internet Request et al., ‘‘NAVCAMS LAN Engineering Plan,’’ BBN for Comments No. 542, 12 Aug. 1973. Report 5907, Mar. 1985. 31. The common set of attendees was Abhay 40. S. Walker, personal communication, 8 June 2006. Bhushan (from MIT), Bob Braden (UCLA), Alex 41. D.P. Deutsch and D.W. Dodds, Hermes System McKenzie (BBN), Jon Postel (UCLA), and Jim Overview, BBN Report 4115, May 1979. White (SRI). 42. D.H. Crocker, Framework and Functions of the 32. That there were FTP meetings at roughly the ‘‘MS’’ Personal Message System, tech. report R- same time of year in both 1972 and 1973 has 2134-ARPA, RAND Corp., Dec. 1977. caused some confusion decades later. People are 43. A copy of the original memo can be found at sometimes confused about which meeting they http://rand-mh.sourceforge.net/book/overall/ attended. hiofmh.html. 33. J. Postel, ‘‘Mail Protocol,’’ DDN NIC memo 29588, 18 Feb. 1976 in ARPANET Protocol 44. D.M. Ritchie and K. Tompson, ‘‘The UNIX Time- Handbook, DDN Network Information Center, Sharing System,’’ The Bell System Technical J, Jan. 1978. vol. 57, no. 6, July-Aug. 1978, part 2, 34. Allowing multiple addresses in a MLFL/MAIL pp. 1905-1930. command was proposed in A. Bhushan, File 45. Dave Crocker observes the interesting Transfer Protocol (FTP) Status and Further counterpoint that attempts to ‘‘enhance’’ MH, Comments, Internet Request for Comments No. such as xmh and mhe, have sought to move the 414, 29 Nov. 1972, and again (now using new MH commands back into a monolithic program. commands) in K. Harrenstein, FTP Extension: 46. Dave Crocker reports that the MS manual, to his XRSQ/XRCP, Internet Request for Comments No. surprise, does not describe features for searching. 743, 30 Dec. 1977. NIC 29588 suggests that D. Crocker, personal communication, June 2006. some sites used the RFC-414 scheme but that it 47. I interacted with Rose and Jacobson on MH was not universally accepted. support in the 1980s. Other names come from J. 35. There were some proposals for an email protocol Peek, MH & xmh: Email for Users & Pro- (the preface to RFC-724 mentions ‘‘Several grammers, O’Reilly and Associates, 3rd ed., 1995. versions of such a protocol have been proposed 48. A. Bhushan et al., Standardizing Network Mail ...’’). However, none seem to have gotten serious Headers, Internet Request for Comments attention; only one seems to have been issued as No. 561, 5 Sept. 1973.

April–June 2008 25 The Technical Development of Internet Email

49. T.H. Myer and D.A. Henderson, Message 61. CSnet supported RFC-733 format from the start. Transmission Protocol, Internet Request for The UUCP network took somewhat longer. The Comments No. 680, Apr. 1975. driving forces were sendmail (used on many 50. See E. Stefferud, ‘‘MSGGROUP Situation Report UUCP systems) and netnews B, which #1,’’ email to Header-People of 2 Dec. 1975. intentionally used 733 format for bulletin boards. 51. In particular, Mooers wrote emails on behalf of Both software systems (plus a desire to easily the BBN team explaining details of RFC-680. gateway to the Internet) pushed the community Years later, Mooers was CSnet’s ‘‘postmistress’’ to informally standardize on 733 for email. (S. and internationally known for her expertise in Bellovin, personal communication, 30 May 2006; solving email problems. M. Horton, personal communication, 6 June 52. J. Haverty, ‘‘Re: [ih] NIC 7104 (ARPANET Protocol 2006; see also, M. Horton, UUCP Mail Interchange Handbook)’’ email to Internet-History mailing list Format Standard, Internet Request for Comments of 28 Apr. 2006. No. 976, Feb. 1986.) Bitnet started using a 53. See RFC-724 preface. custom VM email format but soon shifted to 733 54. Interview with A. Vezza on 3 May 2006. He (J. Klensin, personal communication, 26 May 2006). believes his (now lost) memo, ‘‘Message Services Committee Minority Report,’’ Jan. 1975, 62. A. Bhushan, File Transfer Protocol (FTP) Status and Further Comments, Internet Request for expressed the view that headers should be Comments No. 414, 29 Nov. 1972, lists the machine readable. See also the preface to RFC- implementation status of various FTP 724, which reflects the continued debate. implementations and observes that Clements has 55. The initial membership of the new committee was implemented email retransmission. Walker, John Seely-Brown, David Farber, Ken 63. See Deutsch and Dobbs, Hermes System Overview, Pogran, and John Vittal. J. Vittal, personal p. 21. communication, 5 June 2006. 64. Compare with B. Reid, ‘‘Let’s hear it for uniform 56. For key notes in the discussion, see the note from standards,’’ email to Header-People of 10 Feb. J. Haverty (JFH @ MIT) on 30 Sept. 1976, ‘‘Re: 1978. your message to MSGGROUP at from and sender 65. This decision to interconnect is, in retrospect, …,’’ and J. Vittal, ‘‘Some comments (RFC-724, somewhat surprising. The different networks did etc.) …’’ of 9 Nov. 1976, both emails to view themselves as competing with each other. MsgGroup. Confusing the discussion is that an However, they also viewed themselves as early draft of RFC-724 was apparently distributed, competing with the postal services (derisively with its assigned RFC number, in 1976 (well dubbed ‘‘snail mail’’) and prided themselves on before its official publication date). K. Pogran et getting email where it belonged faster and more al., Proposed Official Standard for the Format of effectively than paper-based mail. Credit should ARPA Network Messages, Internet Request for also be given to Larry Landweber, a member of Comments No. 724, 12 May 1977. both CSnet’s and Bitnet’s boards, and a vigorous 57. J. Vittal, ‘‘Comments on the state of the world,’’ advocate of interconnecting networks. email to Header-People mailing list of 29 Oct. 66. D.A. Nowitz and M.E. Lesk, ‘‘A Dial-Up Network 1977. of UNIXTM Systems,’’ 18 Apr. 1978, Unix 58. See the numerous emails between 4 and 11 Oct. Programmer’s Manual, 7th ed., Bell Telephone 1977 in Header-People. Laboratories, 1979. 59. Mailing lists had an odd history in the message 67. J.S. Quarterman, The Matrix, p. 251 and 278. format standardization process. No later than 68. P. Honeyman and S. Bellovin, ‘‘PATHALIAS or the 1975, there were mailing lists as we know them Care and Feeding of Relative Addresses,’’ Proc. today, in which email to, say, MsgGroup@ISI was 1987 Summer Usenix Conf., 1986, Usenix Assoc., delivered to host ISI. Host ISI then redistributed pp. 126-141. the message to the members of the list. Yet there 69. D. Comer, ‘‘The Computer Science Research seem to have been a number of different Network CSNET: A History and Status Report,’’ practices intended to show that the message was Comm. ACM, vol. 26, no. 10, 1983, pp. 747-753. to a mailing list. So, at one time, ISI would rewrite 70. Peter Denning, one of the CSnet principals, the outbound TO field of MsgGroup messages to remembers that, to make the CSnet proposal read ‘‘[ISI]MSGGROUP:’’. ‘‘researchy’’ enough to be acceptable to the 60. D. Crocker, Standard for the Format of ARPA National Science Board, the proposal emphasized Internet Text Messages, Internet Request for ‘‘resource sharing’’ rather than email, but Comments No. 822, Aug. 1982; P. Resnick, everyone, including the junior NSF staffers, Internet Message Format, Internet Request for understood this was a fig leaf for email. (P. Comments No. 2822, Apr. 2001. Denning, personal communication, 5 June 2006.)

26 IEEE Annals of the History of Computing 71. D.E. Comer and J.T. Korb, ‘‘CSNET Protocol 85. E. Stefferud, ‘‘Subdivision of Messages,’’ email to Software: The IP-to-X.25 Interface,’’ Proc. ACM MsgGroup of 11 July 1975. SIGCOMM 983, ACM Press, 1983, pp. 154-159. 86. The first use of envelope to mean metadata 72. L. Lanzillo and C. Partridge, ‘‘Implementation of appears to be by D. Crocker, E. Szurkowski, and Dial-up IP for UNIX Systems,’’ Proc. 1989 Winter D. Farber, ‘‘An Internetwork Memo Distribution Usenix Conf., Usenix Assoc., pp. 201-208. Capability—MMDF,’’ Proc. 6th ACM/IEEE Data 73. Surviving source code (version 2.7 from 1981) is Comm. Symp., ACM Press, 1979, pp. 18-25. about 6,800 lines of C code. There seem to have 87. The idea for pipelining originated with Phil Karn been no technical papers describing delivermail. around 1990, when he told it to me, and I in turn, The discussion here comes primarily from reading repeated the idea to Van Jacobson. Jacobson the source code and its Unix manual pages. thought it was a wonderful idea, and put it into 74. D.H. Crocker, E.S. Szurkowski,, and D.J. Farber, sendmail only to discover that many SMTP ‘‘An Internetwork Memo Distribution implementations failed if pipelining was turned Capability—MMDF,’’ Proc. 6th ACM/IEEE Data on. Some of the painful experience is described in Comm. Symp., ACM Press, 1979, pp. 18-25. P. Karn, email to IETF mailing list of 8 Sept. 1993. 75. This list is a subset of the list of differences in E. Eventually, the IETF approved a pipelining Allman, ‘‘Mail Systems and Addressing in extension to SMTP to make it official: N. Freed, 4.2bsd,’’ Proc. 1983 Winter Usenix Conf., Usenix SMTP Service Extension for Command Pipelining, Assoc., 1983, pp. 53-62. Internet Request for Comments No. 2920, Sept. 76. E. Allman and M. Amos, ‘‘Sendmail Revisited,’’ 2000. Proc. 1985 Summer Usenix Conf., Usenix Assoc., 88. C. Partridge, Duplicate Messages and SMTP, 1985, pp. 547-555. Internet Request for Comments No. 1047, 1 Feb. 77. See J. Postel, ‘‘Internet Meeting notes—4, 5, & 6 1988. February 1980,’’ Internet Engineering Notes, no. 89. Unfortunately, SMTP is no longer quite this 134, 29 Feb. 1980, which notes that ISI was simple. Some commands now have additional working on ‘‘Internet Mail, which includes the parameters (a consequence of the 8-bit development of mechanisms for delivery of mail enhancements; J. Klensin, Simple Mail Transfer in an internet and provision for multi-media data Protocol, Internet Request for Comments No. in the mail.’’ 2821, Apr. 2001), and there’s pressure to 78. J. Postel, ‘‘Internet Meeting Notes—14 & 15 May standardize the error codes to avoid dependence 1980,’’ Internet Engineering Notes, no. 145, 25 on the error message, which may be a local May 1980. language (J. Klensin, personal communication, 11 79. V. Cerf and J. Postel, Mail Transition Plan, Internet June 2006). Request for Comments No. 771, Sept. 1980. 90. E. Feinler et al., DoD Internet Host Table 80. S. Sluizer and J. Postel, Mail Transfer Protocol, Specification, Internet Request for Comments Internet Request for Comments No. 772, Sept. No. 810, 1 Mar. 1982. 1980. Some people have conflated MTP and MP 91. Z. Su and J. Postel, Domain Naming Convention for (the Mail Protocol—see the Early Multimedia Internet User Applications, Internet Request for section) and incorrectly believe that MTP Comments No. 819, 1 Aug. 1982. supported multimedia. 92. See A.D. Birrell et al., ‘‘Grapevine: An Exercise in 81. RFC-771 does not explain why it was written. But Distributed Computing,’’ Comm. ACM, vol. 25, RFC-772 makes clear that MTP is intended solely no. 4, 1982, pp. 260-274. for use for gateways. 93. P. Mockapetris, Domain Names: Concepts and 82. Suzanne Sluizer recalls Jon ‘‘Postel saying people Facilities, Internet Request for Comments thought that MTP was too complicated.’’ C.J. No. 882, 1 Nov. 1983; P. Mockapetris, Domain Bennett, ‘‘A Simple NIFTP-Based Mail System,’’ Names: Implementation Specification, Internet Internet Engineering Notes, no. 169, 23 Jan. 1981, Request for Comments No. 883, 1 Nov. 1983. lists issues with MTP on pp. 4 and 5. 94. P. Mockapetris and K.J. Dunlap, ‘‘Development of 83. J. Postel, ‘‘Internet Meeting Notes—28-29-30 the ,’’ Proc. ACM SIGCOMM January 1981,’’ Internet Engineering Notes, no. 988, ACM Press, 1988, pp. 123-133. 175, 13 Mar. 1981, lists four implementations: 95. C. Partridge, ‘‘MF in domain database,’’ message MIT, ISI, DCEC, and COMSAT. to NameDroppers mailing list of 29 Oct. 1985. 84. S. Sluizer and J. Postel, Mail Transfer Protocol: ISI 96. C. Partridge, ‘‘MD and MF for one host,’’ message TOPS-20 Implementation, Internet Request for to NameDroppers mailing list of 11 Nov. 1985. Comments No. 784, 1 July 1981; S. Sluizer and J. 97. The description of the issues is now lost, but it seems Postel, Mail Transfer Protocol: ISI TOPS-20 File useful to reconstruct it from memory. If a name Definitions, Internet Request for Comments No. could have both MD and MF records associated 785, 1 July 1981. with it, we needed a set of rules for delivery in the

April–June 2008 27 The Technical Development of Internet Email

presence of both records. The obvious answer was (he’s not sure) but it is more likely than not. Kille that a host that was neither an MD nor an MF for would have provided an international the name could deliver email to either the MD or perspective (he was at University College the MF; a host that was an MF could only deliver to London) and an X.400 perspective. The account an MD; and a host that was an MD could do a DNS of the meeting is my recollection. Horton’s lookup, but, once it realized it was an MD, had to recollections place somewhat more emphasis on look in other databases to figure out how to deliver finalizing the list of top-level domains. the message. Now consider the problem of host H, 102. The issue surrounding .net was that SRI trying to deliver a message to domain name D. H (operator of the DDN NIC) and BBN (operator looksupDintheDNSandgetsbackasetofemail of the CSnet CIC) competed for network resource records. H must then examine all the operations contracts and differed in their records to see if H is listed as either an MD or an MF strategies. BBN’s approach was to build the for D to behave in accordance with the delivery brand of the entity for which BBN operated the rules. Herein lay a problem. It was possible in the network (so, for instance, BBNers on the CSnet DNS to deliver an incomplete list of MDs and MFs. project had CSnet business cards) on the theory In particular, the DNS’s caching mechanism that BBN’s dedication to building the brand (combined with the fact that one could query for made BBN more attractive to the customer. SRI MDs and MFs either individually or using an sought to strongly link the entity to SRI, on the aggregate MAILA query) allowed for look up theory the customer would be more reluctant to responses to contain either the MDs for D or the change operators. So CSnet wanted to see a .net MFs for D, or both. And if H did not get both MDs top-level domain so that NIC’s name would be, and MFs, H could make an incorrect decision. say, nic.inter.net. SRI wanted the NIC’s name to 98. These discussions involved both private and be nic.sri.com. In the event, .net was created, public messages. The private messages have been but the NIC became nic.ddn.mil. lost. The key public messages are P. Milazzo, ‘‘Re: 103. For Postel’s views on .arpa and . and the MD and MF for one host,’’ message to like, see his email ‘‘re: naming and routing’’ to NameDroppers on 11 Nov. 1985 in response to the NameDroppers mailing list on 8 Feb. 1995. the message cited in Ref. 95; C. Partridge, 104. R.E. Millstein, ‘‘The National Software Works: A ‘‘Mailers use MD and MF,’’ message to Distributed Processing System,’’ Proc. ACM’77 NameDroppers on 12 Nov. 1985; and P. Conf., ACM Press, pp. 44-52. Mockapetris, ‘‘MD, MF and larger issues,’’ 105. J. Postel, Internet Message Protocol, Internet message to NameDroppers on 15 Nov. 1985. It is Request for Comments No. 753, Mar. 1979. my recollection that the Mockapetris note came 106. The uuencode format was also adopted by after a private email exchange among Postel, several early email tools, notably Mockapetris, and Partridge. Rudy Nedved (then and Lotus cc:Mail, for packaging attachments. of CMU) and Jon Crowcroft (then of University M.A. Horton, personal communication, 6 June College London) also made important 2006. contributions, especially in thinking how MX RRs 107. J. Postel, Internet Message Protocol, Internet interacted with sites that gatewayed email. Request for Comments No. 759, Aug. 1980. J. 99. P. Mockapetris, Domain Systems Changes and Postel, A Structured Format for Transmission of Observations, Internet Request for Comments Multi-Media Documents, Internet Request for No. 973, Jan. 1986; C. Partridge, Mail Routing Comments No. 767, Aug. 1980. and the Domain System, Internet Request for 108. V. Cerf, Comments on NCP/TCP Mail Service Comments No. 974, Jan. 1986. While the RFCs Transition Strategy, Internet Request for were issued in late January, I recall that the work Comments No. 773, 1 Oct. 1980. on RFC-974 was largely done by Thanksgiving of 109. For a brief overview of the projects, see J. Postel, 1985 (which is remarkable, given the issues with Multimedia Mail Meeting Notes, Internet Request MD and MF surfaced on 11 Nov.) and the delay for Comments No. 807, 9 Feb. 1982. until January was to give Mockapetris time to 110. R.H. Thomas et al., ‘‘Diamond: A Multimedia think about how to address other DNS issues so Message System Built on a Distributed that RFC-973 could be a comprehensive update. Architecture,’’ Computer, Dec. 1985, pp. 65-78. 100. C. Partridge, ‘‘Mail Routing Using Domain 111. Concurrently a similar project, Project Athena, Names: An Informal Tour,’’ Proc. 1986 Summer was under way at MIT. Usenix Conf., Usenix. Assoc., 1986, pp. 366-376. 112. The first paper on the Andrew Messaging System 101. No notes of this meeting survive. The cites none of the prior Internet-based work. See J. attendance list is crafted from my recollections Rosenberg, C.F. Everhart, and N.S. Borenstein, and those of Mary Ann Horton. There’s ‘‘An Overview of the Andrew Message System: A uncertainty about whether Steve Kille was there Portable, Distributed System for Multi-media

28 IEEE Annals of the History of Computing Electronic Communication,’’ Proc. ACM also new to the field and quite young and thus, SIGCOMM ’87, ACM Press, pp. 99-108. unlike Klensin, in no position to dictate a solution 113. For a general overview of work in data encoding to a fractious (and senior) group of techies. for the period, see C. Partridge and M. Rose, ‘‘A Vaudreuil continued as chair of the 822-extensions Comparison of External Data Formats,’’ Message group and brought it to a successful conclusion. Handling Systems and Distributed Applications (Proc. Klensin remembers Phill Gross, IETF chair, IFIP Workshop on Message Handling),E.Stefferud ‘‘dragged me, I’m tempted to say kicking and and O. Jacobsen, eds., North Holland, 1989. screaming’’ into taking on the SMTP problems (J. 114. There were some pioneers. The earliest idea I Klensin, personal communication, 11 June 2006). have seen for an external data format is J. 122. M. Davies, ed., Proc. Twenty-Third IETF Meeting, Haverty, MSDTP-Message Services Data IETF, 15-20 Mar. 1992. Transmission Protocol, Internet Request for 123. Recollections differ slightly about how this change Comments No. 713, 6 Apr. 1976. It contains a of course came about. (J. Klensin, personal remarkably thorough understanding of the communication, 11 June 2006; D. Crocker, problem of creating an external data format. personal communication, 31 May 2006). Rose Haverty was at BBN when Deutsch and Vittal pushed for the simplification. What is unclear is were doing their work. whether EHLO was Rose’s idea, or the reworking of 115. D. Deutsch, R. Resnick,, and J. Vittal, Specification an earlier idea by Klensin that the working group of a Draft Message Format Standard,BBNReport had discarded. I cannot find documentation 4486, Sept. 1980. D. Deutsch et al., Specification pointing to one or the other answer. for Message Format for Computer Based Message 124. J. Klensin et al., SMTP Service Extension for 8bit- Systems (Revised), BBN Report 4765R, 23 Apr. MIME Transport, Internet Request for Comments 1982. Online literature generally gives all credit for No. 1426, Feb. 1993. ASN.1toJimWhite.Asexplainedtome(some 125. Of the Dec. 1990 group, only Bob Braden of ISI yearsago),WhitegetscreditforASN.1’slanguage had written an MTA or participated in crafting for expressing types, but the actual on-the-wire an email standards document. encoding (the Basic Encoding Rules) is the creation 126. Borenstein, Freed, Crocker, and Klensin’s of Deutsch’s group. The dates of these two BBN background is described earlier in the article. reports are consistent with that story (they define Stefferud ran the Msg-People mailing list what clearly became the encoding rules) and in the 1970s and coined the term ‘‘envelope.’’ explain why the encoding rules are completely Fair was widely respected as an expert at unlike , which was White’s invention and keeping email systems running and, at the the Xerox external data format of the time. time, managed Apple Computer’s email 116. There is considerable debate, even today, about systems. Huitema was a pioneer in networking how viable X.400 would have been as the in France. Internet’s email system. Several readers of the paper felt the characterization of X.400 both in is chief scien- terms of the quality of its technology and its tist for networking at BBN chances for success is far too generous. Some Technologies, where he has others felt this was about right. worked on data networking 117. Proc. Nineteenth IETF Meeting, IETF, Dec 1990, problems since 1983. He is pp. 72-76. best known for his work on 118. Proc. Twentieth IETF Meeting, IETF, 11-15 Mar. email routing, TCP round-trip 1991, M. Davies and G. Vaudreuil, eds., time estimation, and high- pp. 75-84. performance router design. He received an MSc 119. There are some hints in the meeting notes that the and a PhD, both in computer science, from two groups initially may have been confused Harvard University. Craig is the former editor in about whether they were complementary or chief of IEEE Network Magazine and ACM Computer competing. Participants’ memories vary. But it is Communication Review and is an IEEE Fellow. hard to believe that there was much competition, given they had the same chairman. 120. The decision not to support uuencode is noted Readers may contact Craig Partridge about this on p. 62 of Proc. Twenty-Second IETF Meeting, article at [email protected]. IETF, 18-22 Nov. 1991, M. Davies, C. Clark, and D. Legare, eds. 121. Until Nov. 1991, both the SMTP and RFC-822 For further information on this or any other extensions groups were chaired by Greg computing topic, please visit our Digital Library Vaudreuil. Vaudreuil was a good group leader, but at http://computer.org/csdl.

April–June 2008 29