.\" ***************************************************
.\"  indra.me   - Steve Kille - Jan 84
.\"
.\"  /vax2/staff/steve/doc/indra/in.me
.\"
.\"     based on
.\"
.\"  tmac.pl.in  -  internal/departmental-specific macros
.\"
.\" ***************************************************
.\"
.\"
.\"
.\"       INTERNAL NOTE HEADER
.\"
.\"       called as .IN "Internal Note number" "date" "other id"
.\"
.de IN
.ec
.ls 1P          \" will be reset at top of next page to \n(LS
.sp 4
.in +5
.tl ~Internal Note \\$1~~Internal~
.ie \\w~\\$3~ .tl ~\\$3~~Working \&~
.el .tl ~~~Working \&~
.ie \\w~\\$3~ \\{  .tl ~~~Paper   \&~
.                   tl ~\\$2~~~     \\}
.el .tl ~\\$2~~Paper   \&~
..
.\"
.\" ***************************************************
.\"
.\"       TECHNICAL REPORT HEADER
.\"       called as .TR "Technical Report number" "date" "other id"
.\"
.de TR
.ec
.ls 1P          \" will be reset at top of next page to \n(LS
.sp 4
.tl ~TECHNICAL REPORT \\$1~~UCL-CS TR \\$1    \&~
.ie \\w~\\$3~ .tl ~\\$3~~~
.el .tl ~~~~
.ie \\w~\\$3~ \\{  .tl ~~~~
.                   tl ~\\$2~~~     \\}
.el .tl ~\\$2~~~
..
.\"
.\" ***************************************************
.\"
.\"       TITLE & AUTHOR(S)
.\"
.\"       called as .TA "title" "subtitle" "author(s)" "co-author(s)"
.\"
.de TA
.sp |3i
.rb
.tl ~~\\$1~~
.if \\w~\\$2~ \\{\
.       sp
.       tl ~~\\$2~~   \\}
.sp 3
.tl ~~\\$3~~
.sp
.if \\w~\\$4~ .tl ~~\\$4~~
.r
..
.\"
.\" ***************************************************
.\"
.\"       ABSTRACT START
.\"
.de AB
.sp |5..5i
.ds AS ABSTRACT:
.ll -(\\w~\\*(AS~u-1m)
.in +(\\w~\\*(AS~u+4m)
.ti -(\\w~\\*(AS~u+1m)
\\*(AS \\c
..
.\"
.\" ***************************************************
.\"
.\"       ABSTRACT END
.\"
.de AE
.wh -6 UC
.in
.ls
.ll
.bp 1
..
.\"
.\" ***************************************************
.\"
.\"       UCL LOGO
.\"
.de UC
.tl ~~Department of Computer Science~~
.sp
.tl ~~University College London \&~~
.wh -6
..
.IN 1726 "April 1985"
.TA "AUTHORISATION  AND  ACCOUNTING"  \
IN \
"STORE  AND  FORWARD  MESSAGE  HANDLING  SYSTEMS" \
"D.H. Brink and S.E. Kille"
.he  '[Authorisation]''[Indra Note 1726]'
.fo  '[Kille/Brink]''[Page %]'
.AB
Paper to be presented in June at Networks 85, Wembley.
.AE
.rb
.ce 6
AUTHORISATION  AND  ACCOUNTING
IN
STORE  AND  FORWARD  MESSAGE  HANDLING  SYSTEMS


D.H. Brink and S.E. Kille
Department of Computer Science
University College London
.r
.sp 2
Most existing store and forward message handling systems have either ignored
accounting and authorisation problems, or have
treated them in a simple manner.  The widespread adoption of the
CCITT X.400 protocols is likely to introduce relayed services provided
by multiple vendors.
These services will, by their nature,
require sophisticated authorisation and accounting.
This paper develops a model for applying such controls,
and describes experience with an experimental service
implemented on the basis of this model.
Finally, the general utility of this model is considered.
.sp 2
.in +4c
Denis Brink is a research assistant at University College London,
Department of Computer Science.  He has a BA in Philosophy and
MSc in Computer Science from University College London.  He
is currently working on the interconnection service project,
and has worked in industry on microcomputer operating systems.
.sp 3
Steve Kille received a BA in Physics from  Oxford  in  1978,  and
MScs  in  Electrical  Engineering  from UMIST (1980) and Stanford
(1981).  He has been a Research Assistant in the department of Computer
Science,  at University College London since 1981, where he has
worked on various aspects of Message Handling Systems.
His current research work is on Directory Services.
.in -4c
.bp
.sh 1 Introduction
.lp
Most existing store and forward message handling systems have either ignored
accounting and authorisation problems, or have
treated them in a simple manner.  The widespread adoption of the
CCITT X.400 protocols is likely to lead to the introduction of
relayed services provided
by multiple vendors (or management domains in X.400 terms) \*([.CCITT84a\*(.].
These services will, by their nature,
require sophisticated authorisation and accounting.
The first
part of this paper develops a model of the controls which
might be applied to such services.
.pp
The second part of the paper considers an
implementation of such controls.
University College London provides a number of message relaying
services between the UK and the USA for registered groups of
users.  A system has been developed to prevent unauthorised
usage, and to provide accounting and statistics for authorised usage.
The structure of the database
system used to generate control and accounting
information, and the internal message system organisation used
to apply these controls are described.
Experience with the use of this system and pragmatic
difficulties of its application are discussed.
Finally, the application of such services in a wider context
are considered.
.sh 1 "A Model of Authorisation"
.lp
The message services under consideration are assumed to be
provided by systems which can be described in terms of the
CCITT X.400 model of store and forward Message Handling
Systems (MHS).
.sp 7c
.ce
Figure 1: X.400 functional model of MHS
.sp
The X.400 model assumes two layers.  The lower layer is the Message
Transfer Layer, and is provided by
.rb "Message Transfer Agents"
(MTA),
which transfer messages in a store and forward manner.
That is to say, a message may be transferred over a sequence of
MTAs, and be queued at each one.
The upper layer is the Inter Personal Messaging layer,
which is provided by
.rb "User Agents"
(UA).
A UA should be considered as the software with which a user
interacts to compose or to read electronic messages.
Communication between UAs is end to end, but there will be no
OSI connection between a pair of UAs.
Rather, the store and forward service of the MTA layer is
used to provide an asynchronous end to end connection.
A UA is specified by a (globally unique) Originator/Recipient
Name, or
.rb "O/R name" .
There are O/R names at both the UA and MTA level.
The MTA level O/R names (P1 level in X.400) are
analogous to the names on an envelope in paper based mail.
The UA level O/R names (P2 level in X.400) are analogous to the
names in a contained letter.  They are
often, but not necessarily, the same.  The
transfer of a message consists of a number of distinct stages:
.np
A user composes a message and addresses it to a (UA level)
recipient.
.np
The message is transferred to an MTA, together with the MTA level recipient
O/R name.
The MTA will ensure that a valid MTA level originator O/R name is specified.
.np
The message is routed through a sequence of MTAs on the basis of
the MTA level recipient O/R name.
.np
The message is delivered to the recipient's UA.
.np
The recipient reads the message, which is usually interpreted in terms
of UA level O/R names.
.pp
A final concept, which is of relevance here, is that of
.rb "Management Domain" .
A Management Domain is an organisation providing MTA, and
(optionally) UA services.  This is illustrated in figure 1.
A Management Domain does not necessarily supply the
underlying OSI connection services.
.pp
The model proposed here operates on the assumption that MTAs
can in general be trusted, whereas UAs cannot.
Thus all control is at the MTA level.
This has the added advantage that if the
MTA layer is used for traffic other than inter-personal
messages, then the control mechanisms still work correctly.
Controls are now considered, as applied by an individual MTA.
An MTA is assumed to be trusted in two ways:
.np
When accepting a message from a UA, the MTA level originator
O/R  name is specified correctly by the MTA.
.np
When a message is transferred between Management Domains, this
is indicated accurately (i.e. a specification of the Management
Domain being left) in the MTA level  trace information\**.
.(f
\n($f. In X.400, trace information is on the basis of transfer between
Management Domains.  In other systems, MTA level trace is on
the basis of transfer between MTAs, and so what is considered as Management
Domain accounting here, may be MTA accounting in other systems.
.)f
.lp
This allows an MTA to determine responsibility for a given
transfer, and implicitly an authority to bill, on the basis of
two classes of item:
.np
One or more management domains.
Trace information will allow the MTA to determine the sequence
of Management Domains which have been traversed.
A recipient O/R name can determine at least the next Management
Domain, by use of a directory service.
.np
Originator and recipient O/R names.
.lp
It is assumed that the MTA has information allowing certain
forms of access on the basis of these parameters.
The set of parameters determining the authority for the MTA to
process the message is used to determine a
.rb "billing authority" \**.
.(f
\n($f. The term billing authority is used, but this does not
necessarily imply any form of bill.
In practice, the question: "who would pay for this if there was
a charge" is useful to determine responsibility.
.)f
Examples:
.ip -
All traffic from Management Domain X to Management Domain Y is
transferred, and billed to Management Domain X.
.ip -
All traffic from user "Zoe Foobar" may be transferred to
Management Domain "Betta Message Services Inc",
and billed to the organisation "Widget Manufacturing,
Plc".
.pp
As well as determining whether or not a message is authorised
to be
processed by the MTA, the billing authority for a given
message allows Quality of Service Parameters and appropriate
costs to be determined.
Some Quality of Service Parameters of interest are:
.np
Route choice, where message can be sent by more that one route.
This may be an MTA level route, or choice of OSI connection to
the next MTA.
.np
When to send message.  For example, a message transfer may be
timed to
take advantage of the tariff structure of the OSI services.
.np
Selection of OSI connection Quality of Service (e.g. use of
encryption).
.pp
The basis for identification of billing authority is now
considered in more detail.
A common policy will be an agreement between the local Management
Domain and an adjacent Management Domain.
This agreement might be to relay all traffic to a set of other Management
Domains, and to deliver to UAs in (and/or serviced by) the
local Management Domain.
This might or might not be restricted to traffic originating in
the adjacent Management Domain (which can be distinguished from
relayed traffic by the
trace information).
There might also be an agreement with a Management Domain
connected to through an intermediate Management Domain.
It is likely that this intermediate Management Domain will be
explicit, as:
.ip -
The intermediate Management Domain is likely to be party to the
agreement, at least implicitly.
.ip -
Use of a different intermediate Management Domains might cause undesired bills
.ip -
It makes message forgery harder.
.lp
O/R names may be authorised to send and/or receive over a set
of Management Domains.
Again, for the same reasons, O/R names are likely to be
authorised in the context of an explicit route of Management
Domains.
This type of authorisation should be regarded as the
authorisation of individual users to use the services of the
MTA in question.
.lp
The approach described here has the following weaknesses.
.np
It relies on MTA security not being breached.
This seems reasonable, as an MTA will not in general be trusted
unless real guarantees are given (e.g. by the payment of
bills).
.np
It relies on the integrity of the OSI connection used to verify
the identity of a remote MTA.
In principle, this can be made as secure as desired.
.lp
In practice, some low level of forgery is acceptable, provided
accounting and policing techniques allow for higher levels of
abuse to be detected and traced.
Some real experiences with this model are now considered.
.sh 1 "UCL Experience"
.lp
The networking environment of the department of Computer
Science at University College London,
and its control and accounting requirements are now
described.  This is followed by overviews of the
mail system, the database system, and their interaction for
accounting and control.  Problems encountered and weaknesses
of the system are identified.
.br
.ne 7c
.sp 6c
.ce

Figure 2: UCL Connectivity
.pp
The department offers an Interconnection Service\*([.Kirstein85a\*(.]
to allow UK (and some continental European) university and research
institution workers to communicate with their US
counterparts.  The requirement for such a service arises from the
diverse protocol systems used by the interconnected networks \*([.Cole84a\*(.].
.pp
The department has connections to the UK X.25 networks PSS and
JANET, and the DARPA Internet.  PSS (Packet Switched Service) is
British Telecom's national
public X.25 network, with gateways to the international X.25
service.
JANET (Joint Academic NETwork) is the private X.25 network
of the Science and Engineering Research Council and the Computer
Board, linking universities and scientific research
establishments. The higher level protocols used by the academic
community on these X.25
networks in the UK are the "coloured book protocols" serving as an
"intercept" standard pending the introduction of suitable ISO standards \*([.Rosner82a\*(.].
Mail services on Janet are provided by use of the JNT Mail Protocol
(also known as Greybook) \*([.Kille84a\*(.].
This specifies both an MTA level protocol and a UA level
protocol.
.pp
The DARPA (U.S. Defense Advanced Research Projects Agency)
Internet is a concatenation of networks linked by
gateways.
The department's local area network can be treated as
one such network.
These networks
use a common set of internet protocols based on
datagrams \*([.Leiner85a\*(.].
The MTA level protocol is SMTP (Simple Mail Transfer Protocol) \*([.Postel82a\*(.],
and the UA level protocol is a format specification known as RFC 822 \*([.Crocker82a\*(.].
The JNT Mail Protocol UA level is derived from RFC 822, and is
identical in all the major aspects.
Interworking is thus straightforward.
The DARPA protocols are also used to access CSNET (the US
Computer Science Network).
UCL is also connected to a UNIX\**
.(f
\n($f. UNIX is a trademark of AT&T Bell Laboratories.
.)f
dialup telephone network,
Usenet,
which again uses RFC 822 derived protocols \*([.Nowitz78a\*(.].
.pp
The department's local area network consists of three Cambridge rings
interconnected by bridges, and also an Ethernet.
Associated with each wide area network
are one or more network access machines.
Application processes access the network access machines by use
of a special Host to Front-end protocol, which allows for
working over multiple networks in a clean manner.
Current service applications are Terminal Access, File Transfer
and Mail.
.\"Remote users have terminal access
.\"to a host dedicated to providing interconnection services.  Mail
.\"systems run on all the hosts.
.\".pp
.\"Connectivity mail nets -- numbers direct/indirect
.pp
Use of the service is circumscribed by
the policies of the funding bodies, and by the
Value Added Carrier Licence from the UK Department of Trade.  These
restrictions are complex, specifying permitted
national/international relaying and permitted message path, in
terms of billing authority.  Coupled with
the extensive connectivity and high connection
costs, the above restrictions
necessitate effective control and accounting measures.
Users are grouped according to sponsorship, charging
policy and access rights.  In practice this broadly divides users
into a centrally-funded class, with access rights
determined by sponsor, and a directly-funded class with
corresponding access rights.
.pp
The Message Transfer service is provided by MMDF (Multi
Channel Memo Distribution Facility) \*([.Kingston84a,\|Kille85a\*(.].
MMDF is a Message Handling System
for the UNIX
operating system, having support for multiple message transfer
protocols, and a selection of UA systems.  MMDF
provides the user with a homogeneous view of the underlying connectivity.
The MMDF MTA is implemented by a number of processes and queues.
The process
.rb submit
is invoked to accept messages submitted
both by local UA processes and by servers handling incoming
messages.
All authorisation controls are applied by submit at message
submission time.
There are a number of
.rb channels
to associate protocols, networks or logical divisions.
Associated with each channel is a queue into which submit
places incoming messages.
The process
.rb deliver
reads and manages the queues associated with one or more channels
and invokes subordinate channel processes to
perform message transmission.
.pp
Channels are used as a mechanism for logically dividing hosts
into sets for the application of management controls.  There
are three orthogonal mechanisms for doing this:
.np
Splitting a set of hosts into more than one channel.  For example, PSS and
Janet hosts are on separate channels as the former network charges
for services, and
the latter is free, though technically they could be on
the same channel as the same protocols may be used.
.np
Allocating a set of hosts to more than one channel for
route or Quality of Service selection.
For example, there are two paths between UCL and the rest of the DARPA
Internet, for use by different users, and with
different polling frequencies.
.np
Separating inbound and outbound channels, when the policies are
asymmetric (e.g. where a user can receive messages from a given
channel, but not send messages over it).
.pp
It is noted that a message can be considered both to arrive and
to depart
over a channel.
A message arrives over a fixed
.rb "inbound channel" ,
but may leave over one of a set of
.rb "outbound channels" ,
as the requested destination may well be accessible over more
than one channel.
Submit considers each possible outbound channel in turn, and queues the
message for the first (if any) channel satisfying
authorisation criteria.  Access policies for each channel are
implemented in terms of two basic sets of controls.  The
following channel access policies are identified; they may
differ for inbound and outbound directions.
.np
FREE:   No controls.
.np
LOG:    Note unauthorised access.
.ne 4
.np
WARN:   As for LOG, but send warning to sender of message.  This is
particularly useful for transition from a free to a controlled
situation.
.np
BLOCK:  Only authorised access to the channel.
.pp
The first set of controls is applied on the basis of user (O/R name).
There is a (hash encoded) database of O/R names, giving a mode and a list of
authorised channel.
The following O/R name modes are identified.
.np
SEND:   O/R name only valid as originator.
.np
RECV:   O/R name only valid as recipient.
.np
BOTH:   O/R name valid as both sender and recipient.
.np
LIST:   special control for distribution lists expanded as a
value added service.
.lp
When a message is being authorised by submit, the originator and
recipient O/R names are looked up, and a set of valid inbound and
outbound channels identified for each.
This information is used
.np
To determine whether there is authorisation for the inbound channel.
.np
To identify which (if any) of the potential outbound channels
are acceptable.
.lp
The priority on the matches are: 1) the first possible outbound
channel; 2) recipient with list authorisation; 3) sender; 4)
recipient.
.pp
The second set of controls is applied on the basis of just the
MTAs and channels involved.  These controls are
applied by table lookup in four tables associated with each
channel.  Two tables are for inbound and two for outbound control.
As well as MTA and channel, there is the concept of MTA route,
to identify a sequence of MTAs, with the message having
originated at the first MTA in the sequence or (ostensibly) be destined
for a user at the last MTA in the sequence.
An important special case is that of messages originating on,
or destined for an adjacent MTA.
The following may be controlled:
.ip -
Inbound channel to everywhere, or to a set of MTAs and outbound
channels.
.ip -
Outbound channel from everywhere, or from a set of MTAs and inbound
channels.
.ip -
Inbound MTA to everywhere, or to a set of MTAs and outbound
channels.
.ip -
Outbound MTA from everywhere, or from a set of MTAs and inbound
channels.
.ip -
Inbound MTA route to everywhere, or to a set of MTAs and outbound
channels.
.ip -
Outbound MTA route from everywhere, or from a set of MTAs and inbound
channels.
.lp
These MTA/channel controls are applied before the user controls and in
general are considered to override them.  They may also be
applied in addition to the user controls, to
apply policy controls
on top of essentially O/R name based controls.
This mechanism might be used to prevent third  country
relaying, in cases where both originator and recipient are
authorised in other contexts.
.pp
The following checks and actions are performed by MMDF, to
prevent forgery.
.np
Only privileged processes can access the message queues.
.np
Locally originated messages have correct UA level originator O/R name.
.np
Locally originated messages have correct MTA level originator O/R name.
This is the O/R name used for authorisation.
.np
When a message is received, the name of the connecting MTA is
added to the source route associated with the originator O/R
name.
O/R names must have an authorised route, to minimise the risk
of forgery.
.pp
The Interconnection Service Management
System (ISMS) used to provide high level access
to and control of the above mechanisms is now discussed.
ISMS is based on Mistress, a proprietary relational database package \*([.Rhodnius82a\*(.].
The basic model of operation is that high level administrative
information is contained in the ISMS.
This information is used to derive control information for
MMDF, in the form of plain text files to be incorporated into
the hash encoded database used by MMDF.
When a message transfer is authorised or rejected by MMDF, this
is noted in a log, together with: originator O/R name;
recipient O/R name; inbound channel; outbound channel; any MTA
route involved; the size of the message; and
reason for authorisation
for both the inbound and outbound channel.
The MTAs directly involved are implicit in the O/R names.
Example reasons for authorisation:
.ip -
Inbound by originator + no authorisation required outbound.
.ip -
Inbound by recipient + outbound by recipient.
.ip -
Inbound MTA to outbound channel pair.
.lp
These logs are then processed at intervals by the ISMS
(typically once per
day),
and stored in terms of the administrative information in the ISMS.
This information can then be used to generate bills, and
usage statistics.
The following are the main relations in the database.
.ip -
Class of user. This gives the set of channels to which access
is permitted.  Most users fall into one of a very small number
of classes.
.ip -
Project.  A project authorised to use the Interconnection
Service.  This contains funding information, and indicates the
class.
Also various management O/R names.  These can be used for
automatic mailing of accounting, statistical, and other project
information.
.ip -
Mailbox.  Indicates an O/R name in terms of project.
.ip -
Message.  Indicates a transfer, and may be associated with one
or two mailboxes for authorisation.
.ip -
Channel.  Indicates charging policy in terms of class of user.
.pp
To prevent administrative overload,
each project is given an account at UCL allowing project
administrators to remotely update UA registrations by use
of a simple program.  This two level scheme,
means that the UCL administration deals
with projects and not individual users.
.pp
This scheme was brought into operation in February 1985, and
has clearly demonstrated the viability of the proposed model.
There are currently about 150 projects and 2000 UAs
registered.
The system handles about 1000 messages per day.
Perhaps the hardest aspect to deal with was the
transition from an uncontrolled situation, where messages were
relayed without checking (even though they should have been
authorised in principle).
A significant number of project applications were processed
over this period.
The following problems were noted:
.ip -
Accurate naming is essential.  MTA tables (on all MTAs
involved) must be kept
consistent for this scheme to work effectively.
.ip -
Certain MTA protocol requirements are made.  A few implementations
which violated message protocols
for other obscure reasons had problems registering O/R names.
.ip -
Strict matching of the source route for incoming messages means
that a few sites have to register multiple routes for each
O/R name.  This is due to both variable internal routing at these
sites, and non-symmetrical routing for incoming and outgoing
directions.  This is seen as an unfortunate consequence of a
control necessary to minimise forgery.
.ip -
If a message is routed over an insecure OSI connection, or
through an insecure MTA, there is clearly a risk of forgery.
This risk must be borne by the project registering such a
route.
.bp
.ip -
Submission time checking means that messages which are not
correctly delivered are still charged for.
This is undesirable, but removes the (non-trivial) problem of
correlating submission and delivery logs.
It does not appear to be a substantial problem in practice.
.ip -
If a message transfer is optimised by transferring one copy of
the message for multiple recipients, the saving is not passed
on to the user.
This seems reasonable, on the grounds that the user should be
charged for services in a uniform manner.
.sh 1 Conclusions
.lp
The model developed here is not a general one;
A broader description of the theoretical issues may be found in \*([.Kille85b\*(.].
However, we believe that our work has shown the viability of a
scheme where messages are authorised, with no requirements
placed on the remote systems other than accurate and
trustworthy protocol implementation.
Our logs have not, as yet, shown any successful attempts to
break the security.
In fact the problems of correctly registering authorised users,
partly due to the stringency of the checks,
have been far more of a problem.
.pp
The major advantage of the approach described is that it allows for MTA
level accounting,  with minimal assistance from other system
components.
It is seen as has having two basic styles of application.
The first is where a Management Domain (or pair of Management
Domains) offer communication over an expensive link
(or some service such as message format conversion).
This approach would enable billing of users and/or Management
Domains for the use of this service.
The UCL implementation is of this type.
A second area where is might be useful is as a gateway to a
Management Domain providing services for one organisation.
This approach would allow the organisation to control its
employees' access to Message Handling Services, much as
telephone systems are sometimes controlled at present.
This type of approach is seen a particularly important as
controls are introduced into systems without overall control in
this area.
.sp
.]<
.\"1982-1
.ds [F Rhodnius82a
.]-
.ds [T Mistress: Relational Database Management System Version 2.1
.ds [Q Rhodnius Incorporated
.ds [R Manual
.ds [D 1982
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"1984-2
.ds [F CCITT84a
.]-
.ds [Q CCITT SG 5/VII
.ds [T Recommendations X.400
.ds [D November 1984
.ds [R Message Handling Systems: System Model - Service Elements
.ds [K x400
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Cole.R.H.-1984-3
.ds [F Cole84a
.]-
.ds [A R.H. Cole
.as [A " and others
.ds [T Network Interconnection Facilities at UCL
.ds [D September 1984
.ds [J ICCC, Melbourne
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Crocker.D.H.-1982-4
.ds [F Crocker82a
.]-
.ds [A D.H. Crocker
.ds [T Standard of the Format of ARPA Internet Text Messages
.ds [D August 1982
.ds [R RFC 822
.ds [K RFC822
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Kille.S.E.-1984-5
.ds [F Kille84a
.]-
.ds [A S.E. Kille, (editor)
.ds [T JNT Mail Protocol (revision 1.0)
.ds [D March 1984
.ds [I Joint Network Team
.ds [C Rutherford Appleton Laboratory
.ds [K greybook
.ds [K jntmail
.nr [T 0
.nr [A 0
.nr [O 0
.][ 2 book
.\"Kille.S.E.-1985-6
.ds [F Kille85a
.]-
.ds [T Addressing in MMDF II
.ds [A S.E. Kille
.ds [J Proc. EUUG Conference, Paris
.ds [D April 1985
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Kille.S.E.-1985-7
.ds [F Kille85b
.]-
.ds [A S.E. Kille
.as [A " and D.H. Brink
.ds [T A Model of Message Flow Control
.ds [D Sepetmber 1985
.ds [J Submitted to IFIP WG 6.5 Congress, Washington
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Kingston.D.P.-1984-8
.ds [F Kingston84a
.]-
.ds [A D.P. Kingston
.ds [T MMDFII: A Technical Review
.ds [J Usenix Conference
.ds [C Salt Lake City
.ds [D August 1984
.ds [K MMDF
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Kirstein.P.T.-1985-9
.ds [F Kirstein85a
.]-
.ds [T The University College London International Computer Communications Interconnection Service
.ds [A P.T. Kirstein
.ds [J Conference on Communications in Distributed Systems, Karlsruhe
.ds [D March 1985
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Leiner.B.M.-1985-10
.ds [F Leiner85a
.]-
.ds [T The DARPA Internet Protocol Suite
.ds [A B.M. Leiner
.as [A ", R.H. Cole
.as [A ", J.B. Postel
.as [A ", and D. Mills
.ds [J Proceedings INFOCOM85
.ds [I IEEE
.ds [D March 1985
.ds [l own paper
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Nowitz.D.A.-1978-11
.ds [F Nowitz78a
.]-
.ds [A D.A. Nowitz
.as [A " and M.E. Lesk
.ds [T A Dial-up Network of UNIX systems
.ds [D August 1978
.ds [R UNIX Programmer's Manual, 7th edition, Bell Labs.
.ds [K UUCP
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Postel.J.B.-1982-12
.ds [F Postel82a
.]-
.ds [A J.B. Postel
.ds [T SIMPLE MAIL TRANSFER PROTOCOL
.ds [D August 1982
.ds [R RFC 821
.ds [K RFC821
.ds [K SMTP
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Rosner.R.A.-1982-13
.ds [F Rosner82a
.]-
.ds [T Towards OSI among UK Universities
.ds [A R.A. Rosner
.ds [J Proc. ICCC'82, London
.ds [I North-Holland
.ds [D September 1982
.ds [P 607-611
.nr [P 1
.ds [K OSI Universities
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.]>
.sp
.ip Note: 7
RFC indicates a DARPA Request For Comments, which may be
obtained from: USC Information Sciences Institute, Marina del
Rey, Ca. USA.
.sh 1 Acknowledgements
.lp
Thanks to Tom Daniel for helpful comments on the paper.
