1 % run through through LaTeX
3 \documentstyle[12pt]{article}
7 \hyphenation{Phone-Net}
15 \centerline{\box\graph}
17 \vskip.5\baselineskip plus.5\baselineskip
27 \title{MZnet: Mail Service for Personal Micro-Computer Systems}
28 \author{Einar Stefferud\\
30 \it Network Management Associates\\
32 \it Visiting Lecturer,\\
33 \it in Information and Computer Science\\
34 \it University of California at Irvine\\ \quad\\
36 \it Department of Information and Computer Science\\
37 \it University of California at Irvine\\ \quad\\
39 \it School of Engineering\\
40 \it University of California at Los Angeles}
47 Traditional computer mail systems involve a co-resident User Agent (UA)
48 and Mail Transfer System (MTS) on a time-shared host computer
49 which may be connected to other hosts in a network,
50 with new mail posted or delivered directly through
51 co-resident mail-slot programs.
52 To introduce personal micro-computers (PCs) into this environment
53 requires modification of the traditional mail system architecture.
54 To this end, the MZnet project uses a {\it split-slot} model,
55 placing UA programs on the PCs while leaving MTA programs
56 on a mail relay host which can provide authentication and buffering.
57 The split-slot arrangement might be viewed as a new protocol level which
58 operates somewhere between the currently defined MTS-MTS and UA-UA levels.
61 \newpage\pagestyle{plain}\pagenumbering{arabic}
63 \f\section* {Introduction}
64 Mail systems were born and have grown up on large central
66 often imbedded in large networks of inter-operating computers with
67 a set of distributed processes automatically transferring mail
69 This is certainly the case with the U.S. Department of Defense (DoD)
70 Advanced Research Projects Agency Network (ARPANET)
71 \cite{ARPANET-Literature}
72 where much of the original computer network mail systems
73 research and development has taken place.
74 Other mail networks such as the Computer Science Network
76 sponsored by the U.S. National Science Foundation,
77 have also used relatively large shared computers
78 lodged in an institutional setting,
79 though they are often connected together with ordinary dial-up
80 telephone links to form a large geographic network.
81 Another U.S. example is USENET
82 \cite{USENET-Literature}
83 which connects thousands of Unix\footnote{UNIX is
84 a Trademark of Bell Laboratories, Inc.}
85 systems together with informally-supported dial telephone links.
86 Although there have been several attempts, there appear to be no
87 successful mail networks based on small personal computers,
88 such as those that use the CP/M\footnote{CP/M is a
89 Trademark of Digital Research, Inc.}
90 or MS-DOS\footnote{MS-DOS is a Trademark of Microsoft Corporation.}
93 \tagfigure{figure1}{The MHS Model}{mhsmodel}
94 The accepted architectural model (see Figure~\ref{mhsmodel})
95 for computer network mail
96 (first articulated by the IFIP 6.5 Systems Environment Working Group)
97 involves a User Agent (UA) which posts new mail items through a mail slot
98 \cite{Vittal81,Deutsch81,Pickens81,Kerr81}
99 to a Mail Transfer Agent (MTA) which delivers posted items
100 to designated UA recipients through corresponding delivery slots.
101 When mail is to be delivered to a UA on another host, it is transferred
102 first to another MTA on the recipient user's host, which in turn puts
103 the mail item through its local delivery slot.
104 In this model, a Mail Transfer System (MTS) may be viewed
105 as a collection of MTAs with network connections among them
106 to provide Mail Transfer Services for a large number of users on
107 different host computers.
109 Replicating this UA/MTA/MTS model on a personal micro-computer (PC)
111 Aspects of PCs that make support of this model difficult include
112 limited storage capacities,
113 limited processing capabilities,
114 and the fact that PCs are geared to support a single user
115 rather than several users at once.
116 A PC with limited secondary diskette storage and
117 limited processing capacity (often single-thread) is not well suited
118 to support the full range of automatic interactions between a UA and
119 an MTA, or the necessary interactions between MTAs in an MTS.
121 we do not see any way to certify PC systems for authentication
123 A PC can change its entire character and behavior with insertion of a new
124 program diskette, suggesting that it is the operating system
125 diskettes and their users that must be certified, rather than the computers.
126 Review of certification issues shows that it is not the computer,
127 but its operators and managers that must be certified,
128 and this involves the notions of central management and control.
129 All this is lost in the maze of PCs that we see proliferating
130 on and off our campuses, in and out of our offices and homes.
132 Thus, we see a need for a new arrangement with the UA separated from
133 its MTA, and using communication protocols to interact with it in ways
134 that resemble MTA-to-MTA interactions.
135 The UA is placed on the PC end, while the more complex
136 tasks performed by the MTA are relegated to the remote host end.
137 The remote MTA must authenticate mail items offered by the PC-based
138 UA, just as it would for a co-located UA, but the task is more difficult
139 because the PC UA is potentially anyone among the public telephone
140 connectable population.
141 This can be handled with password systems, but recognition and
142 identification are not the only services to be provided at the posting slot.
143 Posting also requires some validation of recipient addresses,
144 and validation of the syntax and semantics of certain header fields.
145 Example standards are provided by the U.S. National Bureau of Standards
146 (NBS) and the U.S. DoD ARPANET for the format of mail to be transferred
147 \cite{RFC-822,NBS,CCITT}.
149 The new arrangement described in this paper might be called a
150 {\it split mail slot} in that the UA side of the slot is split away from
152 Although the UA and MTA may be on opposite ends of a telephone connection,
153 they must still act together as a single processing unit
154 to move mail from one to the other, with all that this may entail.
155 This gives rise to a number of new MTA/UA requirements such as error
156 control for service requests, user intervention to select items for
157 delivery, and user postponement or rejection of delivery without
158 triggering failure notices to senders.
159 These are not serious problems when both MTA and UA are
160 programs running on a single host.
161 For example, with both UA and MTA on the same host,
162 unwanted junk mail is simply deleted at low cost,
163 compared to the cost of deletion after a long delivery transmission time.
164 Better that our PC users be able to discard items
165 without delivery transmission.
167 \f\subsection* {Overview of the MZnet Environment}
168 The MZnet project is an undergraduate student effort sponsored within
169 the Information and Computer Science (ICS) Department of the
170 University of California at Irvine (UCI) in Southern California.
171 For the past 2 years, the UCI mail network, known as
172 ZOTnet, has been connected into the Computer Science
173 Network (CSnet) and in 1984, has joined the DoD ARPA Internet with a
174 {\it Split-Gateway} connection \cite{Rose84}
175 to the University of Southern California
176 Information Sciences Institute (USC-ISI).
177 The MZnet split-slot arrangement may have some similarities to the
178 Split-Slot Internet Gateway
180 but the problems and the implementations are quite different.
182 The UCI ZOTnet environment \cite{Rose83-1}
183 gives the MZnet project a full-fledged
184 Internet-class mail system as its foundation.
185 The MZnet project objective is to extend this class
186 of mail service to personal computers located in student and faculty
187 residences, offices and laboratories, without waiting for full-blown
188 local area networking to first provide connections.
189 This follows a pattern of making the most of existing facilities
190 to provide a reasonable level of service.
192 The UCI ZOTnet uses the CSnet-provided MMDF
193 (Multi-channel Memo Distribution Facility) software \cite{MMDF}
194 from the University of Delaware to interconnect
195 two VAX 750 Unix systems with two DEC TOPS-20 systems
196 through a port selector, with dial telephone connection to a CSnet relay
198 The ZOTnet has since evolved into an ethernet-connected
199 local area network with the aforementioned
200 gateway connection into the DoD Internet.
201 The ZOTnet also connects to USENET with the UUCP protocols,
202 and provides format transformations for mail flowing between
204 \cite{Rose83-2,RFC-MMM}.
205 Adding to the reach of the ZOTnet with MZnet
206 is a natural part of its evolution\footnote{For those who are
207 properly curious about such things,
208 the name ``ZOTnet'' derives from the cry of the UCI mascot which
209 is the Anteater from the B.C. comic strip, and MZnet is simply
210 a contraction for Micro-ZOTnet.}.
212 To this point we have set the context of the MZnet project.
213 The remainder of this paper is devoted to relatively technical
214 discussions of implementation of the PC user agent programs
215 and the split-slot UA/MTA interface.
217 \f\section* {The MZnet User Agent: CP/MH}
218 CP/MH is a collection of programs designed to work in conjunction
219 with the Micro ZOTnet (MZnet) as an extension of the UCI ZOTnet.
220 CP/MH programs permit a user of a CP/M 2.2-based microcomputer to
221 send and receive ZOTnet mail messages, as well as to manipulate
222 them locally on floppy disks.
223 The CP/MH programs are written in the C programming language and
224 should be portable to similar operating environments, such as MS-DOS, etc.
226 CP/MH is based on the UCI version of the Rand MH message handling system
228 for the Unix operating system.
229 The major philosophical differences between CP/MH and typical user agents
232 and its descendants are those of modularity and of user interface.
233 In CP/MH (as in MH) the user does not invoke a single monolithic program
234 to deal with mail, but rather invokes individual,
235 non-interactive programs with common knowledge
236 of the way messages are stored.
237 Each program has default behavior which can be modified by using Unix-style
238 command line options at time of invocation or through a user profile.
239 Help messages can also be evoked from CP/MH programs.
241 \f\subsection* {Messages and Folders}
242 The format of a CP/MH message adheres more or less to the syntax
244 in which a message consists of headers containing information pertaining
245 to the message source and destination,
246 and the message body, separated from the headers by a blank line.
247 An example of such a message might be:
250 Date: 02 Nov 83 23:04:53 PST (Wed)
251 To: Toto <dog@Univ-Kansas>
252 From: The Great And Powerful Oz <Oz@Emerald-City>
253 Subject: What Be Your Excuse?
255 What's the matter? I ask you for a simple thing like
256 "distribute this to Witch@Oz-West," and you can't do it.
257 You undergrads will do anything to get out of work!
262 Following the MH convention, each message is kept in a separate file.
263 Since a message is simply ASCII text, it can be operated upon by
264 non-CP/MH programs (such as text editors, in particular).
266 Collections of messages are called {\it folders}. Under CP/MH,
267 folders are represented by several files: an {\it info} file,
268 containing maintenance information about the folder, and a set
269 of message files with the same name as the info file, but with
270 unique numeric suffixes ({\it extensions} in CP/M parlance).
271 An example of this naming scheme might be:
275 \item[{\tt DRAFT}] {\rm the info file for the {\tt DRAFT} folder}
276 \item[{\tt DRAFT.001}] {\rm message 1 in the folder}
277 \item[{\tt DRAFT.002}] {\rm message 2 in the folder}
278 \item[{\tt DRAFT.003}] {\rm message 3 in the folder}
282 The number of messages that may be stored in a folder is limited
283 primarily by the storage capacity of a floppy disk, but also by
284 the three-digit limit of a CP/M extension.
286 The info file contains a field named {\tt CURRENT:} specifying the
287 current message number.
288 The current message number signifies the default message operated upon
289 by CP/MH commands using a particular folder.
290 The current message number may be modified by some commands.
291 An example of the contents of the info file {\tt DRAFT} might be
294 \hspace{.5in} {\tt CURRENT: 3}
297 This indicates that the file {\tt DRAFT.003} would be operated upon
298 when default conditions apply (i.e. when no message number is
299 explicitly given to a CP/MH command).
301 Possible future uses for the info file include named message sequences
302 (a set of messages to which commands may be applied as a whole) and
303 user profile information for application to particular folders (there
304 is presently a single user profile, described shortly).
306 A floppy diskette may contain more than one folder, but folders
307 do not extend over more than one floppy diskette; therefore two
308 different diskettes may contain folders with the same name.
310 \f\subsection* {CP/MH Commands}
311 Commands operating on messages can be divided into several general categories:
314 \item[Transporting:] sending, receiving
315 \item[Viewing:] selecting for display, showing header summaries
316 \item[Creating:] composing, replying, forwarding
317 \item[Archiving:] categorizing, refiling, deleting, sorting
321 The architecture of CP/MH permits the simulation of some of these
322 categories using standard CP/M commands when CP/MH, in its present
323 primitive state, does not cover them.
325 A minimal functionality is presently provided by the following four commands:
330 creates a file containing header information taken
331 from a standard or user-specified template.
332 This newly-created file may be edited to fill in
333 the header fields and body.
335 replies to mail items:
336 creates a file containing header
337 information appropriate for answering a given mail item.
338 This newly-created file may be edited to
339 change header fields and fill in the body.
342 posts selected items through the split-slot from a draft folder.
345 takes delivery of selected items
346 across the split-slot, incorporating
347 them into a mailbox folder.
350 These commands, with a few enhancements and modifications
351 appropriate to the CP/M environment, are functionally almost
352 identical to their Unix MH counterparts.
354 CP/MH commands are invoked like any other
355 CP/M commands such as ED, PIP, or DIR.
356 Command line options are generally preceded by a dash
357 (e.g. {\tt -editor A:ED}), and may be abbreviated.
358 Folder names are preceded by a plus (e.g. {\tt +B:DRAFT}).
359 Messages are identified by numbers or by the special names {\tt first},
360 {\tt last}, {\tt current}, {\tt next}, and {\tt previous}.
362 An example of use of a CP/MH command is:
365 \hspace{1in} {\tt comp -edit a:ed -use last +b:draft -log}
368 This particular example will edit the last-composed message (the
369 {\tt -use last} option) in the folder {\tt DRAFT} on disk drive {\tt B:}
370 (the {\tt +b:draft} option), using the standard CP/M editor ED on disk
371 drive {\tt A:} (the {\tt -edit a:ed} option), and prompting the user when
372 it is appropriate to change disks (the {\tt -log} option).
374 All CP/MH commands have a {\tt -help} option which displays all
375 available options for the particular command invoked.
376 Another common option is {\tt -log} which permits the user to change
377 ({\it relog}) diskettes after invoking a command, for purposes of
378 selecting diskettes with message folders or with editor programs.
379 This is particularly useful on single-drive systems or on systems
380 with diskettes of low storage capacity.
382 \f\subsection* {The Profile}
383 If there are options commonly used with a particular CP/MH command,
384 they may be entered in the user profile contained in the file called
385 (naturally enough) {\tt PROFILE}, which must exist on the same diskette on
386 which CP/MH commands reside and from which the commands are invoked.
387 A profile entry consists of a program name followed by a colon and
388 the options to be used with that program, for example:
392 \hspace{1in} comp: -editor A:VEDIT +B:outbox -log \\
393 \hspace{1in} repl: -editor A:VEDIT -log \\
394 \hspace{1in} send: +B:outbox \\
395 \hspace{1in} inc: +B:inbox -log
399 Individual profile components are overridden by options given at
400 the time of invocation (e.g. {\tt -noedit} given on the command line
401 will override the {\tt -editor} profile component for a particular command).
403 \f\section* {The MZnet Split-Slot Mail Transfer System}
404 The MZnet split-slot software implements a peer-to-peer
405 communication protocol between a time-sharing host's MTA and a personal
406 micro-computer (PC) UA.
407 This MZnet protocol extends the UA/MTA/UA model of
408 computer-based message systems (CBMS) to provide a
409 split gateway function between individual PCs and the ZOTnet
410 similar to the UCI ICS split Internet gateway described previously
411 (see Figure~\ref{splitslot}).
412 \tagfigure{figure2}{The Split-Slot Model}{splitslot}
414 \f\subsection* {The Structure of the Split-Slot}
415 The MZnet Split Gateway consists of three distributed processing components:
418 \item A PC running a UA (in MZnet, CP/MH) acting as the mail server.
419 \item A mini/mainframe host running a full MTA (MMDF in MZnet)
420 providing mail relay services.
421 \item A communication protocol (a modified version of MMDF PhoneNet) to
422 connect the two ends of the split-slot.
425 Although this combination may not be unique, the method by which the MZnet
426 split-slot bonds these parts together uniquely deals with the
427 problems of remote user agents.
428 In addition to overcoming limited storage and processing capacities,
429 remote user agents must deal with noisy modem lines,
430 mail software certification, and mail system security problems.
431 The MZnet architecture appears to solve these problems with
432 a clean mail interface for PCs.
434 \f\subsection* {The MZnet Mail Server}
435 The split-slot mail server consists of a set of {\it command packet}
436 programs run from the PC.
437 These programs simply present commands
438 through the PhoneNet communication protocol to the mail relay slave program
440 Some basic commands are:
444 \item[PostMail] posts mail drafts to MTA
445 \item[GetMail] accepts mail from MTA
446 \item[RemoteScan] displays information about waiting mail
447 \item[Quit] drops connection between PC and Host
451 Each command has the form:
454 \hspace{.5in} Command Request \\
455 \hspace{.5in} Data Transmission \\
456 \hspace{.5in} Command Termination
459 For example, the PostMail command is a small program that:
462 \item initiates a command with the Mail Slave by sending the command
463 name (PostMail) encoded within a PhoneNet packet;
464 \item sends a series of PhoneNet packets that contain pieces of
465 the mail item to be posted;
466 \item finally sends a command termination signal to end
467 the transaction without
468 terminating the connection between host and PC.
471 \f\subsection* {The MZnet Channel To MMDF}
472 The MZnet Channel runs on the MTA host under the University of Delaware's
473 MMDF (Version 1) and is responsible for both delivery of received mail
474 to MZnet users, and posting of MZnet user-originated mail.
475 The MMDF MZnet channel maintains a unique message queue for each
476 registered MZnet user.
477 As new mail items arrive,
478 they are posted to the appropriate queues,
479 where MZnet holds the mail items for pickup by their registered
482 To send or receive mail,
483 the MZnet user must attach to the host,
484 log into the public MZnet account,
485 and identify (authenticate) himself.
486 During the MZnet session with the host,
487 the user has access only to that restricted set of functions
488 provided by the MZnet split gateway protocol:
489 he may request delivery of queued mail with GetMail,
490 or post new mail with PostMail.
491 Prior to taking delivery of queued mail,
492 a survey of waiting mail also may be requested with RemoteScan to obtain
493 message size information (among other data)
494 to allow intelligent disposition
495 of mail in the queue.
497 Hidden within these activities are issues of security and certification.
498 To certify and establish the identity of the user,
499 a second password is requested after logging into the
500 public MZnet account.
501 This certification procedure allows MZnet to certify the source
503 A relatively secure environment is provided by MZnet,
504 as it is the only interface to the host permitted to MZnet users
505 (once beyond the public login procedure),
506 and it offers only the severely restricted set of
507 PhoneNet-encoded commands.
508 Aside from security issues,
509 using a single account to handle all MZnet users
510 reduces demands on system resources.
512 \f\subsection* {The MZnet-PhoneNet Protocol}
513 A unique facet of the MZnet system derives from the PhoneNet File
514 Transfer Protocol (FTP).
515 PhoneNet FTP is a simple error-checked packet protocol which transfers
517 PhoneNet encodes any non-plaintext character (or any other character
518 ``forbidden'' by the idiosyncrasies of the communicating systems) by
519 mapping it onto an ``accepted'' character set.
520 The accepted character set mapping is determined by
521 a ``negotiating'' session between the two systems at the start of
522 the PhoneNet session.
524 MZnet transfers all information (both commands and data) in PhoneNet
525 packets to obtain error control.
526 The MZnet-PhoneNet command FTP tolerates noise with a high degree
527 of success, and in effect, connects both ends of the Split Slot
528 together with a reliable set of virtual wires.
530 \f\subsection* {MZnet Session Example}
531 Here, a typical MZnet session is presented, with the UA commands
532 issued from the PC side of the connection printed
533 in a {\tt typewriter} typeface, and the responses
534 from the host side printed
535 in an {\it italic} typeface.
536 PhoneNet interactions are indented.
537 The initial connection to the host is accomplished with the
538 {\tt term} program, which provides a simple terminal emulation
540 The prompt of the PC for a UA command is ``A$\rangle$''.
541 Note that passwords are never echoed by the host system.
544 xxxxxxxx \= xxxxxxx \= \kill
545 \> A$\rangle$ {\tt term} \\
546 \> {\it login:} {\tt mznet} \\
547 \> {\it password:} \\
548 \> {\it MZ-Password:} \\
549 \> \> PhoneNet packet negotiation \\
550 \> {\it Connected.} \\
551 \> \> exit terminal mode \\
552 \> A$\rangle$ {\tt send cur} \\
553 \> \> PostMail command \\
554 \> \> message text packet transmission \\
555 \> \> command terminator \\
556 \> A$\rangle$ {\tt quit} \\
557 \> \> Quit command \\
558 \> {\it Disconnecting.}
561 \f\section* {Conclusions}
562 The main conclusions of this paper are that
563 small personal computer systems
564 with dial-up phone connections constrain User Agent systems design
565 in ways that require use of a {\it split-slot} interface between
566 the UA and its supporting Mail Transfer Agent (MTA), and that
567 this interface will best provide the required services if it
568 has error controlled command and data transfer facilities, with
569 interactive behavior.
571 It is also believed that a good design for the small PC UA
572 is based on a very modular architecture, such as the Rand MH
573 system, which has been used as a pattern for the MZnet UA.
575 By bringing these concepts together,
576 we expect MZnet to provide reliable UA/MTA
577 service to a distributed set of small personal computers, to match
578 the quality of service that is normally only available from larger
579 mainframe host systems with co-resident UA/MTA pairs.