The Technical Development of Internet Email
`
`Craig Partridge
`BBN Technologies
`
`Abstract
`The development and evolution of the technologies and standards for Internet email took over
`twenty years, and arguably is still underway today. The protocols to move email between
`systems and the rules for formatting messages have evolved, and have each been largely replaced
`at least once. This paper is the story of that evolution, with a focus on why things look the way
`they do today.
`Keywords: Electronic mail, Internet, multimedia communication, protocols
`
`Introduction
`1
`The explosive development of networked electronic mail (email) has been one of the major
`technical and sociological developments of the past forty years. A number of authors have
`already looked at the development of email from various perspectives.1 The goal of this paper is
`to explore a perspective that, surprisingly, has not been thoroughly examined: namely, how the
`details of the technology that implements email in the Internet have evolved.
`This is a detailed history of email’s plumbing. One might imagine, therefore, that it is only of
`interest to a plumber. It turns out, however, that much of how email has evolved has depended
`on seemingly obscure decisions. Writing this paper has been a reminder of how little decisions
`have big consequences and I have sought to highlight those decisions in the narrative.
`2 The Architecture of Email
`As the story of this paper is how email came to look the way it does today, we start by describing
`(in broad strokes) today’s world, so that the steps in the evolution can be marked more clearly.
`Today’s email system can be divided into two distinct subsystems. One subsystem, the message
`handling system (MHS), is responsible for moving email messages from sending users to
`receiving users, and is built on a set of servers called message transfer agents (MTAs). The other
`subsystem, which we will call the user agent (UA), works with the user to receive, manage (e.g.
`delete, archive, or print), and create email messages and interacts with the MHS to cause
`messages to be delivered. Readers may recognize this terminology as being roughly that
`developed by the X.400 email standardization process.
`Each subsystem internally has a rich set of protocols and services to perform its job. For
`instance, the UA typically includes network protocols to manage mailboxes kept on remote
`storage at a user’s Internet Service Provider or place of work. The MHS includes protocols to
`reliably move email messages from one MTA to another, and to determine how to route a
`message through the MTAs to its recipient(s).
`
`Page 1
`
`Apple Exhibit 1329 Page 00001
`
`

`

`The UA and MHS must also have some standards in common. In particular, they need to agree
`on the format of email messages and the format of the meta-data (the so-called envelope) that
`accompanies each message on its path through the network.
`The focus of this paper is how these different pieces incrementally came into being and
`exploring why each one emerged and how its emergence affected the larger email system. In the
`interests of space, this survey stops around the end of 1991. That termination date leaves out at
`least four stories: (1) the development of graphics based user interfaces for personal computers
`and the incorporation of those interfaces into web browsers; (2) the rise of UA protocols such as
`the Post Office Protocol (POP)2 and IMAP3 (these protocols existed prior to 1991, but much of
`their evolution occurred later); (3) the continuing efforts to further internationalize email (e.g.,
`allowing non-ASCI characters in email addresses); and (4) the rise of unwanted email (dubbed
`“spam”) and tools that sought to diminish it. Furthermore, in the interests of space, we do not
`consider the development of technical standards for the support of email lists.
`3 First Steps
`Electronic mail existed before networks did. In the 1960s, time-shared operating systems
`developed local email systems delivering mail between users on a single system.4 The
`importance of this work is that email requires a certain amount of local infrastructure. There
`needs to be a place to put each user’s email. There needs to be a way for a user to discover that
`he or she has new email. By the early 1970s, many operating systems had these facilities.
`In July of 1971, Dick Watson of SRI International published an Internet Request for Comments5
`(RFC-196) describing what he called “A Mail Box Protocol,” The idea was to provide a
`mechanism where the new Network Information Center (NIC) could distributed documents to
`sites on the ARPANET. Watson described a way to send files (documents) to a teletype printer,
`with different mailboxes for different types of printers. Mailbox 0 was a teletype
`“assumed to have a print line 72 characters wide, and a page of 66 lines. The new
`line convention will be carriage return (X’0D’) followed by line feed (X’0A’)…
`The standard printer will accept form feed (X’0C’) as meaning move paper to the
`top of a new page.”6
`Ray Tomlinson of Bolt Beranek and Newman (now BBN Technologies or BBN) read Watson’s
`memo and reacted that “it was overly complicated because it tried to deal with printing ink on
`paper with a line printer and delivered the paper to numbered mailboxes.”7 In Tomlinson’s view,
`the correct approach was to send documents to a user’s electronic mailbox and let the user decide
`if the document merited printing.8 So Tomlinson set out to see if he could send email this way
`between two TENEX systems9 over the ARPANET. His approach was simple.
`TENEX already had an existing local email program called SNDMSG10, which, given a message,
`appended that message to a file called MAILBOX in a user’s directory. TENEX also had a
`homegrown file transfer service called CPYNET (written by Tomlinson). In a passive mode,
`CPYNET listened at a particular address for requests to read, write or append to a particular local
`file. Email was achieved by incorporating CPYNET into SNDMSG. If SNDMSG was given a
`message addressed to user at a remote host, it opened a CPYNET connection to the remote host
`and instructed CPYNET to append the message to the user’s mailbox on that host.
`
`Page 2
`
`Page 00002
`
`

`

`Users learned that they had received network email the same way they learned they had received
`local email. In TENEX, they got a “You have mail” message when they logged in. Mail was
`read by viewing or printing the mailbox file, usually with the TYPE command. (Almost
`immediately, TYPE MAILBOX was replaced with a TENEX macro READMAIL). Messages
`were deleted by deleting the relevant lines with a text editor.
`Tomlinson made two important contributions. First, he found a way to express the networked
`email address. He chose to use the “@” sign to divide the user’s account name from the name of
`the host where the account resided, resulting in the now ubiquitous user@remote format.11
`Second, SNDMSG was the first MTA – it took a message and delivered it (using the CPYNET
`protocol) to a remote user’s mailbox.
`Observe that the last contribution is a surprise. We might imagine that the first program was
`more of a user agent (UA) rather than a message transfer agent (MTA). But SNDMSG could
`only deliver mail, it could not receive mail, and it delivered the email all the way to the
`recipient’s mailbox. Therefore, SNDMSG was much closer in spirit to an MTA (and, indeed, as
`we shall see, was used as an MTA for a number of years). At the same time, SNDMSG was
`primitive. If there were multiple email recipients on the same host, it copied the message once
`for each recipient. If the remote host was down, SNDMSG simply returned a failure message –
`it made no effort to retransmit.
`Despite its primitive nature, Tomlinson’s creation took off. The next few years saw it mature
`from a fun idea to a central feature of the ARPANET (and later the Internet).
`4 From Primitive to Production
`By late 1973, email was widely used on the ARPANET. What happened after Tomlinson’s
`experiment to make this happen? Obviously email met a need. But there were also technical
`steps: standardization of the transfer protocol and the development of user interfaces.
`4.1 A Standard Transfer Protocol
`First, the community replaced CPYNET with a standardized file transfer service, the first
`generation of the File Transfer Protocol (FTP). This process took a while. In 1971, FTP was
`simply a set of rather complex ideas written up in a set of RFCs by a team led by Abhay Bhushan
`of MIT.12 The goal of these ideas was to create a general tool to manage files (including deleting
`and renaming files) on remote machines and to do it in a way that met the needs of any
`envisioned application.13
`At the same time, Dick Watson’s mailbox idea was continuing to mature. In November of 1971,
`a team including Watson proposed a way to enhance (the still nascent) FTP with an explicit
`“MAIL” command to support appending a file to a mailbox. They further proposed that email be
`simply ASCII strings of text (no binary images) and that mailbox numbers be replaced with text
`user identifiers. The identifiers were “NIC handles.” NIC handles were given out by the
`Network Information Center to authorized network users (and were used as login IDs on
`ARPANET terminal servers, called TIPS). This idea, of course, meant that every host would
`need to maintain a table mapping NIC handles of local users to the location of their mailbox file.
`Retaining Watson’s original idea of accessing printer, the MAIL command could be given the
`name “PRINTER” instead of a NIC handle and the file would be printed.
`
`Page 3
`
`Page 00003
`
`

`

`Concurrently, Tomlinson distributed SNDMSG to other TENEX systems and people began to
`get hands-on experience with email. TENEX was the most common operating system on the
`ARPANET at the time and so probably at least half the ARPANET users had access to
`SNDMSG.
`In April of 1972, most of the interested parties, including both Tomlinson and Watson, met at
`MIT to discuss revisions to the File Transfer Protocol. The meeting made several decisions at
`least one of which proved to have a long-term impact: they agreed to use text (ASCII)
`commands and replies (previous versions of FTP had used binary commands) to aid interactive
`use14. To this day, the Internet uses text commands to transfer email (and the tradition lives on in
`much later protocols, such as the web’s transfer protocol, HTTP). A new version of the FTP
`specification, based on these ideas and written by Bhushan, came out in July.15
`The new specification envisioned that email would be delivered via the APPEND command,
`which appended data to a file. Discussions about FTP and email continued however, and a
`month later, Bhushan issued a revision to the FTP specification16 to include a new command,
`MLFL (Mail File). It is said Bhushan came up with MLFL because, one evening while he was
`writing the revision, a fellow graduate student at MIT stopped by to suggest a better solution was
`required for email.17
`MLFL took one argument, a user id, which could either be a NIC handle or a local user name
`(local to the remote host). The user id could also be left out, in which case the mail was to be
`delivered to a printer. After the MLFL command was accepted, the email file was transmitted
`over an FTP data channel (with the end of the file indicating the end of message). The file was
`required to be in ASCII. A separate copy of the file was sent for each recipient at a host.
`MLFL was an important step. A key flaw in Tomlinson’s prototype email was that you had to
`know where in the receiving host’s file system a user’s mailbox was located, so that you could
`append to it.18 This limitation probably explains why most of the email activity in 1971 and
`1972 appears to have taken place between TENEX systems, where the file name for the mailbox
`was consistent. MLFL adopted Watson’s notion that mailboxes are symbolic names that the
`receiving system translates into an appropriate user mailbox file and thereby freed email from
`system specific limitations.
`An interactive MAIL command was also defined, so that users logged into a TIP could type in an
`email message using only FTP’s control connection. In this case, a line with a single dot (“.”) on
`it marked the end of the message. Ending a message with a single dot is still how email is
`moved over the Internet today.
`The MAIL and, more important, MLFL commands remained the way email was delivered
`between systems for several years.
`In the fall of 1972 Bob Clements of BBN updated SNDMSG to use the new commands. Several
`other email cognizant FTP implementations appeared. The most notable is probably the system
`for MIT’s Multics. Ken Pogran wrote the FTP implementation and Mike Padlipsky wrote the
`NETML program that handled email. 19 Multics was exceptional for the time because it had
`good security including user file privileges, so Padlipsky had to invent a special user
`(ANONYMOUS) to receive email and distribute it to users.20 The concept of an anonymous
`login account caught on as a way to permit FTP access to users who did not have an account and
`remains a central feature of FTP to this day.
`
`Page 4
`
`Page 00004
`
`

`

`4.2 First User Agents
`The second development of 1972 and 1973 was the creation of tools to create and manage email.
`Here the center of innovation was within the Advanced Research Projects Agency (ARPA) itself.
`Larry Roberts, head of the ARPA office funding ARPANET, was an early and aggressive user of
`email. Early in 1972, Stephen Lukasik, the head of ARPA, also began using email and that
`induced a number of others, including the ARPA department heads, to use email too.21
`Soon Lukasik became frustrated with READMAIL, which forced him read through all the
`messages in his mailbox in order. Lukasik liked to keep copies of email he received, which
`made the problem worse. He appealed to Roberts for something better.
`One night in July, Roberts wrote a tool using macros for the TECO (Text Editor and COrrector22)
`text editor to manage a mailbox.23 The tool was dubbed RD. RD made it possible to list the
`messages in the mailbox, to pick which message to read next, and to print individual messages.
`Roberts’ colleague at ARPA, Barry Wessler, promptly rewrote RD as a standalone program in
`the programming language SAIL and added additional features for usability. Improvements in
`Wessler’s “New RD” or NRD included the ability to manage more than one file of messages,
`and mechanisms to file, retrieve, and delete messages. RD and NRD were the first mailbox
`management tools, the first true User Agents.
`Wessler’s NRD was not distributed outside ARPA. (RD was.) In early 1973, Martin Yonke was
`a graduate student intern at the University of Southern California’s Information Sciences
`Institute (ISI) and looking for something to do. Steve Crocker of ARPA gave Yonke a copy of
`Wessler’s code (which ran on TENEX) and suggested Yonke look at improving it. Yonke added
`command completion (type the first letter or two of a command and the rest of the name would
`be filled in) and a help interface. A user could type a question mark in most places in a
`command to learn what the choices were. The revised NRD was dubbed BANANARD.24 (At
`the time, “banana” was technical slang for “cool” or “better”). Yonke distributed and maintained
`BANANARD for a bit less than a year though it remained in use for several years more.
`There is at least one fun story from that year. BANANARD kept an index of messages in a file
`so Yonke had to estimate how big the index (which was read into memory) might be. Yonke
`estimated the largest possible mailbox size, doubled that, and concluded that assuming a mailbox
`was never larger than 5,000 messages was safe. Steve Crocker exceeded the limit within a few
`months. So did John Vittal.25
`One of the challenges in RD and NRD was that there was still no standard format for email
`messages. Headers varied. It was hard to find where one message ended and the next one
`started. Wessler remembers trying to get NRD to find the start of headers but it was too hard
`because messages routinely had other messages embedded in them. Therefore, NRD (and RD
`and BANANARD) relied on the receiving system to place a start-of-message delimiter before
`each message in the mailbox.26 The delimiter had four SOH (Start Of Header, also known as
`Control-A) bytes followed by information about the message (initially just a byte count, later
`somewhat more information).27 In one of those odd quirks, part of the start-of-message delimiter
`has lived on. While some present-day email systems parse for a header, others still expect
`messages separated by a line with four consecutive SOH bytes.
`
`Page 5
`
`Page 00005
`
`

`

`4.3 Transitions
`In March 1973, another meeting about FTP was held, to try to clarify issues lingering from the
`April 1972 meeting. It marks a subtle transition.
`Originally, clarifying and improving the support for email in FTP was part of the agenda.28 Yet
`the meeting was ambivalent. Prodded by a late-in-the-meeting arrival of Steve Crocker of
`ARPA, who asked how they were doing on email support, the group decided to formally
`incorporate the MLFL and MAIL commands into the new specification29 (Recall the commands
`had previously been in a separate addendum). Between the meeting and the issuances of the new
`FTP specification, it was decided that email should really be a separate, auxiliary protocol.30
`Email had become important enough (or complex enough) to merit distinction.
`Second, the community was shifting. Though both meetings had over twenty attendees, they
`were different sets of people. Only five people31 attended both meetings.32 Abhay Bhushan, who
`had been driving the development of and writing the specifications for FTP, would soon move on
`to other things. Nancy Neigus of BBN wrote the new FTP specification.
`The research focus was also changing. By year’s end, Larry Roberts (probably email’s most
`important early adopter) would leave ARPA, and under his successor, Bob Kahn, ARPA’s
`networking focus would change to developing networks over media other than telephone wires
`(e.g. satellites and radios) and the problems of interconnecting those networks.
`Finally, at least from a standards perspective, the protocol for delivering email enters a kind of
`limbo. The auxiliary protocol specification for email envisioned in the new FTP specification
`never appeared. After three years, Jon Postel wrote a two page memo which never appeared on-
`line, documenting the, by then well-established, practice of using MAIL and MLFL. The memo
`suggests some sites had not bothered to update their FTP from before the 1973 FTP meeting.33
`There were multiple attempts to allow FTP to send a single copy of a message to multiple
`recipients. All of them apparently failed.34 It would take seven years from the FTP meeting
`before the community seriously returned to the problems of a new email protocol.35 Innovation
`over the next few years would come from user agents and a long-running debate over the format
`of email messages, especially email headers.
`5 The Rise of the User Agent
`In early 1974, John Vittal worked in the office next door to Martin Yonke’s office at ISI. Vittal
`had helped Yonke with BANANARD, and about the time Yonke stopped working on
`BANANARD so he could finish his graduate degree, Vittal took a copy of the code and began to
`think about building an improved user agent.
`5.1 MSG
`Vittal called his new program MSG. In it he sought to write a user agent that was simple yet did
`all the things a user needed it to do. It had roughly the same functionality as BANANARD, but
`the structure of its commands reflected feedback Vittal sought out from users about how they
`wanted to manage their email. MSG was a personal effort by Vittal (writing code on nights and
`weekends) and when he left ISI for BBN in 1976, he took MSG with him.
`
`Page 6
`
`Page 00006
`
`

`

`MSG was, in fact, surprisingly simple. It was a stand-alone program with its own set of
`commands. There were just 30 commands, named such that their first letter uniquely identified
`all but six. Combined with a command-completion scheme, this usually-unique-on-first letter
`approach permitted concise typing by experienced users. (Many early computer users were hunt-
`and-peck typists, so keeping commands to a letter or two in length was a big timesaver).
`Of these 30 commands, several were new from BANANARD. Some were minor, such as a
`command to toggle the user interface between a concise and a verbose mode. However, three
`commands reflect important changes:
` move reflected Vittal’s attention to user behavior. He noticed that one of the most
`common activities was to save a message in a file and then delete the message from the
`inbound mailbox. Vittal created the combined save/delete command, move.
` answer (now usually called “reply”) is widely held to be Vittal’s most insightful and
`important invention. Answer examined a received message to determine to whom a reply
`should be sent, it then placed these addresses, along with a copy of the original
`SUBJECT field, in a responding message. Among the challenges Vittal had to solve
`were the varying email addressing standards and what options to give a user (reply to
`everyone? reply only to the sender of the note?). It took three implementations to get
`right.36
`The wonder of answer is that it suddenly made replying to email easy. Rather than
`manually copying the addresses, the user could just type answer and reply. Users of the
`time remember the creation of answer as transforming – converting email from a system
`of receiving memos into a system for conversation. (There are anecdotal reports that
`email traffic grew sharply shortly after answer appeared37).
`forward provided the mechanism to send an email message to a person who was not
`already a recipient. How much of an innovation forward was is unclear. Barry Wessler
`had to struggle with messages embedded in messages in NRD. But the formalization of
`the idea was new.
`MSG became the ARPANET’s most popular user agent and remained so for several years.
`5.2 HERMES and MH
`About the same time Vittal was starting work on MSG, Steve Walker at ARPA created a new
`committee called the “Message Services Committee,” charged with thinking about email issues.
`Its focus was on user agents (Al Vezza of MIT remembers a push to get user agents to support
`command completion) and email headers. In the summer of 1975, Walker also created the
`MSGGROUP mailing list, to encourage greater discussion.38
`Motivating these efforts was an ARPA program called the Military Message Experiment (MME)
`to make email into a useful service to the military. As part of this program, between 1975 and
`1979, ISI, BBN and MIT (in an advisory role) sought to create user agents designed for the needs
`of the military. The initial goal was a system for personnel at the office of the Navy Commander
`in Chief for the Pacific (CINCPAC)39. In a related effort, RAND Corporation was funded to
`develop a UNIX email user agent.40
`
`
`
`Page 7
`
`Page 00007
`
`

`

`Hermes (a BBN project) and MH (at RAND) were products of this program. Another system,
`called SIGMA was developed by ISI for CINCPAC but never used elsewhere. They illustrate
`some of the diversity of user agents of the time. (An interesting side note is that John Vittal
`worked on both SIGMA and Hermes, while continuing his work on MSG. So Vittal’s personal
`project was competing with the in-house official product. At both ISI and BBN, MSG won.)
`Hermes was designed for an office (or command) environment where much of the email received
`was kept for reference. It contained a sophisticated set of mechanisms for filing and searching
`for messages, including a database that recorded key fields from each message to make searches
`fast. Hermes also provided a high degree of customization. Readers could create a template of
`how messages should be displayed, how they should be printed, and even how they should be
`created (what fields a user should be prompted for). To support this customization, Hermes had
`a per-user configuration file (called a profile) remembered as having been large and complex,
`though documentation suggests it was far simpler than the MH profile file became by the mid-
`1980s.41 Initially known as the MAILSYS project, the Hermes team at various times included
`Jerry Burchfiel, Ted Meyer, Austin Henderson, Doug Dodds, Debbie Deutsch, Charlotte Mooers
`and John Vittal.
`MH (“Mail Handler”) was the successor and response to an earlier RAND system, called MS.
`MS was a user agent for the UNIX operating system (apparently the first UNIX user agent). MS
`was funded by Steve Walker at ARPA and was created by William Crosby, Steven Tepper and
`Dave Crocker.42 MS’s defining characteristic appears to have been that it supported multiple
`user interfaces, including one that sought to mimic a UNIX command shell and another that
`mimicked MSG.
`Soon after MS was working in 1977, Stock Gaines and Norm Shapiro of RAND wrote an
`internal memo suggesting that MS was inconsistent with the style of other UNIX programs.43
`UNIX encouraged the use of many small programs each of which did something well and
`creating meta-programs by combining the small programs together using a mechanism called
`“pipes.”44 Gaines and Shapiro suggested the same approach for email: a set of small programs
`that managed email, where email messages were stored as separate files in a user’s directory.
`Two years after the memo, a new RAND employee, Bruce Bordon, was assigned to upgrade MS.
`He recommended to his management that rather than upgrade MS, he should implement Gaines
`and Shapiro’s idea. The result was MH.
`The virtue of MH is that it makes email part of the user’s larger environment.45 Output of email
`display programs can be filtered through search programs such as grep or simply sent to the
`printing program. MH, in some ways anticipated today’s world, where clicking on an
`attachment opens the correct program. Culturally, in UNIX, rather than clicking on an
`attachment, one pipes data from one program to the next to produce the desired result.
`Because MH puts every message in a separate file in a folder (directory), it is easy to manipulate
`both individual messages and folders. Accordingly, MH (unlike MS46) has powerful tools to sort
`folders and to search, mark, and label messages.
`Through most of the 1980s, MH was maintained by Marshall Rose, with help from a number of
`people, most notably John Romine, Jerry Sweet and Van Jacobson.47 Others have picked up the
`task since and MH (much evolved in its code, but still recognizable as Bordon’s suite of
`programs) continues to be widely used today.
`
`Page 8
`
`Page 00008
`
`

`

`6 Message Formats and Headers
`When Ray Tomlinson sent his email between TENEX systems, he used a format similar to a
`business memo. But there was no standard format for email messages and creating and revising
`standards for email message formats would consume a tremendous amount of effort over the
`next several years.
`6.1 First Message Format Standard
`Abhay Bhushan, Ken Pogran, Ray Tomlinson and Jim White (of SRI) took the first step to
`standardize email headers in RFC-561, published in September 1973.48 Their proposal was mild.
`Every email message should have three fields (FROM, SUBJECT and DATE) at the start.
`Additional fields were permitted, one per line, with each line starting with a single word (no
`spaces) followed by a colon (:). The end of this header section was marked by a single blank
`line, after which came the contents of the message.
`The proposed standard was both forward looking and lacked some basic features. The ability to
`make any word into a header field was progressive and left plenty of room for experimentation.
`The date field was surprisingly precise, specifying the time to the minute and the time zone. The
`blank line after the header remains a feature of email today. Yet there was no TO field, so a
`recipient wouldn’t necessarily know who else was to receive the message and, while use of the
`@ sign was already common, the address format required using the word “at”, as in
`TOMLINSON AT BBN-TENEX, with the odd consequence that for several years, people would
`send emails using “at” in the FROM (and soon, TO) field and yet within the message itself list
`their email address with an “@”.
`6.2 Partial Progress
`In 1975, a team of people working on email systems at BBN sought to update RFC-561 with
`RFC-680.49 The work was produced under the auspices ARPA’s Message Services Committee.50
`The RFC authors were Ted Meyer and Austin Henderson but email on the MSGGROUP mailing
`list suggests Charlotte Mooers51 also played a major role. RFC-680 set out to document a large
`number of fields, many of which were already in widespread but informal use, and to standardize
`their formats in a way that computer programs (e.g. User Agents) could easily parse.
`That the header standard needed updating was becoming increasingly clear. Jack Haverty
`offered the following example from his time maintaining the MIT-ITS mailer.
`“[A] field like ‘To: PDL, Cerf@ISIA’ was ambiguous was ‘PDL’ really
`‘PDL@ISIA’ (picking up the host from the end of the line)? Or was it
`‘PDL@MIT-DMS’ (picking up the host from the ‘From: JFH@MIT-DMS’
`elsewhere in the header)?
`Various mail programs adopted different such ‘abbreviations’ which drove me
`crazy…. To handle all of this protocol chaos, I wrote (and rewrote, and tweaked)
`a sizable (for a LISPish world) chunk of code to try to deduce the precise meaning
`of each message header contents and semantics based on where the message came
`from. Different mail programs had different ideas about the interpretation of
`fields in the headers.
`
`Page 9
`
`Page 00009
`
`

`

`That code first tried to figure out where an incoming message had come from.
`This was not so obvious as it might seem because of redistribution and forwarding
`of messages, and differences in behavior of various versions of the other guy's
`software. So it wasn't enough to just look to see if you were talking to MIT-
`MULTICS. I remember having conditional clauses that in essence said ‘If I see a
`pattern like such-and-such in the headers, this is probably a message from version
`xx.yy of Ken Pogran's Multics mailer.’ With enough such tests, it formed an
`opinion about which mail daemon it was talking with, and which mail UI program
`had created a message.
`Having hopefully figured out the other guy's genealogy (and therefore protocol
`dialect), the code then acted based on a painfully collected set of observations
`about how that system behaved.”52
`RFC-680 is notable for documenting the increase in header fields that had taken place over two
`years. It defined a number of widely used but not standardized header fields, including most
`notably, the TO field, but also CC (carbon copy), BCC (blind carbon copy), IN-REPLY-TO,
`SENDER and Message-ID. Introduction of the TO field meant a format needed to be chosen for
`sending to multiple recipients. The proposal called for multiple email addresses in a field
`separated by commas. The RFC also documented the use of @ instead of “at”.
`RFC-680 was a clear step forward from RFC-561. Still, RFC-680 had limitations. It was based
`on practices on TENEX systems, which were not always representative of the ARPANET
`community as a whole. (For example, the decision to separate addresses in the TO field with
`commas was a TENEX convention). Its syntax had bugs (it unintentionally permitted “@” and
`comma in mailbox names). Furthermore, pragmatically, RFC-680, while intended to become a
`standard, was never officially issued as a standard.53
`In addition, RFC-680 revealed a philosophical split between members of the Message Services
`Committee. The MIT members (Al Vezza and Jack Haverty) felt email headers were primarily
`of use to the email handling programs and should be designed to be machine-readable. Others
`felt that headers should focus on being human readable. RFC-680 tried to strike a compromise,
`which apparently pleased neither side.54
`The result was confusion. Some sites updated their mailers to conform to RFC-680 while others
`continued to follow RFC-561.
`6.3 A New Standard
`Sometime in 1976, the Message Services Committee was replaced by the ARPA Committee on
`Human-Aided Communication.55 One of the new committee’s early actions was to seek to
`clarify the state of standards for email message formats. A vigorous email discussion on the
`HEADER-PEOPLE mailing list in the fall of 1976 led to a new proposed standard in RFC-724
`(“Proposed Standard for Message Format”) written by Ken Pogran (MIT), John Vittal (now at
`B