RFC 784 UNKNOWN EMAIL · IMPLEMENTATION · TOPS-20

Mail Transfer Protocol: ISI TOPS20 implementation

How ISI built a mail system for TOPS-20 using the new Internet protocols.

On rfc-editor.org ↗
PUBLISHED
July 1981
AUTHORS
S. Sluizer, J. Postel
STREAM
Legacy
IMPLEMENTATION LANGUAGE
BLISS-10
TARGET PLATFORM
TOPS-20
TRANSPORT PROTOCOLS
TCP and NCP
MAIL STORAGE
Two files (control + data)
DOI
10.17487/RFC0784

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
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]

AI ELI5

On this page
PROBLEMISI needed a working Mail Transfer Protocol implementation on TOPS-20 machines that could handle both the old ARPANET protocols and the new Internet protocols during the transition period.
MECHANISMISI built separate receiver and sender programs for MTP over both TCP and NCP, with a background dispatcher that processes mail from multiple sources and routes it to the appropriate output channel based on destination capabilities.
WORKING MAIL BRIDGEThe implementation allows mail to flow between old and new protocol systems. Mail is stored in two-file format (control file and data file) so delivery status can be updated as mail is processed.

§1Building a Transition Mail System

ISI created an implementation of the Mail Transfer Protocol for TOPS-20 machines (written in BLISS-10), supporting both TCP and NCP as transport services. The system provides both MTP sender and MTP receiver functions, bridging mail between hosts using old ARPANET protocols and hosts using new Internet protocols.

The implementation includes interfaces to other mail delivery mechanisms and tables indicating for each host whether it can accept mail via MTP on TCP, MTP on NCP, or FTP on NCP (the traditional method).

ISI built a mail post office on TOPS-20 computers that could accept packages from both old and new delivery systems.

§2Mail Flow Architecture

Mail sources (user composition programs like Hermes and MM, or system mail receivers from various channels) create mail files in user directories. A background dispatcher program processes these files and routes them to appropriate output channels. Users can also invoke a synchronous version to send mail immediately if a channel is available.

Mail is stored in a two-file format: a control file containing delivery information and a pointer, plus a data file containing the RFC 733 message header and body. This design allows the control information to be modified as mail is processed (marking recipients as sent, retrying failed recipients) while the message data is only read.

Mail files sit in a queue. A program wakes up regularly, looks at the queue, and tries to deliver each piece to the right place. It keeps track of what worked and what didn't.

§3Components and Tables

The system consists of five main components: MTP receivers for TCP and NCP, a dispatcher, and MTP senders for TCP and NCP. Additionally, it uses a Host Mail Capability table that specifies for each destination host which channels can deliver mail to it (MTP on TCP, MTP on NCP, or old FTP on NCP), and a Host special processing table for routing to systems outside the standard protocols (for example, hosts in England via UCL's mail system).

Mail composition programs interface with the existing user mailbox file system. Other mail sources and sinks can be integrated as requested.

Different routers for TCP and NCP move mail along. Tables say which routers can reach which destinations. The whole system fits together so nothing breaks.

§4References