text.tex

早期freebsd实现

alternative would be to use a received message as the blank form to add a
degree of central control over time and attendance reporting forms.

Receiving supervisors could simply register approval by using the \MH/
\pgm{dist} command to resend subordinates' time cards to higher approval
levels, or
to send them to a time card collection address.
The \MH/ \pgm{dist} command automatically inserts ``ReSent'' header fields
showing who resent it and the resending date.
Alternatively,
the MH \pgm{forw} command could be used to transfer a batch of approved time
cards to the next processing station.
If desired, a new ``approval'' command could be programmed to provide a more
trusted authentication, perhaps with encryption of the content.
Trusted mail systems, such as \trustedmail/\cite{MRose85c},
are becoming available for this purpose.

At the final collection destination,
an automated User Agent could be programmed to directly load the data into
the Time and Attendance DBMS by
parsing and decoding the data contained in the \eg{X-time$\tdots$:} fields.
It might be noted that while the RFC822 does not restrict the
internal forms of messages,
it is necessary to conform to the interchange standard if specialized filters
for message headers are not to be built to serve as {\it export laundries}
(a term originating with Stephen H.~Willson to describe conformance
transformations in \Ada/).

\subsection{Mapping Between Record Modes (DBMS/MHS)}
This time and attendance example suggests that it is possible to define
one-to-one mappings between RFC822 fields and DBMS data elements.
For every DBMS data element definition,
there is a potential corresponding RFC822 transferable equivalent
definition which can facilitate mail transfers of record information.
Indeed,
a large portion of the definitional work is already done where a Data Base
has already been defined.
All that remains is to define the RFC822 equivalents.

The suggestion that a batch of time cards be forwarded inside a ``cover''
message implies that it is possible in the \MH/ framework to recursively
bundle messages within messages, and be able to recover the originals for
separate processing at a receiving destination.
The \MH/ \pgm{burst} command can be applied recursively for this purpose
because \MH/ encapsulation uses an unambiguous scheme to delimit messages
that are enclosed inside other messages.
Thus,
it should be possible to extract a structured set of records from a DBMS
and mail the set to a foreign site for processing, or reinsertion into
another DBMS.
As long as the DBMS data element definitions
correctly correspond to the RFC822 definitions,
it is not even necessary
for the source and destination DBMS systems to be the same.

From this discussion,
it is concluded that the \MH/ framework can be useful
for building distributed record handling systems where people at widely
scattered locations must create and submit record forms for processing
at distant locations.
This might prove to be especially effective when
a mail system is also needed for other communication purposes.
A network of sales offices is a good example,
where general message service would be used for communications
with remote manufacturing and distribution centers,
and could also be used for an order entry system.

Another example might be for structured communications, as occur in
requisition and purchasing systems.
Requisitions could be filled in and mailed to approval offices,
and resent or forwarded to others for action.
At some point,
the requisitions could flow into other other more suitable
processing systems as needed.
At the very least, the ability to originate
requisitions can be distributed to anyone with access to a mail system
that can originate a proper requisition form.

As a last example,
\MH/ already supports group discussions with its BBoard facilities
which allow for automatic sorting of mail by group address,
with shared private or public group access to contributed items.
As has been shown to be possible with administrative record systems,
there is no obvious limit to the ways that group discussion traffic
might be organized into structured collections with indices,
annotations, or reference pointers
to aid in making conference archives more useful.
Indeed, \MH/ tools could even be used to feed discussion items into
existing conference systems.

\section{Distributed Mail}			% mtr
Next, we consider how \MH/ might be used in a distributed mail environment.
Two schemes are discussed:
one in which connectivity is high and connections are relatively ``cheap'',
and one in which connectivity is low and connections are ``expensive''.

\subsection{The ARPA Internet Environs}		% mtr
The ARPA Internet community consists of many types of heterogeneous nodes.
Some hosts are large mainframe computers,
others are personal workstations.
All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}.
Messages which conform to the Standard for the Format of ARPA Internet Text
Messages\cite{DCroc82}
are exchanged using the Simple Mail Transfer Protocol\cite{SMTP}.

On smaller nodes in the ARPA Internet it is often impractical to maintain
a message transport agent.
For example,
a workstation may not have sufficient resources (cycles, disk space)
in order to permit an SMTP server and associated local mail delivery system
to be kept resident and continuously running.
Furthermore,
the workstation could be off-net for extended periods of time.
Similarly,
it may be expensive (or impossible) to keep a personal computer
interconnected to an IP-style network for long periods of time.
In other words,
the node is lacking the resource known as ``connectivity''.

