![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to mznet.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / mznet|
Return to mznet.tex CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / mznet |
1.1 root 1: % run through through LaTeX
2:
3: \documentstyle[12pt]{article}
4: \setcounter{page}{0}
5: \pagestyle{empty}
6:
7: \hyphenation{Phone-Net}
8:
9: \def\tagfigure#1#2#3{%
10: \begin{figure}[t]
11: \hrule
12: \vskip.5\baselineskip
13: \begin{small}\rm
14: \input#1\relax
15: \centerline{\box\graph}
16: \end{small}
17: \vskip.5\baselineskip plus.5\baselineskip
18: \caption{#2}
19: \label{#3}
20: \vskip2pt
21: \hrule
22: \end{figure}
23: }
24:
25: \begin{document}
26:
27: \title{MZnet: Mail Service for Personal Micro-Computer Systems}
28: \author{Einar Stefferud\\
29: \it President,\\
30: \it Network Management Associates\\
31: and\\
32: \it Visiting Lecturer,\\
33: \it in Information and Computer Science\\
34: \it University of California at Irvine\\ \quad\\
35: Jerry Sweet\\
36: \it Department of Information and Computer Science\\
37: \it University of California at Irvine\\ \quad\\
38: Terrance Domae\\
39: \it School of Engineering\\
40: \it University of California at Los Angeles}
41: \date{}
42: \maketitle
43:
44: \newpage
45:
46: \begin{abstract}
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.
59: \end{abstract}
60:
61: \newpage\pagestyle{plain}\pagenumbering{arabic}
62:
63: \section* {Introduction}
64: Mail systems were born and have grown up on large central
65: time sharing systems,
66: often imbedded in large networks of inter-operating computers with
67: a set of distributed processes automatically transferring mail
68: between users.
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
75: \cite{CACM-83}
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.}
91: operating systems.
92:
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.
108:
109: Replicating this UA/MTA/MTS model on a personal micro-computer (PC)
110: is not an easy task.
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.
120: For example,
121: we do not see any way to certify PC systems for authentication
122: of posted mail.
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.
131:
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}.
148:
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
151: the MTA side.
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.
166:
167: \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
179: at least in name,
180: but the problems and the implementations are quite different.
181:
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.
191:
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
197: \cite{CSNET-UCI}.
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
203: protocol domains
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.}.
211:
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.
216:
217: \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.
225:
226: CP/MH is based on the UCI version of the Rand MH message handling system
227: \cite{MH}
228: for the Unix operating system.
229: The major philosophical differences between CP/MH and typical user agents
230: such as MSG
231: \cite{Vittal81}
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.
240:
241: \subsection* {Messages and Folders}
242: The format of a CP/MH message adheres more or less to the syntax
243: described in RFC 822
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:
248:
249: \begin{verbatim}
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?
254:
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!
258:
259: --ozzie
260: \end{verbatim}
261:
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).
265:
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:
272:
273: {\tt
274: \begin{description}
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}
279: \end{description}
280: }
281:
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.
285:
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
292:
293: \begin{flushleft}
294: \hspace{.5in} {\tt CURRENT: 3}
295: \end{flushleft}
296:
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).
300:
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).
305:
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.
309:
310: \subsection* {CP/MH Commands}
311: Commands operating on messages can be divided into several general categories:
312: \medskip
313: \begin{description}
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
318: \end{description}
319:
320: \medskip
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.
324:
325: A minimal functionality is presently provided by the following four commands:
326: \medskip
327: \begin{description}
328: \item[COMP]
329: composes mail items:
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.
334: \item[REPL]
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.
340: \item[SEND]
341: sends mail items:
342: posts selected items through the split-slot from a draft folder.
343: \item[INC]
344: receives mail items:
345: takes delivery of selected items
346: across the split-slot, incorporating
347: them into a mailbox folder.
348: \end{description}
349: \medskip
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.
353:
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}.
361:
362: An example of use of a CP/MH command is:
363:
364: \begin{flushleft}
365: \hspace{1in} {\tt comp -edit a:ed -use last +b:draft -log}
366: \end{flushleft}
367:
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).
373:
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.
381:
382: \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:
389:
390: {\tt
391: \begin{flushleft}
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
396: \end{flushleft}
397: }
398:
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).
402:
403: \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}
413:
414: \subsection* {The Structure of the Split-Slot}
415: The MZnet Split Gateway consists of three distributed processing components:
416: \medskip
417: \begin{itemize}
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.
423: \end{itemize}
424: \medskip
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.
433:
434: \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
439: on the host.
440: Some basic commands are:
441:
442: \medskip
443: \begin{description}
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
448: \end{description}
449:
450: \medskip
451: Each command has the form:
452:
453: \begin{flushleft}
454: \hspace{.5in} Command Request \\
455: \hspace{.5in} Data Transmission \\
456: \hspace{.5in} Command Termination
457: \end{flushleft}
458:
459: For example, the PostMail command is a small program that:
460: \medskip
461: \begin{itemize}
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.
469: \end{itemize}
470:
471: \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
480: recipients.
481:
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.
496:
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
502: of originated mail.
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.
511:
512: \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
516: ASCII plaintext.
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.
523:
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.
529:
530: \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
539: function.
540: The prompt of the PC for a UA command is ``A$\rangle$''.
541: Note that passwords are never echoed by the host system.
542:
543: \begin{tabbing}
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.}
559: \end{tabbing}
560:
561: \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.
570:
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.
574:
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.
580:
581: \bibliography{mznet}
582:
583: \end{document}
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.