|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
|
IETF RFC 784
Mail Transfer Protocol: ISI TOPS20 implementation Last modified on Thursday, October 15th, 1992 Permanent link to RFC 784 Search GitHub Wiki for RFC 784 Show other RFCs mentioning RFC 784 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] |