5 MZnet: Mail Service for Personal
16 Network Management Associates
22 in Information and Computer Science
24 University of California at Irvine
30 Department of Information and Computer Science
32 University of California at Irvine
40 University of California at Los Angeles
51 Traditional computer mail systems involve a co-resident User Agent
52 (UA) and Mail Transfer System (MTS) on a time-shared host com-
53 puter which may be connected to other hosts in a network, with new
54 mail posted or delivered directly through co-resident mail-slot pro-
55 grams. To introduce personal micro-computers (PCs) into this envi-
56 ronment requires modification of the traditional mail system architec-
57 ture. To this end, the MZnet project uses a split-slot model, placing
58 UA programs on the PCs while leaving MTA programs on a mail relay
59 host which can provide authentication and buffering. The split-slot
60 arrangement might be viewed as a new protocol level which operates
61 somewhere between the currently defined MTS-MTS and UA-UA lev-
70 Mail systems were born and have grown up on large central time sharing
72 systems, often imbedded in large networks of inter-operating computers with
74 a set of distributed processes automatically transferring mail between users.
76 This is certainly the case with the U.S. Department of Defense (DoD) Ad-
78 vanced Research Projects Agency Network (ARPANET) [1 ] where much of
80 the original computer network mail systems research and development has
82 taken place. Other mail networks such as the Computer Science Network
84 [2 ] sponsored by the U.S. National Science Foundation, have also used rela-
86 tively large shared computers lodged in an institutional setting, though they
88 are often connected together with ordinary dial-up telephone links to form a
90 large geographic network. Another U.S. example is USENET [3 ] which con-
92 nects thousands of Unix1 systems together with informally-supported dial
94 telephone links. Although there have been several attempts, there appear to
96 be no successful mail networks based on small personal computers, such as
98 those that use the CP/M2 or MS-DOS3 operating systems.
100 The accepted architectural model (see Figure 1) for computer network
102 mail (first articulated by the IFIP 6.5 Systems Environment Working Group)
104 involves a User Agent (UA) which posts new mail items through a mail slot
106 [4 , 5, 6, 7] to a Mail Transfer Agent (MTA) which delivers posted items to
108 designated UA recipients through corresponding delivery slots. When mail
110 is to be delivered to a UA on another host, it is transferred first to another
112 MTA on the recipient user's host, which in turn puts the mail item through
114 its local delivery slot. In this model, a Mail Transfer System (MTS) may
116 be viewed as a collection of MTAs with network connections among them to
118 provide Mail Transfer Services for a large number of users on different host
122 Replicating this UA/MTA/MTS model on a personal micro-computer
124 (PC) is not an easy task. Aspects of PCs that make support of this model
126 difficult include limited storage capacities, limited processing capabilities,
128 and the fact that PCs are geared to support a single user rather than several
130 users at once. A PC with limited secondary diskette storage and limited
131 ________________________________________________
132 1 UNIX is a Trademark of Bell Laboratories, Inc.
133 2 CP/M is a Trademark of Digital Research, Inc.
134 3 MS-DOS is a Trademark of Microsoft Corporation.
143 processing capacity (often single-thread) is not well suited to support the full
145 range of automatic interactions between a UA and an MTA, or the necessary
147 interactions between MTAs in an MTS. For example, we do not see any way
149 to certify PC systems for authentication of posted mail. A PC can change
151 its entire character and behavior with insertion of a new program diskette,
153 suggesting that it is the operating system diskettes and their users that must
155 be certified, rather than the computers. Review of certification issues shows
157 that it is not the computer, but its operators and managers that must be
159 certified, and this involves the notions of central management and control.
161 All this is lost in the maze of PCs that we see proliferating on and off our
163 campuses, in and out of our offices and homes.
165 Thus, we see a need for a new arrangement with the UA separated from
167 its MTA, and using communication protocols to interact with it in ways
169 that resemble MTA-to-MTA interactions. The UA is placed on the PC end,
171 while the more complex tasks performed by the MTA are relegated to the
173 remote host end. The remote MTA must authenticate mail items offered by
175 the PC-based UA, just as it would for a co-located UA, but the task is more
177 difficult because the PC UA is potentially anyone among the public telephone
179 connectable population. This can be handled with password systems, but
181 recognition and identification are not the only services to be provided at the
183 posting slot. Posting also requires some validation of recipient addresses,
185 and validation of the syntax and semantics of certain header fields. Example
187 standards are provided by the U.S. National Bureau of Standards (NBS) and
189 the U.S. DoD ARPANET for the format of mail to be transferred [8 , 9 , 10 ].
191 The new arrangement described in this paper might be called a split mail
193 slot in that the UA side of the slot is split away from the MTA side. Although
195 the UA and MTA may be on opposite ends of a telephone connection, they
197 must still act together as a single processing unit to move mail from one
199 to the other, with all that this may entail. This gives rise to a number of
201 new MTA/UA requirements such as error control for service requests, user
203 intervention to select items for delivery, and user postponement or rejection
205 of delivery without triggering failure notices to senders. These are not serious
207 problems when both MTA and UA are programs running on a single host.
209 For example, with both UA and MTA on the same host, unwanted junk mail
211 is simply deleted at low cost, compared to the cost of deletion after a long
213 delivery transmission time. Better that our PC users be able to discard items
215 without delivery transmission.
224 Overview of the MZnet Environment
227 The MZnet project is an undergraduate student effort sponsored within the
229 Information and Computer Science (ICS) Department of the University of
231 California at Irvine (UCI) in Southern California. For the past 2 years, the
233 UCI mail network, known as ZOTnet, has been connected into the Computer
235 Science Network (CSnet) and in 1984, has joined the DoD ARPA Internet
237 with a Split-Gateway connection [11 ] to the University of Southern California
239 Information Sciences Institute (USC-ISI). The MZnet split-slot arrangement
241 may have some similarities to the Split-Slot Internet Gateway at least in
243 name, but the problems and the implementations are quite different.
245 The UCI ZOTnet environment [13 ] gives the MZnet project a full-fledged
247 Internet-class mail system as its foundation. The MZnet project objective is
249 to extend this class of mail service to personal computers located in student
251 and faculty residences, offices and laboratories, without waiting for full-blown
253 local area networking to first provide connections. This follows a pattern of
255 making the most of existing facilities to provide a reasonable level of service.
257 The UCI ZOTnet uses the CSnet-provided MMDF (Multi-channel Memo
259 Distribution Facility) software [12 ] from the University of Delaware to inter-
261 connect two VAX 750 Unix systems with two DEC TOPS-20 systems through
263 a port selector, with dial telephone connection to a CSnet relay [14 ]. The
265 ZOTnet has since evolved into an ethernet-connected local area network with
267 the aforementioned gateway connection into the DoD Internet. The ZOTnet
269 also connects to USENET with the UUCP protocols, and provides format
271 transformations for mail flowing between protocol domains [15 , 16 ]. Adding
273 to the reach of the ZOTnet with MZnet is a natural part of its evolution4 .
275 To this point we have set the context of the MZnet project. The remainder
277 of this paper is devoted to relatively technical discussions of implementation
279 of the PC user agent programs and the split-slot UA/MTA interface.
280 ________________________________________________
281 4 For those who are properly curious about such things, the name "ZOTnet" derives
283 from the cry of the UCI mascot which is the Anteater from the B.C. comic strip, and
284 MZnet is simply a contraction for Micro-ZOTnet.
293 The MZnet User Agent: CP/MH
296 CP/MH is a collection of programs designed to work in conjunction with
298 the Micro ZOTnet (MZnet) as an extension of the UCI ZOTnet. CP/MH
300 programs permit a user of a CP/M 2.2-based microcomputer to send and re-
302 ceive ZOTnet mail messages, as well as to manipulate them locally on floppy
304 disks. The CP/MH programs are written in the C programming language
306 and should be portable to similar operating environments, such as MS-DOS,
310 CP/MH is based on the UCI version of the Rand MH message handling
312 system [17 ] for the Unix operating system. The major philosophical dif-
314 ferences between CP/MH and typical user agents such as MSG [4 ] and its
316 descendants are those of modularity and of user interface. In CP/MH (as
318 in MH) the user does not invoke a single monolithic program to deal with
320 mail, but rather invokes individual, non-interactive programs with common
322 knowledge of the way messages are stored. Each program has default behav-
324 ior which can be modified by using Unix-style command line options at time
326 of invocation or through a user profile. Help messages can also be evoked
335 The format of a CP/MH message adheres more or less to the syntax described
337 in RFC 822 in which a message consists of headers containing information
339 pertaining to the message source and destination, and the message body,
341 separated from the headers by a blank line. An example of such a message
347 Date: 02 Nov 83 23:04:53 PST (Wed)
349 To: Toto <dog@Univ-Kansas>
351 From: The Great And Powerful Oz <Oz@Emerald-City>
353 Subject: What Be Your Excuse?
357 What's the matter? I ask you for a simple thing like
359 "distribute this to Witch@Oz-West," and you can't do it.
361 You undergrads will do anything to get out of work!
373 Following the MH convention, each message is kept in a separate file.
375 Since a message is simply ASCII text, it can be operated upon by non-
377 CP/MH programs (such as text editors, in particular).
379 Collections of messages are called folders. Under CP/MH, folders are
381 represented by several files: an info file, containing maintenance information
383 about the folder, and a set of message files with the same name as the info
385 file, but with unique numeric suffixes (extensions in CP/M parlance). An
387 example of this naming scheme might be:
390 DRAFT the info file for the DRAFT folder
393 DRAFT.001 message 1 in the folder
396 DRAFT.002 message 2 in the folder
399 DRAFT.003 message 3 in the folder
402 The number of messages that may be stored in a folder is limited primarily
404 by the storage capacity of a floppy disk, but also by the three-digit limit of
408 The info file contains a field named CURRENT: specifying the current mes-
410 sage number. The current message number signifies the default message
412 operated upon by CP/MH commands using a particular folder. The current
414 message number may be modified by some commands. An example of the
416 contents of the info file DRAFT might be
422 This indicates that the file DRAFT.003 would be operated upon when
424 default conditions apply (i.e. when no message number is explicitly given to
428 Possible future uses for the info file include named message sequences (a
430 set of messages to which commands may be applied as a whole) and user
432 profile information for application to particular folders (there is presently a
434 single user profile, described shortly).
436 A floppy diskette may contain more than one folder, but folders do not
438 extend over more than one floppy diskette; therefore two different diskettes
440 may contain folders with the same name.
452 Commands operating on messages can be divided into several general cate-
458 Transporting: sending, receiving
461 Viewing: selecting for display, showing header summaries
464 Creating: composing, replying, forwarding
467 Archiving: categorizing, refiling, deleting, sorting
471 The architecture of CP/MH permits the simulation of some of these cat-
473 egories using standard CP/M commands when CP/MH, in its present prim-
475 itive state, does not cover them.
477 A minimal functionality is presently provided by the following four com-
483 COMP composes mail items: creates a file containing header information
485 taken from a standard or user-specified template. This newly-created
487 file may be edited to fill in the header fields and body.
490 REPL replies to mail items: creates a file containing header information
492 appropriate for answering a given mail item. This newly-created file
494 may be edited to change header fields and fill in the body.
497 SEND sends mail items: posts selected items through the split-slot from a
502 INC receives mail items: takes delivery of selected items across the split-
504 slot, incorporating them into a mailbox folder.
508 These commands, with a few enhancements and modifications appropriate
510 to the CP/M environment, are functionally almost identical to their Unix
514 CP/MH commands are invoked like any other CP/M commands such as
516 ED, PIP, or DIR. Command line options are generally preceded by a dash
518 (e.g. -editor A:ED), and may be abbreviated. Folder names are preceded
527 by a plus (e.g. +B:DRAFT). Messages are identified by numbers or by the
529 special names first, last, current, next, and previous.
531 An example of use of a CP/MH command is:
535 comp -edit a:ed -use last +b:draft -log
539 This particular example will edit the last-composed message (the -use
541 last option) in the folder DRAFT on disk drive B: (the +b:draft option),
543 using the standard CP/M editor ED on disk drive A: (the -edit a:ed op-
545 tion), and prompting the user when it is appropriate to change disks (the
549 All CP/MH commands have a -help option which displays all available
551 options for the particular command invoked. Another common option is
553 -log which permits the user to change (relog) diskettes after invoking a
555 command, for purposes of selecting diskettes with message folders or with
557 editor programs. This is particularly useful on single-drive systems or on
559 systems with diskettes of low storage capacity.
566 If there are options commonly used with a particular CP/MH command,
568 they may be entered in the user profile contained in the file called (naturally
570 enough) PROFILE, which must exist on the same diskette on which CP/MH
572 commands reside and from which the commands are invoked. A profile entry
574 consists of a program name followed by a colon and the options to be used
576 with that program, for example:
580 comp: -editor A:VEDIT +B:outbox -log
582 repl: -editor A:VEDIT -log
590 Individual profile components are overridden by options given at the time
592 of invocation (e.g. -noedit given on the command line will override the
594 -editor profile component for a particular command).
603 The MZnet Split-Slot Mail Transfer System
606 The MZnet split-slot software implements a peer-to-peer communication pro-
608 tocol between a time-sharing host's MTA and a personal micro-computer
610 (PC) UA. This MZnet protocol extends the UA/MTA/UA model of computer-
612 based message systems (CBMS) to provide a split gateway function between
614 individual PCs and the ZOTnet similar to the UCI ICS split Internet gateway
616 described previously (see Figure 2).
620 The Structure of the Split-Slot
623 The MZnet Split Gateway consists of three distributed processing compo-
629 - A PC running a UA (in MZnet, CP/MH) acting as the mail server.
632 - A mini/mainframe host running a full MTA (MMDF in MZnet) pro-
634 viding mail relay services.
637 - A communication protocol (a modified version of MMDF PhoneNet)
639 to connect the two ends of the split-slot.
643 Although this combination may not be unique, the method by which the
645 MZnet split-slot bonds these parts together uniquely deals with the prob-
647 lems of remote user agents. In addition to overcoming limited storage and
649 processing capacities, remote user agents must deal with noisy modem lines,
651 mail software certification, and mail system security problems. The MZnet
653 architecture appears to solve these problems with a clean mail interface for
659 The MZnet Mail Server
662 The split-slot mail server consists of a set of command packet programs run
664 from the PC. These programs simply present commands through the Phone-
666 Net communication protocol to the mail relay slave program on the host.
668 Some basic commands are:
672 PostMail posts mail drafts to MTA
681 GetMail accepts mail from MTA
684 RemoteScan displays information about waiting mail
687 Quit drops connection between PC and Host
691 Each command has the form:
703 For example, the PostMail command is a small program that:
707 - initiates a command with the Mail Slave by sending the command name
709 (PostMail) encoded within a PhoneNet packet;
712 - sends a series of PhoneNet packets that contain pieces of the mail item
717 - finally sends a command termination signal to end the transaction with-
719 out terminating the connection between host and PC.
723 The MZnet Channel To MMDF
726 The MZnet Channel runs on the MTA host under the University of Delaware's
728 MMDF (Version 1) and is responsible for both delivery of received mail to
730 MZnet users, and posting of MZnet user-originated mail. The MMDF MZnet
732 channel maintains a unique message queue for each registered MZnet user.
734 As new mail items arrive, they are posted to the appropriate queues, where
736 MZnet holds the mail items for pickup by their registered recipients.
738 To send or receive mail, the MZnet user must attach to the host, log into
740 the public MZnet account, and identify (authenticate) himself. During the
742 MZnet session with the host, the user has access only to that restricted set
744 of functions provided by the MZnet split gateway protocol: he may request
746 delivery of queued mail with GetMail, or post new mail with PostMail. Prior
748 to taking delivery of queued mail, a survey of waiting mail also may be
757 requested with RemoteScan to obtain message size information (among other
759 data) to allow intelligent disposition of mail in the queue.
761 Hidden within these activities are issues of security and certification. To
763 certify and establish the identity of the user, a second password is requested
765 after logging into the public MZnet account. This certification procedure
767 allows MZnet to certify the source of originated mail. A relatively secure
769 environment is provided by MZnet, as it is the only interface to the host
771 permitted to MZnet users (once beyond the public login procedure), and it
773 offers only the severely restricted set of PhoneNet-encoded commands. Aside
775 from security issues, using a single account to handle all MZnet users reduces
777 demands on system resources.
781 The MZnet-PhoneNet Protocol
784 A unique facet of the MZnet system derives from the PhoneNet File Transfer
786 Protocol (FTP). PhoneNet FTP is a simple error-checked packet protocol
788 which transfers ASCII plaintext. PhoneNet encodes any non-plaintext char-
790 acter (or any other character "forbidden" by the idiosyncrasies of the com-
792 municating systems) by mapping it onto an "accepted" character set. The
794 accepted character set mapping is determined by a "negotiating" session be-
796 tween the two systems at the start of the PhoneNet session.
798 MZnet transfers all information (both commands and data) in PhoneNet
800 packets to obtain error control. The MZnet-PhoneNet command FTP toler-
802 ates noise with a high degree of success, and in effect, connects both ends of
804 the Split Slot together with a reliable set of virtual wires.
808 MZnet Session Example
811 Here, a typical MZnet session is presented, with the UA commands issued
813 from the PC side of the connection printed in a typewriter typeface, and
815 the responses from the host side printed in an italic typeface. PhoneNet
817 interactions are indented. The initial connection to the host is accomplished
819 with the term program, which provides a simple terminal emulation function.
821 The prompt of the PC for a UA command is "Ai". Note that passwords are
823 never echoed by the host system.
842 PhoneNet packet negotiation
852 message text packet transmission
867 The main conclusions of this paper are that small personal computer systems
869 with dial-up phone connections constrain User Agent systems design in ways
871 that require use of a split-slot interface between the UA and its supporting
873 Mail Transfer Agent (MTA), and that this interface will best provide the re-
875 quired services if it has error controlled command and data transfer facilities,
877 with interactive behavior.
879 It is also believed that a good design for the small PC UA is based on
881 a very modular architecture, such as the Rand MH system, which has been
883 used as a pattern for the MZnet UA.
885 By bringing these concepts together, we expect MZnet to provide reliable
887 UA/MTA service to a distributed set of small personal computers, to match
889 the quality of service that is normally only available from larger mainframe
891 host systems with co-resident UA/MTA pairs.
898 [1] SRI-NIC, ARPANET Directory, Network Information Center, SRI In-
900 ternational, Menlo Park, California (November 1980).
909 [2] Comer, D., A Computer Science Research Network CSNET: A History
911 and Status Report, Communications of the ACM, volume 26, number 10
913 (October 1983) 747-753.
916 [3] Emerson, S. L., USENET: A Bulletin Board for Unix Users. BYTE,
918 volume 8, number 10 (October 1983) 219-236.
921 [4] Vittal, J., MSG: A Simple Message System, in: Uhlig (editor), Proceed-
923 ings of the IFIP TC-6 International Symposium on Computer Message
925 Systems (North-Holland, April 1981).
928 [5] Deutsch, D., Design of a Message Format Standard, in: Uhlig (editor),
930 Proceedings of the IFIP TC-6 International Symposium on Computer
932 Message Systems (North-Holland, April 1981).
935 [6] v.Bochmann, G. and Pickens, J. R., A Methodology for the Specifica-
937 tion of a Message Transport System, in: Uhlig (editor), Proceedings of
939 the IFIP TC-6 International Symposium on Computer Message Systems
941 (North-Holland, April 1981).
944 [7] Kerr, I. H., Interconnection of Electronic Mail Systems, in: Uhlig (edi-
946 tor), Proceedings of the IFIP TC-6 International Symposium on Com-
948 puter Message Systems (North-Holland, April 1981).
951 [8] Crocker, D., Standard for the Format of ARPA Internet Text Messages
953 (RFC 822) Network Information Center, SRI International, Menlo Park,
955 California (August 1982).
958 [9] NBS, Message Format for Computer-Based Message Systems, U.S. Na-
960 tional Bureau of Standards FIPS Publication 98 (March 1983).
963 [10] CCITT Study Group VII/5, Draft Recommendation X.MHS1: Mes-
965 sage Handling Systems: System Model_Service Elements (version 2),
967 Technical Report, International Telegraph and Telephone Consultative
969 Committee (CCITT) (December 1982).
972 [11] Rose, M., Low Tech Connections into the ARPA Internet: The Raw-
974 Packet Split-Gateway, University of California Irvine Techical Report
976 number 216 (February 1984).
985 [12] Crocker, D., Szurkowski, E., Farber, D. J., An Internet Memo Distribu-
987 tion Facility_MMDF, Proceedings of the Sixth IEEE Data Communi-
989 cations Symposium (November 1979).
992 [13] Rose, M., The ZOTnet_A Local Area Mailing Network, University of
994 California Irvine Technical Report number 200 (January 1983).
997 [14] CSNET-CIC, Focus on the University of California, Irvine, CSNET
999 News 2, Bolt, Beranek, and Newman, Cambridge, Massachusetts (Octo-
1004 [15] Rose, M., Achieving Interoperability Between Two Domains_
1006 Connecting the ZOTnet and UUCP Computer Mail Networks, University
1008 of California Irvine Technical Report number 201 (January 1983).
1011 [16] Rose, M., Proposed Standard for Message Munging (RFC 886), Network
1013 Information Center, SRI International, Menlo Park, California (Decem-
1018 [17] Borden, B. S., Gaines, R. S., and Shapiro, N.Z., The Rand MH Message
1020 Handling System: User's Manual (Rand Corporation, March 1983).
1029 ________________________________________________________________________________________________________________________
1031 Any Host Relay Host Any Other Host
1051 PhoneNet PhoneNet PhoneNet PhoneNet
1055 modem modem modem modem
1059 _______________________________________Figure_1:__The_MHS_Model_________________________________________________________
1068 ________________________________________________________________________________________________________________________
1070 Any Host MZnet Host PC
1091 PhoneNet PhoneNet PhoneNet PhoneNet
1095 modem modem modem modem
1099 ____________________________________Figure_2:__The_Split-Slot_Model_____________________________________________________
projects / nmh / blob