On mail service to CCN
Robert Braden explains UCLA's mail policy and proposes extensions to FTP mail.
Braden, R.T., "On mail service to CCN", RFC 498, DOI 10.17487/RFC0498, April 1973, <https://www.rfc-editor.org/info/rfc498>.
@misc{rfc498,
series = {Request for Comments},
number = 498,
howpublished = {RFC 498},
publisher = {RFC Editor},
doi = {10.17487/RFC0498},
url = {https://www.rfc-editor.org/info/rfc498},
author = {R.T. Braden},
title = {{On mail service to CCN}},
pagetotal = 3,
year = 1973,
month = apr,
} RFC text
NETWORK WORKING GROUP ROBERT T. BRADEN
RFC #498 UCLA/CCN
NIC #15715 APRIL 17, 1973
ON MAIL SERVICE TO CCN
Most of the recent documents on mail protocols have discussed the
facilities desired at "post-office" hosts, i.e. those which provide
store-and-forward services. CCN has no plans to provide post-office
services; we expect to receive mail only for the staff of CCN. Our
greatest concern is to get messages reliably to and from our
administrative and user support people who don't habitually use on-line
terminals, so we are printing out all mail and distributing it by
courier/secretary.
Let me say a friendly word for SNDMSG. This Tenex command, which
uses the FTP MAIL command to deliver messages, is very simple but
extremely useful--probably because it is so simple. Furthermore, it is
one of the well-kept secrets of the Network that SNDMSG can be used to
send messages to any host which supports the MAIL command (without
requiring logon to FTP). Thus, to send a message to anyone at CCN, the
recommended procedure is to do SNDMSG to "name@CCN". This connects to
CCN's FTP and sends a "MAIL name" command followed by the message. We
now accept any "name" and print an immediate upper-case copy which is
distributed to the recipient's office. So, if you SNDMSG to
"BRADEN@CCN", your message will end up on my desk, usually within a few
hours. Other useful SNDMSG destination at CCN are:
WBK@CCN or KEHL@CCN (the Director)
RIB@CCN or BELL@CCN (Supervisor Of User Relations)
BBN@CCN or NOBLE@CCN (Barbara Noble, User Consultant)
This fine service is brought to you by your friendly neighborhood Tenex.
On the other hand, the Tenex READMAIL command is a little too
simple. After giving you a message, it should ask you whether you want
to delete, keep, forward, and/or repeat the message.
Dave Crocker of NMC has suggested an extension to the MAIL and MLFL
(Mail File) commands in CCN's FTP to allow CCN to serve as a mail
delivery station for NMC as well as CCN. This extension is intended to
be a trivial subset of the full-blown mail protocol which is currently
being developed by Jim White et al. It is a simple means to allow CCN's
high-speed printers to be used conveniently for receiving and
disseminating Network documentation as well as messages. It is based
upon extensions of the pathname/user name fields in the MLFL/MAIL
commands, respectively. The proposed syntax is as follows:
__ __
| |
| ;D[DOCUMENT] |
| ;M[MESSAGE] |
<userid> | ;C[COPIES]= <integer> |
| ;BIN= <integer> |
|__ __|
The semantics would be:
(1) <userid> will normally be a valid TSO userid; this will be used
to determine a charge number to account for the
printing. If <userid> is _not_ recognized, the rest of
the parameters will be ignored, but the mail will
still be accepted. The result will be to print one
copy immediately in upper case and send it to Bin
9906, charging it to an overhead account.
(2) MESSAGE means print a copy immediately using the normal
upper-case-only train. This is the default.
(3) DOCUMENT means enqueue the text for overnight printing with an
upper/lower case print train. A message indicating
receipt (and perhaps the first block) will also be
printed immediately in upper case and distributed.
(4) COPIES makes multiple copies. [This facility will not be
available immediately].
(5) BIN specifies CCN bin to receive output. Default will be
9906 (ARPA mail bin).
Each incoming message will be time-and-date-stamped. The time/date
will appear on the first page of the message (on a separate page in the
case of upper/lowercase), in the 256 acknowledgment message from FTP,
and on our system log file. This time/date stamp may be useful for
users to keep tabs on their documents, and to allow us to track down
missing messages. The semicolon and equal sign delimiters of this syntax
are acceptable in the "user" parameter to SNDMSG.
This extended MAIL syntax will be implemented by June 1.
RTB/gjm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 9/99 ]
AI ELI5
On this page
§1UCLA's Mail Policy
RFC 498 is Robert Braden's statement on UCLA Computing Center's approach to network mail. UCLA does not plan to be a full mail post office hosting accounts for other sites. Instead, it receives mail only for its own staff, prints all messages immediately, and delivers them by courier or secretary within a few hours. This policy is designed to keep administration simple and support the center's administrative and user support staff who do not regularly use online terminals.
The computer center said they would only accept letters for their own people, print them on paper, and have someone deliver them in person.
§2The SNDMSG Command
Braden praises the TENEX SNDMSG command as exceptionally useful despite its simplicity. SNDMSG uses FTP's MAIL command to send messages without requiring the sender to log into FTP. To send a message to a UCLA user, one types SNDMSG to "name@CCN", which connects to UCLA's FTP, issues a MAIL command with the recipient's name, sends the message, and disconnects. This elegant approach does not demand a password or authentication, making it accessible to any network user. UCLA accepts any name format and prints upper-case copies immediately for distribution.
A simple command lets anyone on the network send a message to anyone at UCLA without passwords or complicated steps.
§3Proposed FTP Mail Extensions
Braden proposes extending FTP's MAIL and MLFL commands with optional parameters in the user-name field, separated by semicolons. Parameters include ;MESSAGE (print immediately in uppercase, the default), ;DOCUMENT (queue for overnight printing in mixed case), ;COPIES (future feature for multiple copies), and ;BIN (specify the output bin, defaulting to bin 9906 for ARPA mail). Each message is time-and-date-stamped for tracking. These extensions allow UCLA to provide proper accounting, handle different message types appropriately, and manage output routing.
The mail commands were extended with special instructions like whether to print right away or save for later, how many copies to make, and where to put the output.