[ih] propagation of early email?

[Jack Haverty]

Hi Miles - glad to see Ken is still around!  His recollections align
with mine.  I remember COMSYS (my mail daemon) and COMSAT (Ken's)
having many interesting "discussions" while handling email, and we
also tortured Ken Pogran's mail on Multics.

You got me thinking and remembering ... I offer the following for
historians to ponder, before I forget it.

IIRC, at some point in the early 70s there was a Committee, I think
formed by ARPA, called CAHCOM - Computer-Assisted Human
Communications.  I was on this Committee, and recall going to a
meeting at BBN.  The goal was to foster thinking about how computers
could be used, in conjunction with the new Arpanet, to help humans
communicate.  Arpa wanted new ideas.   Although there was lots of
discussion, the only concrete notion that emerged was email - but in
the very very broad sense encompassing everything associated with
postal style mail and paper communications.  That could include, for
example, mechanisms such as registered mail, notary publics, escrow
agents, postal money orders, overnight couriers, etc.  Multimedia was
for the future when networks and computers could begin to handle such
onerous tasks.

So, back in the Lab at MIT, I did what every programmer seemed to do
when they didn't know quite what the end product should do for the
human users - I built a platform, upon which Somebody Else could build
whatever specific functionality they could imagine.  That was
"COMSYS".  It was a "mail daemon" that looked more like a general
purpose operating system than anything else, and was built in the
Muddle environment, which meant it could utilize all the neat things
that were in the Muddle and ITS runtime environments.

"Messages" were handled as elements of structured data.  As messages
passed through the system, they could be "processed" by various
functions to do interesting stuff.  Processing could be triggered on
occurrence of events or passage of time, and did not require the
particular user to be even logged in.  Users could even extend the
system by writing their own processing code.

After building the obvious basic functions - queueing and sending
email to remote hosts, placing incoming mail in the addressee's
mailbox, etc., COMSYS was installed as a "system daemon" and served as
the MIT-DM email server as well as a playground for experimentation.
Users could, with just a few lines of Muddle code, write their own
processing routines, and arrange for them to be run on incoming and
outgoing messages, or at a scheduled time.  That made it trivial to do
things like mailing lists, "vacation messages", automatic printing of
mail, etc.

I remember that I wrote a function that interfaced with the CCA
Datacomputer (which happened to be next door, but it was on the
Arpanet so it didn't matter).   The idea was that messages that were
deemed "important" could be automatically submitted to the
Datacomputer for archiving and/or public access.  That worked, but
didn't get used a lot.  The Arpanet link was simply too slow - not
well matched to the unimaginably large capacity of the Datacomputer -
one Terabit!  Probably the biggest obstacle was that SQL hadn't been
developed yet, and getting what you wanted out of the Datacomputer
wasn't easy.

COMSYS acted as a testbed for experimentation with "assisting humans"
in some very innovative ways.  For example... Messages weren't
restricted to human mailboxes.  Processes could have mailboxes
too....and necessity is the mother of invention...

So, one of us (Mike Broos as I recall) wrote a few lines of code, and
created a mailbox for the Muddle compiler.  You (more accurately He,
since he didn't publicize this) could send a message, with his Muddle
code as the body, to that mailbox.  When that message arrived, Comsys
would then run the compiler (no one ever said user-provided processing
functions had to be small or quick).  Compiler runs could take minutes
or even hours.  When it finished, COMSYS would reply to that original
message, sending the output of the compiler, including the object
code, back to Mike.

This was significant "assistance".   At the time, computers were
pretty slow, so running compilations, especially during the busy part
of the day, was somewhat antisocial.  Other people could tell that you
were compiling.  Flames would fly if you were doing it too much.  But
no one knew what COMSYS was doing....but some messages took a very,
very long time to be delivered.    It was even better if you could
email your code to the compiler on a different machine from the one
you were using...which happened too.

Such experiments occasionally blew up.  Labs are dangerous places.
One day I was accosted, as the "COMSYS guy", by people complaining
that they were getting email that wasn't addressed to them, and email
that they sent had gotten lost.  COMSYS had been running for months
with no problems or changes, but suddenly seemed to have gone berserk.
 Wore yet, it was very intermittent.  Most messages were getting
through just fine, but occasionally a few would get misdelivered.  Of
course the hardware was always suspect - memory failures could cause
weird things to happen.  But only COMSYS was misbehaving.

Several hours of electronic autopsy revealed the problem.  One of the
students had read the COMSYS Manual, and learned how to tweak the
system to customize his mail.  So, whenever he sent or received a
message, COMSYS was now applying his code to each message.  So far so
good.

However, his programming project had something to do with complex
arithmetic, and he had personalized his Muddle environment by
redefining basic primitives (like +-*/) to handle complex numbers.
But his code was still buggy.  2+2 didn't equal 4.

When COMSYS ran his message-handling code, it also automatically
loaded his Muddle environment, so his code could be comfortable and
homey.  Unfortunately, COMSYS didn't protect itself.  So, after
processing one of his messages, COMSYS itself subsequently couldn't
add 2 and 2 anymore.   But it still ran - and apparently somehow
managed to deliver subsequent messages, but not to the right person.
After the current queue was emptied it exited, and of course on its
next run it had a fresh brain that could do proper arithmetic.  So
only a few messages got mishandled - every time the student sent or
received mail.  It took a few days to build a "sandbox" inside COMSYS
to confine users' code so they could only blow up themselves.

It didn't occur to me until today that I may have the dubious
distinction of being the first victim ever of an email virus......and
built the first "firewall" for email.

This thread started as a discussion of "propagation of early email".
COMSYS ran only on the MIT-DM machine at MIT in Licklider's group, so
the code itself didn't go very far.   But there were quite a few
students over those years doing projects in that environment, so they
were exposed to the concepts and many of them did experiment using
that email daemon environment.  So who knows what they learned and
where that knowledge went.  Please don't blame me for inventing email
viruses......

I don't recall that there were any RFCs about COMSYS or COMSAT.  Email
historians might want to look up the internal Lab reports for more
artifacts.  I wrote two internal MIT lab reports.  MIT Project MAC,
Programming Technology Division Document SYS.16.00 "MIT-DMS
Communications System Overview" May 15, 1975 and SYS.16.01
"Communications System Daemon Manual".  These were the documents that
provided students and other staff with the details needed to write
experimental "email" code like the few I mentioned above.  It was
interesting to read my old musty copies and see how much of what was
done then has endured to today.  It was a little sad to see how many
of those old ideas never got any further too.

IIRC, no one in that "CAHCOM" group ever suggested that, four decades
later, the most popular computer assisted human interaction would
involve millions of people sending one-liner messages by typing with
only their thumbs.

Very interesting and fun times....

/Jack Haverty
(JFH at 70 - before hosts had names...)
(JFH at MIT-DM - Arpanet days...)
(jack.haverty at alum.mit.edu - now)


On Wed, May 23, 2012 at 9:32 PM, Miles Fidelman
<mfidelman at meetinghouse.net> wrote:
> Jack Haverty wrote:
>>
>> It didn't take long (days, not months) for people to throw together
>> some simple programs to queue email and perform the interactions with
>> the remote FTP server.   There were many such programs at MIT and no
>> doubt elsewhere.  I wrote one to act as MIT-DM's "mail daemon", which
>> became quite elaborate over time.  I recall that Ken Pogran was
>> involved in the Multics email, struggling with the fact that Multics
>> really really didn't like programs that crossed boundaries by writing
>> into someone else's directory.   Someone else (Stallman?  Knight?) did
>> one for MIT-AI.   Ken Harrenstien was also in there, coding away.  Ray
>> Tomlinson tossed @ into the fray, which did two things - it made for a
>> good user interface, and it provided the beginning of structure in
>> messages by enabling addresses to be more-or-less parseable out of
>> what was becoming message "headers".
>>
> Well, I checked in with Ken Harrenstien who reports:
>
> ------ quote ---------
>
> Yeah, more or less.  There were actually two similar systems developed
> at almost the same time.  MIT-DM had something called COMSYS written
> in MDL (Muddle) -- if memory serves me correctly, that was by Jack
> Haverty (JFH).  The one I wrote was called COMSAT, was written in
> MIDAS assembler, and ran on all the other ITS systems (AI, ML, MC, and
> whatever else was later brought to life remotely or virtually).
>
> The ITS systems originally had email limited to their own machine or
> other local ITSes via the JOB device which acted as a sort of NFS;
> this may be what you remember from the 1971 time frame.  True Arpanet
> email using the FTP protocol was very kludgy and didn't really take
> off until COMSAT/COMSYS were developed a couple years later and took
> on the job of queueing messages and delivering them at whatever time
> the destination host happened to be alive.  Both of those systems had
> some unique features that didn't appear elsewhere for quite some time,
> at least until sendmail/unix became popular; for example, they could
> serve as mailing list expanders and one of the first such lists was
> "Header-People".  The traffic was so heavy that I wrote a couple of
> RFCs proposing FTP extensions to reduce the number of message copies
> sent to each host (you can find them via search; those were adopted by
> SMTP) and even implemented them for some non-ITS systems.
>
> ------ end quote ------
>
>
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   .... Yogi Berra
>
>