Return to mznet.tex CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / mznet

Annotation of 43BSD/contrib/mh/papers/mznet/mznet.tex, revision 1.1

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.