Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Mail Transfer Protocol: ISI TOPS20 implementation (RFC0784)

IP.com Disclosure Number: IPCOM000003833D
Original Publication Date: 1981-Jul-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Sluizer: AUTHOR [+2]

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 48% of the total 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]

July 1981 ...