mznet.tex

早期freebsd实现

% run through through LaTeX

\documentstyle[12pt]{article}
\setcounter{page}{0}
\pagestyle{empty}

\hyphenation{Phone-Net}

\def\tagfigure#1#2#3{%
    \begin{figure}[t]
	\hrule
	\vskip.5\baselineskip
	\begin{small}\rm
	    \input#1\relax
	    \centerline{\box\graph}
	\end{small}
	\vskip.5\baselineskip plus.5\baselineskip
	\caption{#2}
	\label{#3}
	\vskip2pt
	\hrule
    \end{figure}
}

\begin{document}

\title{MZnet:  Mail Service for Personal Micro-Computer Systems}
\author{Einar Stefferud\\
	\it President,\\
	\it Network Management Associates\\
	and\\
	\it Visiting Lecturer,\\
	\it in Information and Computer Science\\
	\it University of California at Irvine\\ \quad\\
Jerry Sweet\\
	\it Department of Information and Computer Science\\
	\it University of California at Irvine\\ \quad\\
Terrance Domae\\
	\it School of Engineering\\
	\it University of California at Los Angeles}
\date{}
\maketitle

\newpage

\begin{abstract}
Traditional computer mail systems involve a co-resident User Agent (UA)
and Mail Transfer System (MTS) on a time-shared host computer 
which may be connected to other hosts in a network,
with new mail posted or delivered directly through 
co-resident mail-slot programs.
To introduce personal micro-computers (PCs) into this environment 
requires modification of the traditional mail system architecture.
To this end, the MZnet project uses a {\it split-slot} model,
placing UA programs on the PCs while leaving MTA programs
on a mail relay host which can provide authentication and buffering.
The split-slot arrangement might be viewed as a new protocol level which 
operates somewhere between the currently defined MTS-MTS and UA-UA levels. 
\end{abstract}

\newpage\pagestyle{plain}\pagenumbering{arabic}

\section*	{Introduction}
Mail systems were born and have grown up on large central
time sharing systems,
often imbedded in large networks of inter-operating computers with 
a set of distributed processes automatically transferring mail
between users.  
This is certainly the case with the U.S. Department of Defense (DoD) 
Advanced Research Projects Agency Network (ARPANET)
\cite{ARPANET-Literature}
where much of the original computer network mail systems 
research and development has taken place.  
Other mail networks such as the Computer Science Network
\cite{CACM-83}
sponsored by the U.S. National Science Foundation,
have also used relatively large shared computers 
lodged in an institutional setting,
though they are often connected together with ordinary dial-up
telephone links to form a large geographic network.    
Another U.S. example is USENET
\cite{USENET-Literature}
which connects thousands of Unix\footnote{UNIX is
a Trademark of Bell Laboratories, Inc.}
systems together with informally-supported dial telephone links.
Although there have been several attempts, there appear to be no 
successful mail networks based on small personal computers, 
such as those that use the CP/M\footnote{CP/M is a
Trademark of Digital Research, Inc.}
or MS-DOS\footnote{MS-DOS is a Trademark of Microsoft Corporation.}
operating systems.  

\tagfigure{figure1}{The MHS Model}{mhsmodel}
The accepted architectural model (see Figure~\ref{mhsmodel})
for computer network mail
(first articulated by the IFIP 6.5 Systems Environment Working Group) 
involves a User Agent (UA) which posts new mail items through a mail slot
\cite{Vittal81,Deutsch81,Pickens81,Kerr81}
to a Mail Transfer Agent (MTA) which delivers posted items 
to designated UA recipients through corresponding delivery slots.  
When mail is to be delivered to a UA on another host, it is transferred
first to another MTA on the recipient user's host, which in turn puts
the mail item through its local delivery slot.  
In this model, a Mail Transfer System (MTS) may be viewed 
as a collection of MTAs with network connections among them 
to provide Mail Transfer Services for a large number of users on 
different host computers.

Replicating this UA/MTA/MTS model on a personal micro-computer (PC)
is not an easy task.
Aspects of PCs that make support of this model difficult include
limited storage capacities,
limited processing capabilities,
and the fact that PCs are geared to support a single user
rather than several users at once.
A PC with limited secondary diskette storage and 
limited processing capacity (often single-thread) is not well suited 
to support the full range of automatic interactions between a UA and 
an MTA, or the necessary interactions between MTAs in an MTS. 
For example,
we do not see any way to certify PC systems for authentication 
of posted mail.  
A PC can change its entire character and behavior with insertion of a new 
program diskette, suggesting that it is the operating system 
diskettes and their users that must be certified, rather than the computers.  
Review of certification issues shows that it is not the computer, 
but its operators and managers that must be certified, 
and this involves the notions of central management and control.  
All this is lost in the maze of PCs that we see proliferating 
on and off our campuses, in and out of our offices and homes.  

Thus, we see a need for a new arrangement with the UA separated from 
its MTA, and using communication protocols to interact with it in ways 
that resemble MTA-to-MTA interactions.
The UA is placed on the PC end, while the more complex
tasks performed by the MTA are relegated to the remote host end.
The remote MTA must authenticate mail items offered by the PC-based 
UA, just as it would for a co-located UA, but the task is more difficult 
because the PC UA is potentially anyone among the public telephone 
connectable population.  
This can be handled with password systems, but recognition and 
identification are not the only services to be provided at the posting slot.  
Posting also requires some validation of recipient addresses, 
and validation of the syntax and semantics of certain header fields.
Example standards are provided by the U.S. National Bureau of Standards 
(NBS) and the U.S. DoD ARPANET for the format of mail to be transferred
\cite{RFC-822,NBS,CCITT}.

The new arrangement described in this paper might be called a
{\it split mail slot} in that the UA side of the slot is split away from 
the MTA side.  
Although the UA and MTA may be on opposite ends of a telephone connection, 
they must still act together as a single processing unit 
to move mail from one to the other, with all that this may entail.  
This gives rise to a number of new MTA/UA requirements such as error 
control for service requests, user intervention to select items for 
delivery, and user postponement or rejection of delivery without 
triggering failure notices to senders.  
These are not serious problems when both MTA and UA are 
programs running on a single host.  
For example, with both UA and MTA on the same host, 
unwanted junk mail is simply deleted at low cost, 
compared to the cost of deletion after a long delivery transmission time.  
Better that our PC users be able to discard items 
without delivery transmission.  

\subsection*	{Overview of the MZnet Environment}
The MZnet project is an undergraduate student effort sponsored within 
the Information and Computer Science (ICS) Department of the 
University of California at Irvine (UCI) in Southern California.  
For the past 2 years, the UCI mail network, known as
ZOTnet, has been connected into the Computer Science 
Network (CSnet) and in 1984, has joined the DoD ARPA Internet with a 
{\it Split-Gateway} connection \cite{Rose84}
to the University of Southern California 
Information Sciences Institute (USC-ISI).  
The MZnet split-slot arrangement may have some similarities to the 
Split-Slot Internet Gateway
at least in name, 
but the problems and the implementations are quite different.  

The UCI ZOTnet environment \cite{Rose83-1}
gives the MZnet project a full-fledged
Internet-class mail system as its foundation.  
The MZnet project objective is to extend this class 
of mail service to personal computers located in student and faculty 
residences, offices and laboratories, without waiting for full-blown 
local area networking to first provide connections.  
This follows a pattern of making the most of existing facilities 
to provide a reasonable level of service.

The UCI ZOTnet uses the CSnet-provided MMDF
(Multi-channel Memo Distribution Facility) software \cite{MMDF}
from the University of Delaware to interconnect 
two VAX 750 Unix systems with two DEC TOPS-20 systems 
through a port selector, with dial telephone connection to a CSnet relay
\cite{CSNET-UCI}.
The ZOTnet has since evolved into an ethernet-connected 
local area network with the aforementioned
gateway connection into the DoD Internet.
The ZOTnet also connects to USENET with the UUCP protocols,
and provides format transformations for mail flowing between 
protocol domains
\cite{Rose83-2,RFC-MMM}.
Adding to the reach of the ZOTnet with MZnet 
is a natural part of its evolution\footnote{For those who are
properly curious about such things, 
the name ``ZOTnet'' derives from the cry of the UCI mascot which 
is the Anteater from the B.C. comic strip, and MZnet is simply 
a contraction for Micro-ZOTnet.}.

To this point we have set the context of the MZnet project.
The remainder of this paper is devoted to relatively technical 
discussions of implementation of the PC user agent programs 
and the split-slot UA/MTA interface. 

\section*	{The MZnet User Agent: CP/MH}
CP/MH is a collection of programs designed to work in conjunction
with the Micro ZOTnet (MZnet) as an extension of the UCI ZOTnet.
CP/MH programs permit a user of a CP/M 2.2-based microcomputer to
send and receive ZOTnet mail messages, as well as to manipulate
them locally on floppy disks.  
The CP/MH programs are written in the C programming language and 
should be portable to similar operating environments, such as MS-DOS, etc.

CP/MH is based on the UCI version of the Rand MH message handling system
\cite{MH}
for the Unix operating system.  
The major philosophical differences between CP/MH and typical user agents
such as MSG
\cite{Vittal81}
and its descendants are those of modularity and of user interface.  
In CP/MH (as in MH) the user does not invoke a single monolithic program 
to deal with mail, but rather invokes individual, 
non-interactive programs with common knowledge
of the way messages are stored.  
Each program has default behavior which can be modified by using Unix-style 
command line options at time of invocation or through a user profile.  
Help messages can also be evoked from CP/MH programs.

\subsection*	{Messages and Folders}
The format of a CP/MH message adheres more or less to the syntax
described in RFC 822
in which a message consists of headers containing information pertaining 
to the message source and destination, 
and the message body, separated from the headers by a blank line.  
An example of such a message might be:

\begin{verbatim}
     Date: 02 Nov 83 23:04:53 PST (Wed) 
     To: Toto <dog@Univ-Kansas>
     From: The Great And Powerful Oz <Oz@Emerald-City>
     Subject: What Be Your Excuse?

     What's the matter?  I ask you for a simple thing like
     "distribute this to Witch@Oz-West," and you can't do it.
     You undergrads will do anything to get out of work!

     --ozzie
\end{verbatim}

Following the MH convention, each message is kept in a separate file.  
Since a message is simply ASCII text, it can be operated upon by 
non-CP/MH programs (such as text editors, in particular).

Collections of messages are called {\it folders}.  Under CP/MH,
folders are represented by several files: an {\it info} file,
containing maintenance information about the folder, and a set
of message files with the same name as the info file, but with
unique numeric suffixes ({\it extensions} in CP/M parlance).  
An example of this naming scheme might be:

{\tt
\begin{description}
\item[{\tt DRAFT}]  	{\rm the info file for the {\tt DRAFT} folder}
\item[{\tt DRAFT.001}]  {\rm message 1 in the folder}
\item[{\tt DRAFT.002}]  {\rm message 2 in the folder}
\item[{\tt DRAFT.003}]  {\rm message 3 in the folder}
\end{description}
}

The number of messages that may be stored in a folder is limited
primarily by the storage capacity of a floppy disk, but also by
the three-digit limit of a CP/M extension.  

The info file contains a field named {\tt CURRENT:} specifying the
current message number.  
The current message number signifies the default message operated upon 
by CP/MH commands using a particular folder.  
The current message number may be modified by some commands.  
An example of the contents of the info file {\tt DRAFT} might be