10-Sep-79 23:23:58-PDT,44117;000000000001 Date: 9 Sep 79 16:06-EDT (Sun) From: Dcrocker at UDel-EE Reply-to: Dcrocker at Rand-Unix Subject: MSGGROUP#1239 MMDF - Full text - with ^L, NO underscores Subject: An Internetwork Memo Distribution Capability To: MSGGROUP at USC-ECL Message-ID: <79251.58002.2180 @ UDel-EE> The following is the paginated version WITH ^L form-feeds. It also includes imbedded underscores. The text is 823 lines long, and prints on 14 pages. Dave. ----- AN INTERNETWORK MEMO DISTRIBUTION CAPABILITY -- MMDF David H. Crocker Edward S. Szurkowski David J. Farber September, 1979 Department of Electrical Engineering University of Delaware Newark, Delaware 19711 (To be published in the PROCEEDINGS OF THE SIXTH DATA COMMUNICATIONS SYMPOSIUM, Pacific Grove, California, November 1979.) AN INTERNETWORK MEMO DISTRIBUTION CAPABILITY -- MMDF ABSTRACT The advent of packet-switched networks has led to increased use of computers for sending text messages (memos) between peo- ple. However, attachment to common carrier or equivalent packet networks is expensive and/or restricted by organizational poli- cies. In addition, use of several networks creates the need for relaying memos between them. The work described here is designed to free users from dependence upon any particular communication environment and to provide a memo distribution facility which can employ whatever communication channels are available. It will support variable-network structures, emulation of network attach- ment, and inter-network memo forwarding. INTRODUCTION It has been common for stand-alone time-sharing systems to provide some text message (memo) services to their users. Such services typically allow simple transmission of a block of text from one user's storage space into some other user's space. As such, these facilities are little more than restricted disk file-copy mechanisms. Little or no specialized software is pro- vided to aid in creation, viewing, or final disposition of mes- sages. However, the advent of packet-switched networks gave a major boost to the use of these services and resulted in a demand for improvements to their functionality. These changes seem pri- marily to be due to the vastly increased base of potential com- municants and to their geographic separation. The DARPA Network (ARPANET) provided the first major oppor- tunity for ongoing inter-organizational human communication to take place using geographically distributed computers [15, 9, 3]. Common carrier-oriented, network-based message systems are begin- ning to appear, although most of their initial orientation is toward using the network to connect the users' terminals to the same machine, rather than toward having a number of machines, each located near users, and employ the network to transmit mes- sages between machines. The existing ARPANET-based environment is still quite lim- ited in size and there are many potential communicants who are not attached. A user's costs of attaching to a common carrier- oriented packet network are quite high and, as in the case of the ARPANET, there often may be organizational policies restricting who is allowed to access it. In addition, the current trend is toward a profusion of networks, so attachment to one will not guarantee the ability to send messages to a given other user. The work underway at the University of Delaware has created an 2 application-level system for the distribution of memos between machines not attached to a packet network, to permit machines to emulate network attachment and to allow inter-network memo dis- tribution. FRAMEWORK FOR MEMO PROCESSING The basic object of manipulation is a message, currently limited to text and not including drawings, facsimile, speech, or the like. It has a structured segment, containing some header information such as recipient lists and a subject line, and it has an unstructured body of text. Users may have a program aid in the acquisition of the message parts (e.g., by prompting) and then initiate transmission. For messages sent to users of the same machine, delivery is, of course, quite rapid; to users on machines attached to the same network, delivery usually occurs within a few minutes. The recipient may have available a program which aids in processing messages for initial viewing and later disposition (filing or deletion). Often, the creation and recep- tion programs are identical (or linked) so that, for example, the destination address and subject lines of a reply message can automatically be taken from the received message. We classify the existing message systems as "memo" proces- sors to indicate their usual role within human communications. They do not attempt to support the full range of formal inter- organizational communications, which could require such services as full typography, multiple media (e.g., voice and facsimile) and authenticated "signatures". Architecturally, a message system may be factored into user and distribution environments. (See Figure 1). The user environment may allow the user to create, view, modify, remove and/or store messages and to interface with the distribution package for submission (posting) and receipt (delivery). The distribution package is responsible for accepting a message when posted, transmitting (relaying) it on toward the equivalent package on the recipient's machine and delivering it into the recipient's domain. If sender and receiver reside on the same machine, a zero-hop case results in exercising only one package; on the ARPANET, delivery between a sender and receiver using different machines is usually one hop. An intended reci- pient may be a person or a process; with the former, delivery is necessarily to some computer-based "agent" such as a standard disk file or a special program [12, 1, 18, 14]. Most work has been devoted to the development of sophisti- cated user environments, with a wide range of text (word) pro- cessing features [e.g., 1, 7, 8]. In a few cases, data-base management systems have been employed to help users wade through the mass of memos they have to process [17, 18]. For example, an informal survey of various ARPANET users indicates that process- ing 20-50 memos a day, per user, is not uncommon. Over the course of a year, management of the resulting glut of data can be 3 extremely difficult. Delivery facilities have received relatively little atten- tion. The most important standard feature for network environ- ments is a facility's taking responsibility for re-trying transmission when a receiving host's distribution package is not initially available; failure to transmit a message within a period of time usually results in the message's being returned to its sender. Some systems also allow forwarding mail to a reci- pient known to the system, but having a mailbox on another machine which can be reached. Several systems provide an extremely useful extension to this service, by allowing the known name to map into more than one address; sending mail to a distri- bution list thereby only requires specification of one address. A more robust environment might include change-of-address notifi- cation, return-receipt, levels of privacy (such as end-to-end encryption), priority handling and the like. On the ARPANET, the existing mail transmission protocol allows only simple transfer of a single message for a single recipient [11, 13]. A separate transfer is required to send a copy of a memo to each indicated recipient. Two replacement pro- tocols have been proposed, but neither has been pursued [5, 19]. Another attempt is now underway [14]. Also in the past year, IFIPS Working Group 6.5 has been formed to begin specifying a standard for international use. GOALS The University of Delaware's Multi-channel Memo Distribu- tion Facility (MMDF) is intended to interface to user-environment systems in such a way as to provide an integrated view of a com- munication environment which can have a variety of different transmission channels. Consequently, sending a message to a local user, to a user on a machine attached through a local, national or international packet network, or to one on a machine accessible only through a telephone call involves the same effort and procedures for the user. The degree to which users are impacted by changing underlying channels is minimized. It is also intended that the need for multi-hop relaying will be tran- sparent to the user. At present, the level of service provided to the user is approximately the same as is available on the ARPANET. By allow- ing specification of a list of recipients, for a given channel, MMDF provides a degree of message batching ("bagging"); this is in contrast with the transfer-per-copy required in the ARPANET protocol. Also, provisions exist for indicating that a memo is to be broadcast on users' terminals, rather than, or in addition to, being put into their mailboxes. This is already experimen- tally available on some ARPANET hosts [6]. An additional capa- bility, which has to date received only limited use, allows reci- pients to have their own agent program automatically invoked to take non-standard actions during final delivery. 4 ARCHITECTURE MMDF is implemented under Western Electric's Unix(TM) operating system, running on DEC PDP-11s and has modules for han- dling deliveries to the local machine, the ARPANET, and machines accessible through a telephone call. Memos must conform to the syntactic requirements now in effect for ARPANET text messages [2]. PRIMARY FUNCTIONALITY In order to provide reasonable data security and privacy and to facilitate deferred deliver of messages, MMDF operates separately from the user, once a memo is submitted for transmis- sion; however a sender may elect to observe the initial transmis- sion attempt. In particular, no storage (file) space is shared with users and users' access to MMDF's storage space is highly restricted. Figure 2 is an overview of the MMDF process struc- ture. Posting of a memo is initiated by some higher-level memo- manipulation system's invoking the SUBMIT program which is responsible for accepting a memo, parsing and partially verifying its distribution list, queuing the memo in MMDF's file space and, optionally, for invoking the DELIVER process if delivery is to be attempted immediately. (A background DELIVER daemon runs period- ically, processing those memos not yet transmitted.) Since all memos are passed through the SUBMIT process, it is quite easy to impose various format and content policies on them. Currently, SUBMIT enforces basic syntactic requirements, authenticates source information and partially verifies destina- tion specifications. The syntax checking only verifies that fields are properly delimited and is not concerned with their internal format. Source information is supposed to indicate who sent the memo, since it is not considered acceptable for anonymous senders to consume -- and possibly flood -- storage space of recipients; however some "anonymous" mail is currently allowed, but such messages are explicitly marked as having unau- thenticated source addresses. For the specification of destina- tion mailboxes, SUBMIT can fully certify the existence of mail- boxes on the local machine, but can only certify the existence of the (next) host specified in non-local addresses. In the latter case, detection of non-existent mailboxes is deferred until delivery is actually attempted. A more robust inter-machine functional protocol might allow complete certification at the time of submission. An aliasing facility is provided to extend the basic list of known names (i.e., login names). The extension allows users to receive mail under several names, as might be necessary if the user's login name were not well known. Also, mail can be accepted for forwarding to another machine; and the facility sup- ports distribution lists by allowing a single alias name to expand into multiple addresses. The facility currently is merely a keyword-oriented, string-replacement mechanism and proves 5 remarkably useful, given its simplicity. A more sophisticated mechanism would understand human name construction and would intelligently map first/last name combinations into user mailbox addresses. Through a simple protocol, a single SUBMIT process can accept multiple memos for posting. A posted memo is queued into two files; the first contains envelope-related information and the second contains the message text. Envelope information includes message status, such as the time the memo was queued, as well as the return address and the recipient address list. Con- ceptually, it is useful to think of this file as containing a set of independent envelopes. Addresses consist of a mailbox reference and an optional host reference. If the host reference is present and does not refer to the local host, mailbox reference may include further host reference(s), implying multi-hop relaying. However, this is not relevant to the SUBMIT which is parsing the address solely to select the (next) transmisson channel. The local channel receives special handling (e.g., verification of the mailbox references) since it effects final delivery, but SUBMIT otherwise is not aware of individual channels' characteristics. The address is actually a transport path specification, in which a host reference directly maps into a channel name, through a sim- ple name-table search. A more robust facility might make a stronger separation between address and path, as discussed in [16]. DELIVER is responsible for managing the transmission pro- cess, recording its success and handling failures. It invokes subordinate processes to perform actual transmission on indivi- dual channels. The envelope list stored by SUBMIT explicitly names the appropriate channel for each address, so that DELIVER is not REQUIRED to have any specific information about channels. However it does have code which implements policies attempting to regulate WHEN a channel may be invoked. If DELIVER is running as the background daemon responsible for processing memos not yet transmitted, it uses the time of queueing so that memos will be delivered in the order submitted. In addition, this is used for a two-stage time-out in the event of transmission failures. After the first time-out (e.g., one day) a warning memo may be sent to the return address, indicating to whom the memo has not yet been successfully transmitted. After the second time-out (e.g., four days), the entire memo is removed from the queue and may be sent to the return address. The normal mode for message systems is to have the distri- bution package initiate transmission to the next relay site. That is, when a message is queued an active attempt is made to transmit it on toward the recipient. In order to implement a special use of telephone circuit-based delivery, we have added a "passive" mode, called "Post Office Box" delivery. In this mode, a queued message is held until the next, or recipient, machine attaches itself and requests (i.e., polls for) any P.O. Box 6 messages being held for it. For example, this allows a machine attached to a network to hold messages arriving from the net, until unattached machines call up. A more robust option allows a message to be handled in both modes, according to which side first initiates connection, so that it is actively sent if the holding machine initiates and passively sent if the receiving machine initiates. CONTROL OF TRANSMISSION MODULES When a transmission module is invoked, it has access to the memo's text, but not its address list. A simple protocol is used by DELIVER to pass individual addresses to a module. After receiving an address the module responds to DELIVER with an indi- cation that the "envelope" is acceptable or not, that a copy of the entire memo has just been sent for the indicated addressee, or that an error occurred. When DELIVER indicates the end of the address list for that module, the module signals normal comple- tion or an error. If normal completion is indicated, DELIVER marks as completely processed those addresses which were previ- ously marked as only having had the envelope accepted. One of the error conditions is for an unavailable host and this may occur at any time. If it does, DELIVER terminates the current invocation of the module and moves on; the background DELIVER will then again try transmission at a later time. The current policy is to have the background DELIVER minim- ize channel invocations, so that it attempts to send all messages queued for a channel, before moving on to the next one. TRANSMISSION MODULES. Currently, four transmission modules have been built: LOCALSND, ARPASND, PHONESND, and POBOXSND. Transmission to another machine involves two levels of protocols. A low-level link protocol allows uninterpreted data to be transferred; a higher one deals with the semantics of passing memos. Minus various user interface features, the higher level protocol should correlate with the features of the SUBMIT program. None of the existing modules use a mail submission protocol which allows con- tinuation after interruption from sending a message (or address list). Instead, transmission must restart from the beginning of the negotiation, including full transmission of the message text. Under Unix, the LOCALSND delivery module must run with spe- cial privileges, since it must be able to write onto any user's mailbox and, for privacy reasons, mailboxes normally are pro- tected. The standard action is to append a new message to the end of a recipient's mailbox file. However, a feature is avail- able which allows any recipient to have a special program invoked at the time of delivery. The program may take full responsibil- ity for delivery or may merely augment normal delivery with other special actions. Currently, it is used for automatic incorpora- tion into a simple data base which holds system-wide public news messages. An alternate use might have the user's program take special action to notify the user of the message's arrival, while 7 still allowing standard delivery of the message. For a machine attached to the ARPANET, the ARPASND module handles transmission to other attached hosts. It employs the File Transfer Protocol (FTP) for mail submission and sends a separate copy of the message for each recipient [11, 13]. (Unfortunately, some hosts will accept messages, indicating suc- cessful delivery, even when the recipient is unknown. They typi- cally then send the message to a lineprinter or to the operator.) Receipt of messages from attached hosts is accomplished separately, by a FTP serving process which invokes SUBMIT. PHONESND performs telephone-based transmission and requires use of dial-out hardware. Since telephone calls may be expensive and slow to make, DELIVER may have a particularly stringent pol- icy regarding the timing of PHONESND's use, such as limiting calls to the period of lowest telephone rates and/or until several messages are queued. To effect transmission, PHONESND calls the destination com- puter and then starts a slave (serving) process which runs as a normal user program and does not require any special operating system privileges. The data-transfer (link-level) protocol currently being used is simple and idiosyncratic; it is believed that it can be implemented on any operating system, employed in a user process having no special privileges and operates in a strictly half-duplex manner. No attempts have yet been made to perform data compression or otherwise maximize effective channel bandwidth; however it appears likely that such enhancements would not be difficult. PHONESND accomplishes pickup of P.O. Box-held memos from a host, as well as transmitting queued messages to it. However to DELIVER, PHONESND appears merely to be another transmission module. The current policy is to send outbound messages, as shown in the top half of Figure 3, before retrieving P.O. Box messages, as shown in the bottom half the figure. It depicts the full process structure for two Unix-based MMDF systems partici- pating in this type of exchange. As a normal transmission module, PHONESND is handed an address by DELIVER, transmits it to the slave which passes it onto the SUBMIT. SUBMIT then returns an acceptance or rejection response, which the slave transmits back to PHONESND, which passes it to DELIVER. When DELIVER signals PHONESND that there are no more addresses for a message, PHONESND attempts to send the message text. Upon successful completion, it notifies DELIVER. When DELIVER signals that there are no more messages, PHONESND invokes a local version of SUBMIT and asks the slave process to initiate transmission of any P.O. Box messages waiting to be picked up. The slave then invokes a DELIVER, on its end, requesting pickup of any P.O. Box mail for the calling host (determined by the name under which it logged into the slave host). The slave's DELIVER invokes the POBOXSND module which 8 actually performs the mail transfer back up to the slave, across to the calling PHONESND, and onto its SUBMIT. The transaction then follows a submission protocol identical with that originally used to submit mail in the other direction. Note that POBOXSND does not initiate any connections. Instead it merely "releases" any messages waiting for its caller, up through the controlling terminal connection. In the MMDF running at the University of Delaware, DELIVER believes that the PHONESND module is actually the ARPANET module. In this fashion, the system thinks that it actually is attached to the network, with the PHONESND module being the only one aware of the need to go through a telephone call and relay station. Such attachment emulation could be quite useful for allowing a number of unattached machines to share the costs of using a common-carrier packet network. A greater average delivery time is the ONLY performance difference that can be perceived by users. What is also significant is that the eventual transition of connecting one of these unattached processors directly will be completely transparent to its users. The cost of entering into network-based memo communications is thereby greatly reduced. ACCESS CONTROL & DATA SECURITY All of the modules in MMDF can access memo text and there- fore must be viewed as "trusted" processes, free of any Trojan Horse security violations. However, the system is designed to prevent unauthorized access by others, to the limit of the operating systems's capabilities to do so. All memos offered for distribution are passed through the SUBMIT process, so that all policies regarding the "validity" of memos are implemented in it. The policies described earlier are relatively few. As an example of differing policies, stronger enforcement of memo syntax may be desired, to guarantee that user programs can use information in the memo for filing and con- structing replies. Machines which exchange memos, via MMDF's PHONESND, must do so with prior agreement since the caller must be able to log into the server. This login requirement makes the question of the server's trusting the caller -- for example, whether it believes that a memos's source information has been adequately authenti- cated -- purely an administrateive issue. Using the example, a server which trusts a caller will not have to add a disclaimer to a submitted memo, indicating that the source information has not been authenticated. To some extent, the system's operational control can be viewed as involving communication between message system "security kernels". Once a memo is submitted for transmission, it resides in file storage which is protected from users. Only authorized processes, such as SUBMIT and DELIVER are able to access the data in that storage space. Therefore, memos are protected to the 9 limit of the operating system and MMDF software integrity. STATUS Two sets of MMDF systems are currently operational. The initial set consists of the University of Delaware, Department of Electrical Engineering's DEC PDP 11/70, which has dial-out hardware and is not attached to the ARPANET, and the Rand Corporation's PDP 11/70, which is attached to the ARPANET. As discussed above, use of Rand's system allows the Delaware system to emulate network connection. An early version of MMDF software was exported to SRI International, for its use in tying together a PDP 11/70 at Gal- laudet College, in Washington, D.C. and an SRI PDP 11/40 in Menlo Park, California, as a demonstration telecommunication network for the deaf ("Deafnet"). The project is funded by the Depart- ment of Health, Education and Welfare, and this first phase is intended to show the feasibility of augmenting the deaf community's existing mechanism (direct station-to-station phone calls using obsolete baudot TTY's and non-standard modems) with current communication technology, particularly that of distri- buted computer networks. MMDF runs as a collection of user programs. No modifica- tions to the operating system are required, although a file exclusive-open mechanism, developed at Rand, and the Alarm (time-out) system call are used if available. As mentioned ear- lier, the local delivery process must run with extra privileges, to be able to write onto any user's mailbox. Due to the nature of Unix, it is convenient to have each functional module occupy a separate process. This imposes measurable additional costs, but provides considerable flexibil- ity and avoids the address-space problems common to 16-bit machines. The Delaware and Rand machines have been cooperating to provide a regular, reliable service for exchanging memos, since the middle of Spring, 1979. The background DELIVER processes at both sites have a one-half hour sleep cycle. Because Delaware has access to a WATS telephone line, for calling Rand, the current policy is to allow queued memos to be transferred when the background DELIVER next wakes up. If no mail has gone out within two hours, Delaware forces a call to request any P.O. Box mail that is waiting. During a transfer session, total effective bandwidth tends to be 1-1.2 kilobytes per MINUTE, using 300 baud modems. Transfer of 250 kilobyte memos is common and transfers of more than 500 kilobytes have been accomplished. However it should be noted that large transfers commonly require several tries before completing successfully; this would be considerably less painful if the protocols allowed continuation after interr- uption, rather than requiring starting from the beginning. With the current configuration, it is common to have closed-loop com- munication between a Delaware and ARPANET user, with one memo in 10 each direction, take two hours. While much slower than is com- monly experienced by hosts directly connected to the ARPANET, it is eminently useful. The only piece of software not yet built would allow users to query about the status of queued memos which have not yet been sent and, optionally, to remove these memos from the queue. Note that this capability is essentially unavailable with the United States Postal Service; retrieving a piece of mail, once it has been placed in an outgoing mailbox, is virtually impossible. Consequently, this program is not considered to be critical to the operation of the facility. CONCLUSION In the past, computer-based memo distribution has been lim- ited to a shared local machine and, possibly, to an attached packet network. Attachment to common carrier-oriented networks of this type is expensive and still severely limits to whom mes- sages can be sent. The current project has developed a distribu- tion facility which can take advantage of a wide range of transmission channels available to it, including the telephone and local networks, and promise to reduce greatly the entry cost for performing computer-based memo processing. Although no attempt has yet been made to optimize system performance carefully, and some of its design would appear to impose substantial costs, preliminary indications show reasonable operating performance and costs. With proper tuning, the system should constitute an extremely cost-effective communication tool. ACKNOWLEDGEMENTS The current software makes use of a skeleton distribution system which was built by Steven Tepper, of the Rand Corporation, for the Defense Advanced Research Projects Agency, and already contained provisions for the alias, two-stage time-out and individualized-receipt features. Also, Robert Anderson, formerly of Rand, and Stockton Gaines, of Rand, have been extremely cooperative in permitting the use of their Unix system during the development of this system. SRI adapted MMDF to operate symmetrically, with any host able to originate or receive calls. Our discussions with them led to a more general implementation of the active/passive mechanism and to the system's status-logging package. And, of course, the exchange provided us with a better understanding of some of the difficulties in transporting the system into other operating situations. Our participation in the recent activities of IFIPS Working Group 6.5, on International Computer Message Services, has also greatly aided in our understanding of this domain; some of the vocabulary used in this paper and some of the organization to 11 Figure 1 were taken from those discussions. We would also like to thank Vinton Cerf, of DARPA, for some cogent comments on an earlier draft of this paper. This work has been supported in part by the University of Delaware and in part by research contracts from the General Sys- tems Division of International Business Machines and from the Department of the Army Materiel Development and Readiness Com- mand. REFERENCES [1] Crocker, D.H. FRAMEWORK AND FUNCTIONS OF THE MS PERSONAL MESSAGE SYSTEM. R-2134-ARPA, The Rand Corporation: Santa Monica, Calif. (1977). [2] Crocker, D.H., Vittal, J.J., Pogran, K.T., and Henderson, D.A. Standards for the Format of ARPA Network Text Mes- sages. In: [4]. [3] Crocker, S.D., Heafner, J.F., Metcalfe, R.M. and Postel, J.B. Function-oriented Protocols for the ARPA Network. In: AFIPS PROCEEDINGS, Vol. 40, 271-9 (1972). [4] Feinler, E. and Postel, J. (eds.). ARPANET PROTOCOL HANDBOOK. NIC-7104-REV-1, Network Information Center, SRI International: Menlo Park, Calif. (1978) (AD-A0038901). [5] Haverty, J.F. MSDTP -- Message Services Data Transmission Protocol. RFC No. 713, NIC No. 34739, Network Information Center, SRI International: Menlo Park, Calif. (April, 1976). [6] Harrenstein, K.L. FTP Extension: XSEN. In: [4]. [7] Heafner, J.F., Miller, L.F., and Zogby, B.A. SIGMA MESSAGE SERVICE REFERENCE MANUAL. ISI/WP-5, Information Sciences Institute, University of Southern California: Marina del Rey, Calif. (Feb., 1977). [8] Henderson, D.A. and Myer T.H. Issues in Message Technology. In: PROCEEDINGS OF THE FIFTH DATA COMMUNICATIONS SYMPOSIUM, 77CH1260-9C, IEEE: New York, pp. 6:1-9 (Sept., 1977). [9] Kahn, R.E. The ARPA Network -- Packet-switching Technology. In: IEEE CONFERENCE ON COMMUNICATION SYSTEMS AND TECHNOLOGY, IEEE: New York, p. 134 (1974). [10] Levin, R. and Schroeder, M.D. Transport of Electronic Mes- sages Through a Network. In: Boutmy & Danthine (eds), TELEINFORMATICS 79. North-Holland Publishing (June 1979). [11] Neigus, N. File Transfer Protocol for the ARPA Network. In: [4]. 12 [12] Pickens, J. Functional Distribution of Computer Based Mes- saging Systems. In: PROCEEDINGS OF THE SIXTH DATA COMMUNICATIONS SYMPOSIUM, IEEE: New York (Nov. 1979). [13] Postel, J. Mail Protocol. In: [4]. [14] Postel, J. An Internetwork Message Structure. In: PROCEEDINGS OF THE SIXTH DATA COMMUNICATIONS SYMPOSIUM, IEEE: New York (Nov. 1979). [15] Roberts, L.G. and Wessler, B.D. The ARPA Computer Network. In: N. Abramson & F.F. Kuo (eds.), COMPUTER COMMUNICATION NETWORKS, Prentice-Hall: Englewood Cliffs, N.J., pp. 485-500 (1972). [16] Schoch, J.F. Inter-Network Naming, Addressing, and Routing. In: PROCEEDINGS OF COMPCON 78. IEEE: New York (Fall, 1978). [17] Sattley, J. MARS -- A Message Archival and Retrieval Ser- vice. RFC No. 744, NIC No. 42857, Network Information Center, SRI International: Menlo Park, Calif. (Jan, 1978). [18] Vezza, A. and Broos, M. An Electronic Message System: Where Does it Fit? In: PROCEEDING OF TRENDS AND APPLICATIONS: COMPUTER NETWORKS, IEEE: New York (1976). [19] White, J.E. A Proposed Mail Protocol. RFC No. 524, NIC No. 17140, Network Information Center, SRI International: Menlo Park, Calif. (June, 1973). 13 ---------------------------------------------------------------- | User Environment Distribution Environment | | | | --------------- Queue of | | ----------------- Posting | Accept and |----> memos | | | Compose Send-|--------> | Queue memos | | | | | Format Show | --------------- V | | | Edit File | ------------------ | | ----------------- | | | | / / / V V | | Memo Receiving ------------- ------------ | | Folder1... Mailbox <----- | Deliver | | Relay to |--> | | | To Local | | Foreign | | | | Mailboxes | | Sites | | | ------------- ------------ | ---------------------------------------------------------------- Figure 1: General System Structure for Memo Processing ---------------------------------------------------------------- | --------- -------- --------- | | |user | -> |SUBMIT| . > |DELIVER| . . . . | | |program| -------- . --------- . . . . | | --------- | . . . . V . . . | | | . --------- . . . -- | | | . -----> |ARPASND| . . . | | | | . | --------- V . . |--> | | V . | ---------- . . | Relay | | (limited) Queue of |------> |POBOXSND| . . | toward | | (access ) messages --| ---------- V . | foreign | | / / | ---------- . | mailboxes | | Envelopes Texts |---------> |PHONESND| . | | | | ---------- V -- | | | ---------- Deliver | | -------------> |LOCALSND| -> to local | | ---------- mailboxes | ---------------------------------------------------------------- Figure 2: MMDF Process Structure ---------------------------------------------------------------- | Unattached Host (Caller) Attached Host (Server) | | * | | DELIVER (daemon) | | | Send --> SUBMIT | | V to | | | [Phonesnd]->(outgoing) . .> Net . > [Slave] -> (incoming) | | [----------------------------------------------------------] | | [Phonesnd]<-(incoming) <. . Pickup < . [Slave] <- (outgoing) | | | from ^ | | | V Net | V | | SUBMIT | DELIVER | | | (pickup)| | | | V | | -<--- POBOXSND | ---------------------------------------------------------------- Figure 3: Network Mail Forwarding for Unattached Hosts