Despite this,
it is often desirable to be able to process mail with \MH/ on these smaller
nodes,
and they often support a user agent to aid the tasks of mail handling.
To solve this problem,
a network node which can support a message transport entity
(known as {\it service} host) offers
a maildrop service to these less endowed nodes
(known as {\it client} hosts).
The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a
workstation to dynamically access a maildrop on a service host to pick-up
mail.%
\nfootnote{Actually,
there are three different descriptions of the POP.
The first, cited in \cite{JReyn84},
was the original description of the protocol,
which suffered from certain problems.
Since then,
two alternate descriptions have been developed.
The official revision of the POP\cite{MButl85},
and the revision of the POP which \MH/ uses
(which is documented in an internal memorandum in the \MH/ release).
This paper considers the POP in the context of the \MH/ release.}
The level of access includes the ability to
determine the number of messages in the maildrop and the size of each message,
as well as to retrieve and delete individual messages.
More sophisticated implementations of the POP server
are able to distinguish between the header and body portion of each message,
and send $n$ lines of a message to the POP client.
This capability is useful in thinly connected environments where conservation
of bandwidth is important.
By utilizing a more intelligent POP client,
a user may generate ``scan~listings'' and dynamically decide which messages
are worth taking delivery on.
The philosophy of the POP is to put intelligence in the
POP clients and not the POP servers.

The underlying paradigm in which the POP functions is that of a
split-slot/remote-\UA/ model.
The client host (such as a workstation) is without a co-resident
{\it message transport agent} (\MTA/),
and thus makes use of a service host with an \MTA/ to obtain posting (SMTP)
and delivery (POP) services.
The entity which supports this type of environment is called a remote-\UA/
since the user agent resides on a different host than its associated message
transport agent.

One very important issue which must be raised at this point is one of
authentication.
The POP requires that a client identify itself to the server using a
server-specific user-id and a server/user-specific password.
This authentication is required to prevent unauthorized entities from
accessing a maildrop on a POP service host.
It must be emphasized that the POP client is not a ``trusted'' entity of the
\MTS/ in any sense at all.

Ideally,
one would also like to authenticate mail as it is posted on the POP service
host using the SMTP.
Currently,
in the ARPA Internet community,
no authentication is done with SMTP transactions.
This is considered a shortcoming by those interested in researching the
split-\UA/ model of distributed mail.
The MZnet environment,
discussed in the next section,
has authentication facilities for posting mail.

The current release of \MH/ supports the above model fully:
a POP client program is available to retrieve a maildrop on a POP service
host.
In addition,
using the SMTP configuration for delivery in \MH/,
a user is able to specify a search-list of service hosts (and networks)
with which to try to post mail.
Using this search-list,
when an \MH/ user posts a draft,
the \pgm{post} program will attempt to establish an SMTP connection
with each host in the list to post the message until it succeeds.
Initial experimentation with the split-\UA/
in a local network environment has proved quite successful.

\subsection{The MZnet Environs}			% jns
In 1983,
the MZnet project\cite{EStef84} at the University of California, Irvine
set out to study the problems involved with bringing
Internet-class mail handling facilities to personal computers.
The project used Apple~II computers running the CP/M 2.2 operating system.
Programming was done in a subset of the C language called BDS C.
The transport system was based on the \MMDF/ PhoneNet software,
and implemented a {\it split-slot} arrangement between a personal computer
and a larger,
centralized mail distribution system that performed user
authentication and provided a relatively secure mail transfer channel.
The user agent, CP/MH, was based on \MH/.

A conclusion of the experiment was that small personal computer systems
with dial-up phone connections constrain user agent systems design in
ways that require use of a {\it split-slot} interface between the \UA/
and its supporting \MTA/, and that this interface
best provides the required services if it has error controlled command
and data transfer facilities, with interactive behavior. 
Another conclusion indicated that a good design for a user agent in such
a small personal computer
environment could be based on a very modular architecture,
such as \MH/.
A final conclusion was that session-level authentication of the client \UA/
is required for both posting and delivery.

It should be noted that the MZnet project had a profound influence on the
development of the POP used by \MH/.
A somewhat more detailed discussion of the relations between the two
environments can be found in the POP description contained
in the \MH/ release.

\section{A Final Note}				% jns
With the fifth major release of the \MH/ system,
it has become clear that most major increases in functionality can come
only at the expense of either efficiency or portability.
Although there has been great effort to keep \MH/ portable to a number of
\unix/ implementations,%
\nfootnote{As of this writing,
there are approximately 75~sites running \mh5
on five different implementations of \unix/.}
the divergence in process management facilities,
file system enhancements,
and even C~compiler capabilities
has already presented obstacles to some attempts to rehost the \MH/ code.

There has been some discussion of implementing specialized \MH/ daemons
that maintain context information over one or more sessions,
thus decreasing the amount of overhead involved in starting each \MH/ command.
Unfortunately,
even if such daemons were to be implemented,
they would be very difficult to move to versions of \unix/
without sophisticated process management facilities,
and even then the differences in ``philosophies''
of process management\cite{WJoy83,EOlse84}
would tend to keep such daemons system specific.
A better solution seems to be simply to tune existing code.

\section{Acknowledgements}
The authors would like to thank Norman Z.~Shapiro and
Phyllis Kantar of the Rand Corporation for their invaluable comments during
the preparation of this paper.

\section{Distribution Information}
For information concerning distribution mechanics for the current release of
\MH/, please contact:
$$\displayindent=\leftskip	\advance\displayindent by1.5\parindent
    \halign{\leftline{#}\cr
	Support Group\cr
	Attn: MH Distribution\cr
	Department of Information and Computer Science\cr
	University of California, Irvine\cr
	Irvine, CA  92717\qquad USA\cr
	\cr
	714/856--6852\cr
}$$