Customized generic SPECS/build-nmh-cygwin for nmh.
[mmh] / docs / historical / mznet.txt
1
2
3
4
5   MZnet:   Mail  Service  for  Personal
6
7
8              Micro-Computer  Systems
9
10
11
12                                   Einar  Stefferud
13
14                                        President,
15
16                 Network  Management  Associates
17
18                                              and
19
20                                Visiting  Lecturer,
21
22             in  Information  and  Computer  Science
23
24                 University  of  California  at  Irvine
25
26
27
28                                      Jerry  Sweet
29
30 Department  of  Information  and  Computer  Science
31
32                 University  of  California  at  Irvine
33
34
35
36                                 Terrance  Domae
37
38                            School  of  Engineering
39
40           University  of  California  at  Los  Angeles
41
42
43
44                                                0
45 \f
46
47
48
49                                             Abstract
50
51      Traditional computer mail systems involve a co-resident User Agent
52 (UA)  and  Mail  Transfer  System  (MTS)  on  a  time-shared  host  com-
53 puter which may be connected to other hosts in a network, with new
54 mail  posted  or  delivered  directly  through  co-resident  mail-slot  pro-
55 grams.  To  introduce  personal  micro-computers  (PCs)  into  this  envi-
56 ronment requires modification of the traditional mail system architec-
57 ture.  To this end,  the MZnet project uses a split-slot model,  placing
58 UA programs on the PCs while leaving MTA programs on a mail relay
59 host  which  can  provide  authentication  and  buffering.   The  split-slot
60 arrangement might be viewed as a new protocol level which operates
61 somewhere between the currently defined MTS-MTS and UA-UA lev-
62 els.
63 \f
64
65
66
67 Introduction
68
69
70 Mail  systems  were  born  and  have  grown  up  on  large  central  time  sharing
71
72 systems, often imbedded in large networks of inter-operating computers with
73
74 a set of distributed processes automatically transferring mail between users.
75
76 This  is  certainly  the  case  with  the  U.S.  Department  of  Defense  (DoD)  Ad-
77
78 vanced  Research  Projects  Agency  Network  (ARPANET)  [1 ]  where  much  of
79
80 the  original  computer  network  mail  systems  research  and  development  has
81
82 taken  place.   Other  mail  networks  such  as  the  Computer  Science  Network
83
84 [2 ]  sponsored  by  the  U.S.  National  Science  Foundation,  have  also  used  rela-
85
86 tively large shared computers lodged in an institutional setting, though they
87
88 are often connected together with ordinary dial-up telephone links to form a
89
90 large geographic network.  Another U.S. example is USENET [3 ] which con-
91
92 nects  thousands  of  Unix1  systems  together  with  informally-supported  dial
93
94 telephone links.  Although there have been several attempts, there appear to
95
96 be  no  successful  mail  networks  based  on  small  personal  computers,  such  as
97
98 those that use the CP/M2  or MS-DOS3  operating systems.
99
100       The  accepted  architectural  model  (see  Figure  1)  for  computer  network
101
102 mail (first articulated by the IFIP 6.5 Systems Environment Working Group)
103
104 involves a User Agent (UA) which posts new mail items through a mail slot
105
106 [4 ,  5,  6,  7]  to  a  Mail  Transfer  Agent  (MTA)  which  delivers  posted  items  to
107
108 designated  UA  recipients  through  corresponding  delivery  slots.  When  mail
109
110 is  to  be  delivered  to  a  UA  on  another  host,  it  is  transferred  first  to  another
111
112 MTA on the recipient user's host, which in turn puts the mail item through
113
114 its  local  delivery  slot.   In  this  model,  a  Mail  Transfer  System  (MTS)  may
115
116 be viewed as a collection of MTAs with network connections among them to
117
118 provide  Mail  Transfer  Services  for  a  large  number  of  users  on  different  host
119
120 computers.
121
122       Replicating  this  UA/MTA/MTS  model  on  a  personal  micro-computer
123
124 (PC)  is  not  an  easy  task.  Aspects  of  PCs  that  make  support  of  this  model
125
126 difficult  include  limited  storage  capacities,  limited  processing  capabilities,
127
128 and the fact that PCs are geared to support a single user rather than several
129
130 users  at  once.   A  PC  with  limited  secondary  diskette  storage  and  limited
131 ________________________________________________
132     1 UNIX is a Trademark of Bell Laboratories, Inc.
133     2 CP/M is a Trademark of Digital Research, Inc.
134     3 MS-DOS is a Trademark of Microsoft Corporation.
135
136
137
138                                                            1
139 \f
140
141
142
143 processing capacity (often single-thread) is not well suited to support the full
144
145 range of automatic interactions between a UA and an MTA, or the necessary
146
147 interactions between MTAs in an MTS. For example, we do not see any way
148
149 to  certify  PC  systems  for  authentication  of  posted  mail.  A  PC  can  change
150
151 its  entire  character  and  behavior  with  insertion  of  a  new  program  diskette,
152
153 suggesting that it is the operating system diskettes and their users that must
154
155 be certified, rather than the computers.  Review of certification issues shows
156
157 that  it  is  not  the  computer,  but  its  operators  and  managers  that  must  be
158
159 certified,  and  this  involves  the  notions  of  central  management  and  control.
160
161 All  this  is  lost  in  the  maze  of  PCs  that  we  see  proliferating  on  and  off  our
162
163 campuses, in and out of our offices and homes.
164
165       Thus, we see a need for a new arrangement with the UA separated from
166
167 its  MTA,  and  using  communication  protocols  to  interact  with  it  in  ways
168
169 that resemble MTA-to-MTA interactions.  The UA is placed on the PC end,
170
171 while  the  more  complex  tasks  performed  by  the  MTA  are  relegated  to  the
172
173 remote host end.  The remote MTA must authenticate mail items offered by
174
175 the PC-based UA, just as it would for a co-located UA, but the task is more
176
177 difficult because the PC UA is potentially anyone among the public telephone
178
179 connectable  population.   This  can  be  handled  with  password  systems,  but
180
181 recognition and identification are not the only services to be provided at the
182
183 posting  slot.   Posting  also  requires  some  validation  of  recipient  addresses,
184
185 and validation of the syntax and semantics of certain header fields.  Example
186
187 standards are provided by the U.S. National Bureau of Standards (NBS) and
188
189 the U.S. DoD ARPANET for the format of mail to be transferred [8 , 9 , 10  ].
190
191       The new arrangement described in this paper might be called a split mail
192
193 slot in that the UA side of the slot is split away from the MTA side.  Although
194
195 the  UA  and  MTA  may  be  on  opposite  ends  of  a  telephone  connection,  they
196
197 must  still  act  together  as  a  single  processing  unit  to  move  mail  from  one
198
199 to  the  other,  with  all  that  this  may  entail.   This  gives  rise  to  a  number  of
200
201 new  MTA/UA  requirements  such  as  error  control  for  service  requests,  user
202
203 intervention to select items for delivery, and user postponement or rejection
204
205 of delivery without triggering failure notices to senders.  These are not serious
206
207 problems  when  both  MTA  and  UA  are  programs  running  on  a  single  host.
208
209 For example, with both UA and MTA on the same host, unwanted junk mail
210
211 is  simply  deleted  at  low  cost,  compared  to  the  cost  of  deletion  after  a  long
212
213 delivery transmission time.  Better that our PC users be able to discard items
214
215 without delivery transmission.
216
217
218
219                                                            2
220 \f
221
222
223
224 Overview  of  the  MZnet  Environment
225
226
227 The MZnet project is an undergraduate student effort sponsored within the
228
229 Information  and  Computer  Science  (ICS)  Department  of  the  University  of
230
231 California  at  Irvine  (UCI)  in  Southern  California.  For  the  past  2  years,  the
232
233 UCI mail network, known as ZOTnet, has been connected into the Computer
234
235 Science  Network  (CSnet)  and  in  1984,  has  joined  the  DoD  ARPA  Internet
236
237 with a Split-Gateway connection [11  ] to the University of Southern California
238
239 Information Sciences Institute (USC-ISI). The MZnet split-slot arrangement
240
241 may  have  some  similarities  to  the  Split-Slot  Internet  Gateway  at  least  in
242
243 name, but the problems and the implementations are quite different.
244
245       The UCI ZOTnet environment [13  ] gives the MZnet project a full-fledged
246
247 Internet-class mail system as its foundation.  The MZnet project objective is
248
249 to extend this class of mail service to personal computers located in student
250
251 and faculty residences, offices and laboratories, without waiting for full-blown
252
253 local area networking to first provide connections.  This follows a pattern of
254
255 making the most of existing facilities to provide a reasonable level of service.
256
257       The UCI ZOTnet uses the CSnet-provided MMDF (Multi-channel Memo
258
259 Distribution Facility) software [12  ] from the University of Delaware to inter-
260
261 connect two VAX 750 Unix systems with two DEC TOPS-20 systems through
262
263 a  port  selector,  with  dial  telephone  connection  to  a  CSnet  relay  [14  ].   The
264
265 ZOTnet has since evolved into an ethernet-connected local area network with
266
267 the aforementioned gateway connection into the DoD Internet.  The ZOTnet
268
269 also  connects  to  USENET  with  the  UUCP  protocols,  and  provides  format
270
271 transformations for mail flowing between protocol domains [15  , 16  ].  Adding
272
273 to the reach of the ZOTnet with MZnet is a natural part of its evolution4 .
274
275       To this point we have set the context of the MZnet project.  The remainder
276
277 of this paper is devoted to relatively technical discussions of implementation
278
279 of the PC user agent programs and the split-slot UA/MTA interface.
280 ________________________________________________
281     4 For  those  who  are  properly  curious  about  such  things,  the  name  "ZOTnet"  derives
282
283 from  the  cry  of  the  UCI  mascot  which  is  the  Anteater  from  the  B.C.  comic  strip,  and
284 MZnet is simply a contraction for Micro-ZOTnet.
285
286
287
288                                                            3
289 \f
290
291
292
293 The  MZnet  User  Agent:   CP/MH
294
295
296 CP/MH  is  a  collection  of  programs  designed  to  work  in  conjunction  with
297
298 the  Micro  ZOTnet  (MZnet)  as  an  extension  of  the  UCI  ZOTnet.   CP/MH
299
300 programs permit a user of a CP/M 2.2-based microcomputer to send and re-
301
302 ceive ZOTnet mail messages, as well as to manipulate them locally on floppy
303
304 disks.   The  CP/MH  programs  are  written  in  the  C  programming  language
305
306 and should be portable to similar operating environments, such as MS-DOS,
307
308 etc.
309
310       CP/MH  is  based  on  the  UCI  version  of  the  Rand  MH  message  handling
311
312 system  [17  ]  for  the  Unix  operating  system.   The  major  philosophical  dif-
313
314 ferences  between  CP/MH  and  typical  user  agents  such  as  MSG  [4 ]  and  its
315
316 descendants  are  those  of  modularity  and  of  user  interface.   In  CP/MH  (as
317
318 in  MH)  the  user  does  not  invoke  a  single  monolithic  program  to  deal  with
319
320 mail,  but  rather  invokes  individual,  non-interactive  programs  with  common
321
322 knowledge of the way messages are stored.  Each program has default behav-
323
324 ior which can be modified by using Unix-style command line options at time
325
326 of  invocation  or  through  a  user  profile.   Help  messages  can  also  be  evoked
327
328 from CP/MH programs.
329
330
331
332 Messages  and  Folders
333
334
335 The format of a CP/MH message adheres more or less to the syntax described
336
337 in  RFC  822  in  which  a  message  consists  of  headers  containing  information
338
339 pertaining  to  the  message  source  and  destination,  and  the  message  body,
340
341 separated  from  the  headers  by  a  blank  line.  An  example  of  such  a  message
342
343 might be:
344
345
346
347           Date:  02  Nov  83  23:04:53  PST  (Wed)
348
349           To:  Toto  <dog@Univ-Kansas>
350
351           From:  The  Great  And  Powerful  Oz  <Oz@Emerald-City>
352
353           Subject:  What  Be  Your  Excuse?
354
355
356
357           What's  the  matter?    I  ask  you  for  a  simple  thing  like
358
359           "distribute  this  to  Witch@Oz-West,"  and  you  can't  do  it.
360
361           You  undergrads  will  do  anything  to  get  out  of  work!
362
363
364
365                                                            4
366 \f
367
368
369
370           --ozzie
371
372
373       Following  the  MH  convention,  each  message  is  kept  in  a  separate  file.
374
375 Since  a  message  is  simply  ASCII  text,  it  can  be  operated  upon  by  non-
376
377 CP/MH programs (such as text editors, in particular).
378
379       Collections  of  messages  are  called  folders.   Under  CP/MH,  folders  are
380
381 represented by several files:  an info file, containing maintenance information
382
383 about  the  folder,  and  a  set  of  message  files  with  the  same  name  as  the  info
384
385 file,  but  with  unique  numeric  suffixes  (extensions  in  CP/M  parlance).   An
386
387 example of this naming scheme might be:
388
389
390 DRAFT       the info file for the DRAFT folder
391
392
393 DRAFT.001          message 1 in the folder
394
395
396 DRAFT.002          message 2 in the folder
397
398
399 DRAFT.003          message 3 in the folder
400
401
402       The number of messages that may be stored in a folder is limited primarily
403
404 by  the  storage  capacity  of  a  floppy  disk,  but  also  by  the  three-digit  limit  of
405
406 a CP/M extension.
407
408       The info file contains a field named CURRENT: specifying the current mes-
409
410 sage  number.   The  current  message  number  signifies  the  default  message
411
412 operated upon by CP/MH commands using a particular folder.  The current
413
414 message  number  may  be  modified  by  some  commands.   An  example  of  the
415
416 contents of the info file DRAFT might be
417
418
419              CURRENT:  3
420
421
422       This  indicates  that  the  file  DRAFT.003  would  be  operated  upon  when
423
424 default conditions apply (i.e.  when no message number is explicitly given to
425
426 a CP/MH command).
427
428       Possible future uses for the info file include named message sequences (a
429
430 set  of  messages  to  which  commands  may  be  applied  as  a  whole)  and  user
431
432 profile  information  for  application  to  particular  folders  (there  is  presently  a
433
434 single user profile, described shortly).
435
436       A  floppy  diskette  may  contain  more  than  one  folder,  but  folders  do  not
437
438 extend  over  more  than  one  floppy  diskette;  therefore  two  different  diskettes
439
440 may contain folders with the same name.
441
442
443
444                                                            5
445 \f
446
447
448
449 CP/MH  Commands
450
451
452 Commands  operating  on  messages  can  be  divided  into  several  general  cate-
453
454 gories:
455
456
457
458 Transporting:              sending, receiving
459
460
461 Viewing:          selecting for display, showing header summaries
462
463
464 Creating:          composing, replying, forwarding
465
466
467 Archiving:           categorizing, refiling, deleting, sorting
468
469
470
471       The architecture of CP/MH permits the simulation of some of these cat-
472
473 egories using standard CP/M commands when CP/MH, in its present prim-
474
475 itive state, does not cover them.
476
477       A minimal functionality is presently provided by the following four com-
478
479 mands:
480
481
482
483 COMP           composes  mail  items:  creates  a  file  containing  header  information
484
485          taken  from  a  standard  or  user-specified  template.  This  newly-created
486
487          file may be edited to fill in the header fields and body.
488
489
490 REPL         replies  to  mail  items:   creates  a  file  containing  header  information
491
492          appropriate  for  answering  a  given  mail  item.   This  newly-created  file
493
494          may be edited to change header fields and fill in the body.
495
496
497 SEND          sends mail items:  posts selected items through the split-slot from a
498
499          draft folder.
500
501
502 INC       receives  mail  items:  takes  delivery  of  selected  items  across  the  split-
503
504          slot, incorporating them into a mailbox folder.
505
506
507
508 These  commands,  with  a  few  enhancements  and  modifications  appropriate
509
510 to  the  CP/M  environment,  are  functionally  almost  identical  to  their  Unix
511
512 MH counterparts.
513
514       CP/MH commands are invoked like any other CP/M commands such as
515
516 ED,  PIP,  or  DIR.  Command  line  options  are  generally  preceded  by  a  dash
517
518 (e.g.  -editor  A:ED),  and  may  be  abbreviated.  Folder  names  are  preceded
519
520
521
522                                                            6
523 \f
524
525
526
527 by  a  plus  (e.g.   +B:DRAFT).  Messages  are  identified  by  numbers  or  by  the
528
529 special names first, last, current, next, and previous.
530
531       An example of use of a CP/MH command is:
532
533
534
535                         comp  -edit  a:ed  -use  last  +b:draft  -log
536
537
538
539       This  particular  example  will  edit  the  last-composed  message  (the  -use
540
541 last  option)  in  the  folder  DRAFT  on  disk  drive  B:  (the  +b:draft  option),
542
543 using  the  standard  CP/M  editor  ED  on  disk  drive  A:  (the  -edit  a:ed  op-
544
545 tion),  and  prompting  the  user  when  it  is  appropriate  to  change  disks  (the
546
547 -log option).
548
549       All  CP/MH  commands  have  a  -help  option  which  displays  all  available
550
551 options  for  the  particular  command  invoked.   Another  common  option  is
552
553 -log  which  permits  the  user  to  change  (relog)  diskettes  after  invoking  a
554
555 command,  for  purposes  of  selecting  diskettes  with  message  folders  or  with
556
557 editor  programs.   This  is  particularly  useful  on  single-drive  systems  or  on
558
559 systems with diskettes of low storage capacity.
560
561
562
563 The  Profile
564
565
566 If  there  are  options  commonly  used  with  a  particular  CP/MH  command,
567
568 they may be entered in the user profile contained in the file called (naturally
569
570 enough)  PROFILE,  which  must  exist  on  the  same  diskette  on  which  CP/MH
571
572 commands reside and from which the commands are invoked.  A profile entry
573
574 consists  of  a  program  name  followed  by  a  colon  and  the  options  to  be  used
575
576 with that program, for example:
577
578
579
580                         comp:    -editor  A:VEDIT  +B:outbox  -log
581
582                         repl:    -editor  A:VEDIT  -log
583
584                         send:    +B:outbox
585
586                         inc:    +B:inbox  -log
587
588
589
590       Individual profile components are overridden by options given at the time
591
592 of  invocation  (e.g.   -noedit  given  on  the  command  line  will  override  the
593
594 -editor profile component for a particular command).
595
596
597
598                                                            7
599 \f
600
601
602
603 The  MZnet  Split-Slot  Mail  Transfer  System
604
605
606 The MZnet split-slot software implements a peer-to-peer communication pro-
607
608 tocol  between  a  time-sharing  host's  MTA  and  a  personal  micro-computer
609
610 (PC) UA. This MZnet protocol extends the UA/MTA/UA model of computer-
611
612 based message systems (CBMS) to provide a split gateway function between
613
614 individual PCs and the ZOTnet similar to the UCI ICS split Internet gateway
615
616 described previously (see Figure 2).
617
618
619
620 The  Structure  of  the  Split-Slot
621
622
623 The  MZnet  Split  Gateway  consists  of  three  distributed  processing  compo-
624
625 nents:
626
627
628
629       -  A PC running a UA (in MZnet, CP/MH) acting as the mail server.
630
631
632       -  A  mini/mainframe  host  running  a  full  MTA  (MMDF  in  MZnet)  pro-
633
634          viding mail relay services.
635
636
637       -  A  communication  protocol  (a  modified  version  of  MMDF  PhoneNet)
638
639          to connect the two ends of the split-slot.
640
641
642
643 Although  this  combination  may  not  be  unique,  the  method  by  which  the
644
645 MZnet  split-slot  bonds  these  parts  together  uniquely  deals  with  the  prob-
646
647 lems  of  remote  user  agents.  In  addition  to  overcoming  limited  storage  and
648
649 processing capacities, remote user agents must deal with noisy modem lines,
650
651 mail  software  certification,  and  mail  system  security  problems.  The  MZnet
652
653 architecture  appears  to  solve  these  problems  with  a  clean  mail  interface  for
654
655 PCs.
656
657
658
659 The  MZnet  Mail  Server
660
661
662 The split-slot mail server consists of a set of command  packet programs run
663
664 from the PC. These programs simply present commands through the Phone-
665
666 Net  communication  protocol  to  the  mail  relay  slave  program  on  the  host.
667
668 Some basic commands are:
669
670
671
672 PostMail          posts mail drafts to MTA
673
674
675
676                                                            8
677 \f
678
679
680
681 GetMail          accepts mail from MTA
682
683
684 RemoteScan               displays information about waiting mail
685
686
687 Quit      drops connection between PC and Host
688
689
690
691       Each command has the form:
692
693
694
695              Command Request
696
697              Data Transmission
698
699              Command Termination
700
701
702
703       For example, the PostMail command is a small program that:
704
705
706
707       -  initiates a command with the Mail Slave by sending the command name
708
709          (PostMail) encoded within a PhoneNet packet;
710
711
712       -  sends a series of PhoneNet packets that contain pieces of the mail item
713
714          to be posted;
715
716
717       -  finally sends a command termination signal to end the transaction with-
718
719          out terminating the connection between host and PC.
720
721
722
723 The  MZnet  Channel  To  MMDF
724
725
726 The MZnet Channel runs on the MTA host under the University of Delaware's
727
728 MMDF  (Version  1)  and  is  responsible  for  both  delivery  of  received  mail  to
729
730 MZnet users, and posting of MZnet user-originated mail.  The MMDF MZnet
731
732 channel  maintains  a  unique  message  queue  for  each  registered  MZnet  user.
733
734 As new mail items arrive, they are posted to the appropriate queues, where
735
736 MZnet holds the mail items for pickup by their registered recipients.
737
738       To send or receive mail, the MZnet user must attach to the host, log into
739
740 the  public  MZnet  account,  and  identify  (authenticate)  himself.  During  the
741
742 MZnet  session  with  the  host,  the  user  has  access  only  to  that  restricted  set
743
744 of  functions  provided  by  the  MZnet  split  gateway  protocol:  he  may  request
745
746 delivery of queued mail with GetMail, or post new mail with PostMail.  Prior
747
748 to  taking  delivery  of  queued  mail,  a  survey  of  waiting  mail  also  may  be
749
750
751
752                                                            9
753 \f
754
755
756
757 requested with RemoteScan to obtain message size information (among other
758
759 data) to allow intelligent disposition of mail in the queue.
760
761       Hidden within these activities are issues of security and certification.  To
762
763 certify and establish the identity of the user, a second password is requested
764
765 after  logging  into  the  public  MZnet  account.   This  certification  procedure
766
767 allows  MZnet  to  certify  the  source  of  originated  mail.   A  relatively  secure
768
769 environment  is  provided  by  MZnet,  as  it  is  the  only  interface  to  the  host
770
771 permitted  to  MZnet  users  (once  beyond  the  public  login  procedure),  and  it
772
773 offers only the severely restricted set of PhoneNet-encoded commands.  Aside
774
775 from security issues, using a single account to handle all MZnet users reduces
776
777 demands on system resources.
778
779
780
781 The  MZnet-PhoneNet  Protocol
782
783
784 A unique facet of the MZnet system derives from the PhoneNet File Transfer
785
786 Protocol  (FTP).  PhoneNet  FTP  is  a  simple  error-checked  packet  protocol
787
788 which transfers ASCII plaintext.  PhoneNet encodes any non-plaintext char-
789
790 acter  (or  any  other  character  "forbidden"  by  the  idiosyncrasies  of  the  com-
791
792 municating  systems)  by  mapping  it  onto  an  "accepted"  character  set.  The
793
794 accepted character set mapping is determined by a "negotiating" session be-
795
796 tween the two systems at the start of the PhoneNet session.
797
798       MZnet transfers all information (both commands and data) in PhoneNet
799
800 packets to obtain error control.  The MZnet-PhoneNet command FTP toler-
801
802 ates noise with a high degree of success, and in effect, connects both ends of
803
804 the Split Slot together with a reliable set of virtual wires.
805
806
807
808 MZnet  Session  Example
809
810
811 Here,  a  typical  MZnet  session  is  presented,  with  the  UA  commands  issued
812
813 from  the  PC  side  of  the  connection  printed  in  a  typewriter  typeface,  and
814
815 the  responses  from  the  host  side  printed  in  an  italic  typeface.   PhoneNet
816
817 interactions are indented.  The initial connection to the host is accomplished
818
819 with the term program, which provides a simple terminal emulation function.
820
821 The prompt of the PC for a UA command is "Ai".  Note that passwords are
822
823 never echoed by the host system.
824
825
826
827                  Ai term
828
829
830
831                                                            10
832 \f
833
834
835
836                  login:  mznet
837
838                  password:
839
840                  MZ-Password:
841
842                                PhoneNet packet negotiation
843
844                  Connected.
845
846                                exit terminal mode
847
848                  Ai send  cur
849
850                                PostMail command
851
852                                message text packet transmission
853
854                                command terminator
855
856                  Ai quit
857
858                                Quit command
859
860                  Disconnecting.
861
862
863
864 Conclusions
865
866
867 The main conclusions of this paper are that small personal computer systems
868
869 with dial-up phone connections constrain User Agent systems design in ways
870
871 that  require  use  of  a  split-slot  interface  between  the  UA  and  its  supporting
872
873 Mail Transfer Agent (MTA), and that this interface will best provide the re-
874
875 quired services if it has error controlled command and data transfer facilities,
876
877 with interactive behavior.
878
879       It  is  also  believed  that  a  good  design  for  the  small  PC  UA  is  based  on
880
881 a  very  modular  architecture,  such  as  the  Rand  MH  system,  which  has  been
882
883 used as a pattern for the MZnet UA.
884
885       By bringing these concepts together, we expect MZnet to provide reliable
886
887 UA/MTA service to a distributed set of small personal computers, to match
888
889 the  quality  of  service  that  is  normally  only  available  from  larger  mainframe
890
891 host systems with co-resident UA/MTA pairs.
892
893
894
895 References
896
897
898  [1]   SRI-NIC,  ARPANET  Directory,  Network  Information  Center,  SRI  In-
899
900        ternational, Menlo Park, California (November 1980).
901
902
903
904                                                            11
905 \f
906
907
908
909  [2]   Comer,  D.,  A  Computer  Science  Research  Network  CSNET:  A  History
910
911        and Status Report, Communications of the ACM, volume 26, number 10
912
913        (October 1983) 747-753.
914
915
916  [3]   Emerson,  S.  L.,  USENET:  A  Bulletin  Board  for  Unix  Users.  BYTE,
917
918        volume 8, number 10 (October 1983) 219-236.
919
920
921  [4]   Vittal, J., MSG: A Simple Message System, in:  Uhlig (editor), Proceed-
922
923        ings  of  the  IFIP  TC-6  International  Symposium  on  Computer  Message
924
925        Systems (North-Holland, April 1981).
926
927
928  [5]   Deutsch,  D.,  Design  of  a  Message  Format  Standard,  in:  Uhlig  (editor),
929
930        Proceedings  of  the  IFIP  TC-6  International  Symposium  on  Computer
931
932        Message Systems (North-Holland, April 1981).
933
934
935  [6]   v.Bochmann,  G.  and  Pickens,  J.  R.,  A  Methodology  for  the  Specifica-
936
937        tion  of  a  Message  Transport  System,  in:  Uhlig  (editor),  Proceedings  of
938
939        the IFIP TC-6 International Symposium on Computer Message Systems
940
941        (North-Holland, April 1981).
942
943
944  [7]   Kerr,  I.  H.,  Interconnection  of  Electronic  Mail  Systems,  in:  Uhlig  (edi-
945
946        tor),  Proceedings  of  the  IFIP  TC-6  International  Symposium  on  Com-
947
948        puter Message Systems (North-Holland, April 1981).
949
950
951  [8]   Crocker,  D.,  Standard  for  the  Format  of  ARPA  Internet  Text  Messages
952
953        (RFC 822) Network Information Center, SRI International, Menlo Park,
954
955        California (August 1982).
956
957
958  [9]   NBS,  Message  Format  for  Computer-Based  Message  Systems,  U.S.  Na-
959
960        tional Bureau of Standards FIPS Publication 98 (March 1983).
961
962
963 [10]    CCITT  Study  Group  VII/5,  Draft  Recommendation  X.MHS1:   Mes-
964
965        sage  Handling  Systems:   System  Model_Service  Elements  (version  2),
966
967        Technical  Report,  International  Telegraph  and  Telephone  Consultative
968
969        Committee (CCITT) (December 1982).
970
971
972 [11]    Rose,  M.,  Low  Tech  Connections  into  the  ARPA  Internet:  The  Raw-
973
974        Packet  Split-Gateway,  University  of  California  Irvine  Techical  Report
975
976        number 216 (February 1984).
977
978
979
980                                                            12
981 \f
982
983
984
985 [12]    Crocker, D., Szurkowski, E., Farber, D. J., An Internet Memo Distribu-
986
987        tion  Facility_MMDF,  Proceedings  of  the  Sixth  IEEE  Data  Communi-
988
989        cations Symposium (November 1979).
990
991
992 [13]    Rose,  M.,  The  ZOTnet_A  Local  Area  Mailing  Network,  University  of
993
994        California Irvine Technical Report number 200 (January 1983).
995
996
997 [14]    CSNET-CIC,  Focus  on  the  University  of  California,  Irvine,  CSNET
998
999        News 2, Bolt, Beranek, and Newman, Cambridge, Massachusetts (Octo-
1000
1001        ber 1983).
1002
1003
1004 [15]    Rose,    M.,    Achieving    Interoperability    Between    Two    Domains_
1005
1006        Connecting the ZOTnet and UUCP Computer Mail Networks, University
1007
1008        of California Irvine Technical Report number 201 (January 1983).
1009
1010
1011 [16]    Rose, M., Proposed Standard for Message Munging (RFC 886), Network
1012
1013        Information Center, SRI International, Menlo Park, California (Decem-
1014
1015        ber 1983).
1016
1017
1018 [17]    Borden, B. S., Gaines, R. S., and Shapiro, N.Z., The Rand MH Message
1019
1020        Handling System:  User's Manual (Rand Corporation, March 1983).
1021
1022
1023
1024                                                            13
1025 \f
1026
1027
1028
1029 ________________________________________________________________________________________________________________________
1030
1031 Any  Host                                          Relay  Host                                       Any  Other  Host
1032
1033
1034
1035      user                                                                                                     user
1036
1037
1038
1039      UA                                                                                                        UA
1040
1041
1042
1043            slot                                                                                          slot
1044
1045
1046
1047     MTA                                    MTA                        MTA                                    MTA
1048
1049
1050
1051 PhoneNet                               PhoneNet                    PhoneNet                               PhoneNet
1052
1053
1054
1055   modem                                  modem                       modem                                  modem
1056
1057
1058
1059 _______________________________________Figure_1:__The_MHS_Model_________________________________________________________
1060
1061
1062
1063                                                            14
1064 \f
1065
1066
1067
1068 ________________________________________________________________________________________________________________________
1069
1070 Any  Host                                          MZnet  Host                                                 PC
1071
1072
1073
1074      user                                                                                                     user
1075
1076
1077
1078      UA                                                                                                        UA
1079
1080
1081
1082            slot                                                           split slot
1083                                                        MZnet                                                MZnet
1084
1085
1086
1087     MTA                                    MTA
1088
1089
1090
1091 PhoneNet                               PhoneNet                    PhoneNet                               PhoneNet
1092
1093
1094
1095   modem                                  modem                       modem                                  modem
1096
1097
1098
1099 ____________________________________Figure_2:__The_Split-Slot_Model_____________________________________________________
1100
1101
1102
1103                                                            15