Mail Transfer Protocol: ISI TOPS20 implementation
How ISI organized an MTP mail implementation for TOPS-20 systems.
Sluizer, S. and J. Postel, "Mail Transfer Protocol: ISI TOPS20 implementation", RFC 784, DOI 10.17487/RFC0784, July 1981, <https://www.rfc-editor.org/info/rfc784>.
@misc{rfc784,
series = {Request for Comments},
number = 784,
howpublished = {RFC 784},
publisher = {RFC Editor},
doi = {10.17487/RFC0784},
url = {https://www.rfc-editor.org/info/rfc784},
author = {S. Sluizer and J. Postel},
title = {{Mail Transfer Protocol: ISI TOPS20 implementation}},
pagetotal = 3,
year = 1981,
month = jul,
} RFC text
Network Working Group S. Sluizer
Request for Comments: 784 J. Postel
ISI
July 1981
MAIL TRANSFER PROTOCOL:
ISI TOPS20 IMPLEMENTATION
We are creating an implementation of MTP for TOPS20. The programs are
written in BLISS-10. This implementation supports the MTP user and
server functions using both TCP and NCP transport services, and provides
interfaces to other mail delivery mechanisms.
The transport services (NCP, TCP, etc.), are used to establish
communication between MTP sender and MTP receiver programs. These
communication paths will be called channels in the rest of this memo.
Our model of operation is that mail sources will create mail files in
user directories. The mail sources are both user mail composition
programs (like Hermes, MM, SNDMSG), and system network mail receiving
programs which accept mail from various input channels. The mail files
are processed by a background program which dispatches mail to various
output channels. There is also a user version of the dispatcher to send
mail at once (provided the necessary channel is available).
To take advantage of MTP's multi-recipient feature, the mail consists of
two files. The first is a control file which contains the delivery
information and a pointer to the second file. The second file contains
the mail data (including the RFC 733 header) to be delivered.
The reason for using two files is that the control information must be
modified as the mail is processed while the mail data only needs to be
read (although the file is eventually deleted or renamed). For example,
a message may be sent to different recipients via different channels.
If one of the channels is not available, the control file must be
modified to mark or delete the recipients to whom the mail has been sent
and keep the recipient information available for those recipients not
yet sent. In a a future implementation of the dispatcher, the control
information may be moved to a master table in its data area to optimally
schedule output channel use.
The dispatcher makes its decision about how to send mail to each
recipient by consulting a table that indicates for each host its ability
to accept mail via (1) MTP on TCP, (2) MTP on NCP, or (3) FTP on NCP
(i.e., the old way). There is also a table for other cases (e.g.,
delivery to hosts in England via another mail transmission system
created by UCL).
Sluizer & Postel Page [1]
ISI TOPS20 Implementation
The individual pieces of this system are:
1. MTP receiver for TCP.
2. MTP receiver for NCP.
3. Dispatcher.
4. MTP sender for TCP.
5. MTP sender for NCP.
6. Mail composition programs (MM, HERMES, MSG, SNDMSG, ...).
7. User mailbox files.
8. Pending Mail files.
9. Other Mail sources.
10. Other Mail sinks.
11. Host Mail Capability table.
12. Host special processing tables.
We are building 1 through 5, hope that others will adapt 6 to this
system (a version of MM has been adapted at ISI), using the existing 7,
defining and using 8, providing interfaces for 9 and 10 as requested,
and creating and using 11 and 12.
Page [2] Sluizer & Postel
Mail Transfer Protocol
+-----+ +-----+ +------+ +------+
| MTP | | MTP | | USER | |OTHER |
| TCP | | NCP | | MAIL | |MAIL |
| RCV | | RCV | | PGM | |SOURCE|
+-----+ +-----+ +------+ +------+
| | | |
| | | |
| | | |
v v v v
+----+ +----+ +----+ +----+
| | | | | | | |
Pending +----+ | +----+ | +----+ | +----+ |
Files | |-+ | |-+ | |-+ | |-+
| | | | | | | |
+----+ +----+ +----+ +----+
\ | | /
\ | | /
\ | | /
v v v v
+------------------+ TABLES
| | +----+
| DISPATCHER |<----->| |---+
| | | | |
+------------------+ +----+ |
/ / \ \ +----+
/ / \ \
/ / \ \
v v v v
+-----+ +-----+ +-------+ +-----+
| MTP | | MTP | | LOCAL | |OTHER|
| TCP | | NCP | |MAILBOX| |MAIL |
| SND | | SND | | FILES | |SINK |
+-----+ +-----+ +-------+ +-----+
Note that current implementation the dispatcher and the senders for
MTP-on-TCP and MTP-on-TCP are combined in one program.
Sluizer & Postel Page [3]
ISO Plain Language
On this page
§1A Queue and Dispatcher for Mail
The memo describes an MTP implementation for TOPS-20 written in BLISS-10. Its planned sender and receiver functions support both TCP and NCP transport services and provide interfaces to other mail delivery mechanisms.
Mail programs create files in user directories. A background dispatcher sends queued mail, while a user-run dispatcher can send immediately when the needed channel is available.
Mail is placed in files and handled by a dispatcher. The dispatcher can run in the background or be started by a user.
§1Separating Delivery Instructions from Mail
Each piece of mail uses two files. The control file contains delivery information and points to the second file, which contains the mail data, including the RFC 733 header.
This separation lets the dispatcher change the recipient information as it sends a message through different channels, while the message data stays available to read. If one channel is unavailable, the control file can retain information for recipients who have not yet been sent the message.
One file tells the system where to send the message. The other file holds the message itself, so delivery progress can change without rewriting its contents.
§1Choosing an Output Channel
The dispatcher consults a host capability table to determine whether a destination accepts MTP over TCP, MTP over NCP, or the older FTP-over-NCP method. A separate table covers special cases, such as delivery through another mail system.
The system is made from receivers, senders, the dispatcher, mail composition programs, pending mail files, and local or external mail sources and destinations. The RFC says the first five network components were being built and describes the remaining interfaces and tables as work to provide or define.
The dispatcher checks a table to learn which delivery method each host supports. It then sends the message through that method or a special mail route.