[mailhist-discuss] First email attachment?
jack at 3kitty.org
Sun Mar 12 18:56:16 PDT 2017
On 03/12/2017 03:48 PM, Dave Crocker wrote:
> Was there any distinctive/standard packaging and/or encoding?
Short answer - Nope.
In COMSYS, to send an attachment, you (your mail client) would simply
add a FILE attribute to the message as you composed it. That attribute
simply specified the file location in a site-standard format. All
attributes, including the message body, were placed into the COMSYS
COMSYS was a system which viewed messages as records in a database, with
a variety of attributes changing over time: TO, FROM, TIME-SENT, etc.
For intra-site mail, sending a message involved simply putting the
intended addressees into the TO attribute, and appending "SENDING" to
the PROCESSING-NEEDED attribute. The COMSYS daemon worked off the
PROCESSING-NEEDED changes as a work queue, and did the associated work.
Usually that was SENDING, but it could also be things like "ARCHIVE"
which copied the message into the DataComputer.
So, for intra-site messages, there was no need for packaging or encoding
attachments. The message simply pointed to them using the FILE
attribute, which was made visible to the recipient on SENDING, and the
recipients' mail clients would go get them when desired. No encoding
Within the ITS systems world at MIT, a network file system of sorts was
developed, permitting users on one machine to access files across the
ARPANET on another ITS machine as if the file was on a local disk. So,
for example, I could send a message, from my DM machine, with an
Enclosure that referenced a file on the AI machine. E.g.,
"DSK:JFH;ENCL01" would be a file on the local disk. But "AI:KLH;KENENC"
would be a file on the AI machine.
So within the ITS sites, you could send Enclosures in mail that attached
files from a different machine than the one you're sending from. How
that fits in to the mail taxonomy and the notion of "encoding" for
transmission over a network is left as an exercise.
For generic ARPANET inter-site recipients, COMSYS had a bit more work.
SENDING involved creating the appropriate RFC-compliant headers from the
information in the attributes and prepending them to the message body.
Enclosures were assumed to be ascii, and were simply copied from the
associated file and appended to the message body, with a little
separator that said something like "Enclosure follows". That's the best
I could think to do. There weren't a whole lot of standard file
formats. Even text was still not quite nailed down. But I think we
had finally gotten out of the era when individual messages were
terminated by carriage-return, period, carriage return.
For receiving messages, the situation was a lot worse, since every site
and mail program out there seemed to have its own ideas about the format
and meaning of the header fields it created. I remember painfully
writing pages of Muddle code (which is a lot, most functions took less
than a page of code), which tried, and failed, to reliably get the
incoming header contents into database attributes correctly by trying to
deduce the genesis of each message to decide which heuristics to apply.
It was mind-blowing to receive a message which had been forwarded or a
reply and there were layers of header fields to try to correctly understand.
This led to years of arguments on HEADER-PEOPLE and other venues about
"simple" versus "complex" mail protocols.
It's been 40 years --- I still think that messages as database objects
makes a lot of sense....
More information about the mailhist-discuss