Summary of computer mail services meeting held at BBN on 10 January 1979
Summary of a 1979 meeting on unifying the chaotic state of ARPANET email.
Postel, J., "Summary of computer mail services meeting held at BBN on 10 January 1979", RFC 808, DOI 10.17487/RFC0808, March 1982, <https://www.rfc-editor.org/info/rfc808>.
@misc{rfc808,
series = {Request for Comments},
number = 808,
howpublished = {RFC 808},
publisher = {RFC Editor},
doi = {10.17487/RFC0808},
url = {https://www.rfc-editor.org/info/rfc808},
author = {J. Postel},
title = {{Summary of computer mail services meeting held at BBN on 10 January 1979}},
pagetotal = 8,
year = 1982,
month = mar,
} RFC text
Contents
Network Working Group J. Postel
Request for Comments: 808 ISI
1 March 1982
SUMMARY OF COMPUTER MAIL SERVICES MEETING
HELD AT BBN ON 10 JANUARY 1979
Introduction:
This note is a very belated attempt to document a meeting that was
held three years ago to discuss the state of computer mail in the
ARPA community and to reach some conclusions to guide the further
development of computer mail systems such that a coherent total mail
service would continue to be provided.
Some important conclusions were reached at this meeting which limited
the extent to which mail systems were to incorporate new features in
the context of the existing service and specifications.
Unfortunately, this meeting and the conclusions were not documented,
and the specifications were not revised. This has led to continuing
problems in the mail service.
Due to the passage of time these notes are necessarily quite
incomplete. It is thought that there were a number of other
attendees. I would like to express my appreciation to those who
helped provide this information, especially Vint Cerf, Jack Haverty,
Danny Cohen, Bob Thomas, and Debbie Deutsch.
The Meeting Announcement:
On 10 January 1979 we are holding a meeting at BBN in Cambridge, MA,
starting at 0930, to discuss Message Service support on the ARPANET.
The purpose of the meeting is to provide a basis for any
standardization of efforts which may be necessary. We will take
stock of the various message services currently available on the
ARPANET, discuss problems which have been encountered between
different message systems, review current protocols and review
forthcoming developments. An agenda is given below. Each of you
should be prepared to discuss current problems you are aware of and
any developments which impact future message service.
RFC 808
The Meeting Agenda:
1. Present State of Affairs
. Survey of Message Systems
. Current Problems
. Format Protocols - RFC 560, 680, 733
. Distribution Service
. Documentation
2. Future Developments in Message Technology
. Multi-Media Techniques
. Impact of Personal Computers
. Distributed Service
- NSW Project
- Internetwork Addressing and Forwarding
. Other
3. Impact of Charging Technology on the Message Service
. Protocols
. Distribution of Messages
4. Managing the Message Service
5. Supporting the Message Service
Talks:
1. Duane Adams opened the meeting. He indicated that we should be
concerned about computer mail as a total message service (not just as
a local user interface), and asked what impact on the message service
the developments in internetting and multimedia would have.
2. Dave Farber gave a bit of history of mail systems, listing the
names of all the systems anybody had every heard of (see Appendix A).
It was noted that most of the mail systems were not formal projects
(in the sense of explicitly sponsored research), but things that
"just happened".
3. Ted Myer chaired a discussion of current problems in mail
systems, and the following made comments as well: R. Stallman,
D. Farber, P. Santos, K. Harrenstien, R. Kunzelman, T. Knight,
B. Thomas, D. Lebling, J. Haverty, D. Cohen, D. Adams, V. Cerf, and
A. Vezza.
This was mostly gripes about what this or that mail system did
wrong.
Topics included use of MLFL instead of MAIL, fully qualifying
the all the usernames with hostnames on all the addresses,
immediate feedback about the addressed user having a mailbox at
the destination host or getting an error message later, host
RFC 808
table update problems, strange FTP replies (e.g., "System going
down in 10 minutes"), and addressing issues.
There were also some things mentioned that might be added to the
current systems.
Topics included virtual hosts (e.g., NSW), internetted hosts,
authentication, message identification, duplicate detection,
spoofing, multicopy delivery, limits on receipt, program to
program mail, structured typed data, graphics, fax, and voice.
At the end of this session there was a statement that further work
was putting patches on patches and that we should make a
commitment to a version 2 system. There should be an edict that
says "this is it", and the current mail service should be frozen.
4. Debbie Deutsch talked about some work being done at BBN on
multimedia mail.
Debbie discussed the alternatives for including other types of
data (voice, graphics, fax, numeric, executable) in messages, and
for structuring messages to identify and interrelate the different
types of data. The main choice to make is between encoding the
data in ASCII and using keyword field identifiers, or using a
binary typed structured format. The current work is attempting
integrate fax data handling into an existing text mail system.
Copies of the viewgraphs were distributed.
5. There was a discussion of Personal Computers.
Tom Knight gave a short discription of the Lisp Machine project.
There was some general discussion of the impact of personal
computers on mail services. The main realization being that the
personal computer will not be available to handle incoming mail
all the time. Probably, personal computer users will have their
mailboxes on some big brother computer (which may be dedicated to
mailbox service, or be a general purpose host) and poll for their
mail when they want to read it. There were some concerns raised
about accountability and accounting.
6. Bob Thomas talked about the ideas for routing mail between
regular mailboxes on ARPANET Hosts and mailboxes of NSW users.
The main point of interest is that an NSW user is not a user of a
specific host, thus, the notion of a mailbox being "user@host"
dosen't work. Bob suggested that one might think of NSW as a
virtual host. The implementation of this mail service for NSW
RFC 808
users is constrained to minimize the amount of new code and
changes to existing programs. Bob described his ideas for address
formats for sending messages between NSW users, from NSW users to
ARPANET users, and from ARPANET users to NSW users. The last
being the most difficult to pull off. Copies of the viewgraphs
were distributed, and copies of a memo were distributed (BBN NSW
Working Note 24).
7. Jon Postel talked about the ideas he had for internet multimedia
mail systems.
Two aspects of this were a general approach to addressing and
routing for mail distribution, and using a structure of typed data
elements to represent the message data and control.
8. There was some discussion of other work in mail services.
Someone talked about the work of ANSI X3 S33 on message structure
and protocol.
Dave Farber described the activities of IFIP TC 6.5 on
international message services.
Ted Myer described the interests of the US Congress Office of
Technology Assesment (OTA) in electronic communication.
General Discussion:
It was suggested that we need to view the problems in building a
total message service rather than individual message systems.
In general it was felt that the current message service was somewhat
out of control with incompatible varations and extensions. There
were several instances where a minor change to one mail system led to
unexpected problems in another mail system.
In part, the reason for this seemed to be the varations allowed by
the protocol, and especially the partial implementation of the
protocol by most systems.
The general approach to resolving these problems was two fold:
First, a few minor further changes were to be allowed, but in
general full implementation of the protocol (RFC 733) was not to
be carried out. In case of questions about a particular change
Duane Adams was to decide if it would be allowed ot not. The goal
in this approach was to quickly stabilize the mail service in a
useful state.
RFC 808
In particular, if a small number of senders are doing something
that is incompatible with the total service, they will be asked
to stop doing it. Or, if a small number of receivers can't
handle something that most systems do, they will be asked to
handle that feature.
Second, work was to be focused on the definition and
implementation of a next-generation mail service which would
attack all the existing problems and include facilities for voice,
fax, and graphics data.
The use of structured data in the next-generation mail service was
approved. Jack Haverty noted that RFC 713 specified a language,
MSDTP, that could be used to define a structured mail protocol.
Conclusions:
A. Existing Mail Services
1. Mail shall not be sent between hosts if it breaks existing
mail programs.
Outlawed by this rule are:
a. Spaces in user names.
b. Multiple at signs in mailboxes.
2. Features of RFC 733 that are generally unimplemented shall
remain unimplemented, and are decommitted from the specification.
Outlawed by this rule are:
a. "Include" and "Postal" type addresses.
3. Duane Adams will arbitrate disputes.
4. There shall be no more changes to the MAIL/MLFL FTP reply
codes.
B. New Mail Services
1. New services should be provided in the context of the
experimental multimedia mail systems now being planned.
RFC 808
Action Items:
1. Jon Postel is to circulate a draft specification of a structured
mail protocol by 15-Feb-79.
[* This became IEN-85 published in March 1979 and now superseded
by RFCs 759 and 767. *]
2. Everyone is to submit a 2 to 3 page position paper on addressing
to Duane Adams by 1-Mar-79.
3. Everyone is to submit a 2 to 3 page position paper on System
Architecture and Message Transmission by 1-Apr-79.
RFC 808
Appendix A:
First Preliminary List of ARPANET Mail Systems
Center;by Dave Farber
Mail System Authors Machines
SNDMSG Antiquity Tenex, TOPS-20
READMAIL Antiquity TEXEX, TOPS-20
RD Larry Roberts TENEX, TOPS-20
MSG Vittal TENEX (18 SITES)
HERMES BBN TENEX (14 SITES)
HG Calvin
MAIL Werme TOPS-10 on KA and KL10 CMU
RDMAIL Karlton TOPS-10 on KA and KL10 CMU
COMSAT KLH MIT-MC,-AI,-ML
MAIL/QMAIL (1) KLH MIT-MC,-AI,-ML
BABYL EAK MIT-MC,-AI,-ML
FTPS (2) KLH MIT-MC,-AI,-ML
SIGMA ISI Dedicated TENEX
MAILSTAT (3) BBN TENEX, TOPS-20
FTP (2) BBN TENEX, TOPS-20
MAILER (3) BBN TENEX, TOPS-20
MM MMcM@AI SRI-KL
BANANARD Yonke TENEX
MSG Version 1 UCB - RAND PDP 11 UNIX
SNDMSG (UNIX) UCB - RAND PDP 11 UNIX
MS D. Crocker PDP 11 UNIX
MSG Version 2 D. Crocker PDP 11 UNIX
MH Borden RAND-UNIX
Read-mail (1) Palter & Sibert Multics all
print-mail Palter & Sibert Multics all
send-mail Palter & Sibert Multics all
MSGH Ness at Wharton Wharton 10
Wharton Mail System Ness at Wharton Wharton 10
SWAMP Guyton IBM 370 Wilber
MSG Antiquity HARVARD and RUTGERS 10
MAIL (1) Harvey SU-AI-10
RCV (Mail reader) Harvey SU-AI-10
DMSG (Private) TENEX
READMAIL - LL IBM VM/370
RD Haines LL IBM VM/370
$NETMAIL ? AMES-67
(1) mail sender
(2) FTP server
(3) service system
RFC 808
Attendees:
Name Org Mailbox
Duane Adams ARPA Adams@ISIA
Bill Carlson ARPA Carlson@ISIA
Vint Cerf ARPA Cerf@ISIA
Jerry Burchfiel BBN Burchfiel@BBNA
Debbie Deutsch BBN DDeutsch@BBNA
Jack Haverty BBN Haverty@BBN-Unix
Charles Khuen BBN Khuen@BBNC
Mark Lavin BBN MLavin@BBNE
Charlotte Mooers BBN Mooers@BBNE
Ted Myer BBN Myer@BBNA
Ray Nickerson BBN Nickerson@BBNC
Paul Santos BBN Santos@BBNE
Bob Thomas BBN BThomas@BBND
Mike Wingfield BBN Wingfield@BBND
Joanne Sattley CCA JZS@CCA
Howard Wactlar CMU Wactlar@CMU-10A
James Pool DOE Pool@BBN
Robert McNab DCA DCACode535@ISIA
Ed Cain DCEC Cain@EDN-Unix
Warren Hawrylko DCEC Lyons@ISIA
Harry Helm DCEC Lyons@ISIA
Danny Cohen ISI Cohen@ISIB
Jon Postel ISI Postel@ISIF
Dave Lebling MIT PDL@MIT-XX
Tom Knight MIT TK@MIT-AI
R. Stallman MIT RMS@MIT-AI
Pat Winston MIT PHW@MIT-AI
Al Vezza MIT AV@MIT-DMS
Wayne Shiveley OFDA ---
Bob Anderson RAND Anderson@RAND-Unix
Ken Harrenstien SRI KLH@SRI-NIC
Ron Kunzelman SRI Kunzelman@SRI-KL
Dave Farber UDEL Farber@UDEL
AI ELI5
On this page
§1The Problem: Incompatible Mail Systems
This document, written in 1982, records a meeting held at BBN in Cambridge, Massachusetts on 10 January 1979. At that time, email was supposed to be a unified service across the ARPANET, but it had become fractured. Each site had built its own mail system—there was SNDMSG, READMAIL, MSG, HERMES, HG, MAIL, COMSAT, BABYL, and dozens more, each on different computers running TENEX, TOPS-10, TOPS-20, UNIX, Multics, or IBM systems.
The problem was that these systems were not fully compatible. Minor changes in one system would unexpectedly break other systems. For example, variations in how mail addresses were written, how FTP servers responded, and how host tables were maintained were causing service failures across the network. The RFC notes that the text mail service was somewhat out of control with incompatible variations and extensions.
Every computer had its own email program, and they didn't agree on how email should work. When one place changed something, it would break email at other places.
§2What Was Breaking Email
The problems were both technical and procedural. Technically, the RFC 733 protocol allowed features that most implementations did not support—features like "Include" and "Postal" type addresses. Since most systems did not implement these, adding them broke compatibility. Other issues included:
- Spaces in usernames caused delivery failures
- Multiple @ signs in mailbox addresses created ambiguity
- Strange FTP server replies (e.g., "System going down in 10 minutes") were misinterpreted as mail delivery errors
- Host table update problems led to mail bouncing
The meeting also heard complaints about missing features people wanted: authentication, message identification, duplicate detection, prevention of email spoofing, multicopy delivery with limits, program-to-program mail, and support for graphics, fax, and voice.
One speaker summed it up bluntly: further work on the current system was just putting patches on patches. A commitment to a version 2 system was needed.
The rules in RFC 733 allowed things that nobody actually used, which confused people. Some formats didn't work across systems. Everyone wanted different new features added, but adding them broke things.
§3The Stabilization Strategy
The meeting concluded that the existing text mail service had to be frozen. No more changes would be made except for a few minor refinements. Duane Adams from ARPA would arbitrate any disputes about whether a change was permitted.
The specific rules were:
- Spaces in usernames and multiple @ signs are forbidden—mail shall not be sent between hosts if it breaks existing mail programs.
- Unimplemented RFC 733 features are decommitted—features like "Include" and "Postal" type addresses would remain permanently unimplemented and were no longer part of the specification.
- No more changes to MAIL/MLFL FTP reply codes—this had been a source of confusion.
The philosophy was pragmatic: stabilize the service in a useful state by preventing incompatible changes, rather than trying to complete the specification.
They decided: no more changes to the basic email system. If a change breaks other systems, don't do it. The leader at ARPA would decide any arguments about what's allowed.
§4The Future Direction
Rather than trying to patch the existing system, the meeting's key decision was to shift focus to a new, structured multimedia mail architecture. New services should be provided in the context of experimental multimedia mail systems, not in the existing text mail framework.
Jack Haverty noted that RFC 713 had specified a language called MSDTP that could define a structured mail protocol. The consensus was that future email should use structured data (typed message components) rather than the plain text approaches that were causing compatibility problems.
The group also assigned action items: Jon Postel would draft a specification of a structured mail protocol, and everyone would submit position papers on addressing and system architecture. These became the foundation for RFC 759 and RFC 767, which defined multimedia mail structures.
Instead of trying to fix the old email, they decided to design something completely new that could handle pictures, voice, and text all organized in a clear structure.
§5The Role of Personal Computers and New Services
The meeting anticipated challenges that would become central to email design for decades. Personal computers were starting to exist, but they would not run all the time. The solution: personal computer users would keep their mailboxes on a larger host computer and poll for mail when they wanted to read it. This is the principle behind POP (Post Office Protocol), developed years later.
Bob Thomas from BBN proposed treating an entire user community (like the NSW—Network Standard Workstations) as a virtual host. Rather than addressing mail to a specific machine, you would address it to the user within the virtual community. The system would then route it appropriately. This idea of virtual addressing remains fundamental to modern email.
The meeting also acknowledged that as mail services became more sophisticated, they needed to ensure compatibility with emerging standards from ANSI X3 S33, IFIP TC 6.5 (international message services), and the US Congress Office of Technology Assessment.
They realized computers wouldn't always be on, so people should check their mail on a central server. Also, email addresses shouldn't be tied to one specific computer—a person should have an address that works no matter where their computer is.