In the process of cleaning out boxes of old paperwork, I found this company memo, circa early 1980s, that describes a “simpler” way to send email. At the time, email systems were mainframe-based text systems you logged onto and typed at — actually not terribly unlike the web-based email systems today.
The memo reminds me of how it was back then and of how far we’ve come since. Here it is, reproduced as is:
Purpose: Prepare an entire message “off-line” and then transmit it to
EZ-Mail. This way you can use your word processor and also reduce “on-line” time. In fact, if your communications software package can be programmed (e.g. with scripts or macros), you can set the entire sign-on, upload, and sign-off procedure to occur without your even being there.
WARNING: This is an advance command for special purpose use only. The simpler alternative is to prepare the text portion of your message “off-line” and transmit it to
EZ-Mail at the Enter Message prompt (while
How it works:
UPLOAD requires that you have a personal computer or intelligent terminal with software that allows you to send and receive messages (sometimes called files).
It is important that the message be formatted in a special way for
UPLOAD to work properly and that it be ASCII. The format is:
/* BEGIN TO : username1,username2 CC : SUB: Test upload Put the data here. .END /* BEGIN (optional - repeat for every additional message) TO : username3,username1 CC : username5 username6 username9 SUB: Test 2nd message upload Put data for 2nd message here. .END /* END
It is very important that everything is printed with a left margin of “0”. If
EZ-Mail doesn’t see the “/*” and “.end” in the first colum, it ignores everything.
If you are unfamiliar with sending and receiving files, consult your communications software documentation. Most word processors will generate an ASCII file/message.
All sorts of things occur to me about this…
I’m first struck by the very odd dual syntax of the meta-commands. In one case we have the /* syntax, but also .END (which is typed as .end in the memo text — a typo or is the command case-insensitive?).
The reality is that the .END command is superfluous, there’s no real need for it. Message text can end with either a new /* BEGIN or an /* END command. Not that the syntax thrills me. Is a space required? Are multiple spaces allowed?
It’s quite possible some outer wrapper handles the /* commands while an inner function processes message text up to an .END command. Still, not a well-designed system, even for the day!
If it had been me, I’d have just used .BEGIN and .END with a final .QUIT to end processing. (And, of course, case-insensitive. Duh.)
I’m also struck by the use of commas in both TO lines, but not in the CC line. That could be a typo on the memo author’s part. The question of parsing delimiters isn’t always as simple as it seems.
Commas and spaces can be treated as identical with multiple contiguous commas or spaces compressed into a single delimiter. Under that protocol, the following are identical:
name1 name2 name3 name1,name2,name3 name1, name2, name3 name1,, name3 nameX
This works well when the input text contains no spaces (typically true of code, for example) and there is no need to detect empty fields.
But in the fourth example above, the two commas imply an empty field (“name2”). Yet treating spaces as a delimiter makes it hard to determine how many empty fields might come before the last field. When empty fields are possible, use a visible delimiter!
I also wonder about the space between the TO and the : — the same curious syntax exists for the CC field. Is it optional? Required?
Note also the blank line between the TO, CC, SUB fields and the text. This is how the underlying SMTP mail protocol actually works, but the memo doesn’t mention how crucial — or not — that blank line is (which, of course, makes me wonder if it is).
The whole thing “EZ-Mail” thing could have been just a front end with an SMTP backend. I barely remember the system at all, and in any event I was just a user, not a designer or builder on it.