home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / metamail / contrib / ServiceMail / README < prev    next >
Encoding:
Text File  |  1993-05-10  |  6.0 KB  |  130 lines
  1. The ServiceMail Toolkit, v2.0 5-10-93
  2.  
  3. Jay C. Weber <weber@eitech.com>
  4. Eric Rescorla <ekr@eitech.com> 
  5. Salil Deshpande <salil@eitech.com>
  6. Enterprise Integration Technologies (EIT)
  7.  
  8. This distribution contains software that helps you set up servers that
  9. others can access via electronic mail.  Such servers can include archive
  10. servers and mailing-list maintainers (for which code is included in this
  11. distribution), but also custom services like solid modelers, text
  12. formatters, simulators, etc.  In fact, earlier versions of this distribution
  13. were used to create the following email services:
  14.  
  15.  o a semiconductor process simulator at Stanford University
  16.  
  17.  o a PDES-described solid rendering service at the University of Utah
  18.  
  19.  o an image-to-text (OCR) service at Cornell
  20.  
  21.  o a LaTeX-to-Postscript compiler, an FTP gateway, a WAIS gateway,
  22.    a stock quote service, etc. at EIT
  23.  
  24. We hope you will think of many other batch-oriented services that your
  25. organization can provide to the world.  The advantage of the use of email
  26. access is, of course, is its ubiquity; virtually all of the roughly
  27. five million world-wide Internet users (on roughly 750,000 machines) would
  28. then be able to run your software prototype, retrieve your technical reports,
  29. or demo your new product.  Plus, there are 10-15 million other users who
  30. can reach your services through MCI Mail, Compuserve, and AT&T Easylink
  31. gateways.
  32.  
  33. Theoretically, this distribution should be straightfoward to install and
  34. use on all UNIX systems.  However, it has been tested mostly on Sun
  35. Workstations. We are very interested to hear of your experiences, both
  36. good and bad.
  37.  
  38.  
  39. Installation Issues
  40. -------------------
  41.  
  42. ServiceMail needs access to an email stream.  This distribution supports
  43. two alternative sources:  through .forward files or through system
  44. aliases.  Both require a small amount of work from a system administrator,
  45. but alias approach is more palatable to finicky administrators.  The
  46. default .forward approach is probably easier to configure and maintain.
  47.  
  48. For the .forward approach,first procure an account that is dedicated to
  49. ServiceMail.  We recommend calling it "services", and giving it only
  50. the most basic user priviledges (read/write its home directory, read
  51. and execute standard UNIX commands).  Make sure you give it a good
  52. (read: obscure) password, especially if the account is called "services",
  53. since standard account names are often the subject of system attacks.
  54. This account should be for ServiceMail only, e.g., don't use your own
  55. account because all email will be redirected to the email shell (though
  56. I suppose you could change the way unrecognized services are handled
  57. by stuffing the messages into your personal mailbox).
  58.  
  59. Now, if you have the distribution as servicemail.tar.Z:
  60.  
  61.   Other than creating the services account, no administrator priviledges
  62.   are required.  Log in as services, make sure you are in ~services and
  63.   the Toolkit .tar.Z file is handy, and unpack it by
  64.  
  65.     % uncompress servicemail.tar.Z
  66.     % tar xf servicemail.tar
  67.  
  68. For the aliases approach, create a destination directory (say,
  69. /usr/local/src/servicemail), change to that directory, and unpack
  70. the distribution as above.  Then check the file src/man/mesh.man
  71. for information about what to add to the system aliases file.
  72.  
  73. For either approach, next read the INSTALL file for information about
  74. configuration options and when to run "make".
  75.  
  76.  
  77. Configuring Example Services
  78. ----------------------------
  79.  
  80. The toolkit comes with several example services that are almost online.
  81. To actually turn them on, edit the file src/mesh/config.tcl and
  82. "uncomment" out one or more of the "define-service" lines.  Some of
  83. these services are system dependent (latex2ps requires the latex and
  84. dvi2ps commands), and some require some setup (listserv requires the
  85. directory ~/Lists and some existing mailing lists to do much;
  86. archive-request requires the directory ~/archive and some files therein
  87. to manipulate) -- check the comments and code for these services.
  88.  
  89.  
  90. Creating Custom Services
  91. ------------------------
  92.  
  93. The main reason to use this toolkit is to build custom services.  One of
  94. these days we'll have a graphical and/or interactive interface for building
  95. new services, but for now there's no getting around a little hacking.  If
  96. you are not familiar with TCL, it helps to have some experience in writing
  97. UNIX shell scripts.  We recommend that you start with one of the example
  98. services in src/services.  There is a lengthy man page on TCL in
  99. doc/Tcl.man.  Also, look at doc/mesh/hacking.doc for some information
  100. on special TCL builtins and calling conventions.
  101.  
  102. A word about security.  If you build an "exec" service, you are asking for
  103. trouble.  There are also many subtle ways to create security problems.
  104. For example, if any of your services evaluate their switches, then someone
  105. can send "{rm -r *}" as a switch and cause problems.  Make sure that
  106. publicly available services don't consume substantial resources; e.g.,
  107. if any service prints output (or mills parts!) make sure it is obscure or
  108. has some access control.  The example ps2paper service uses a simple
  109. scheme to check if requestors are local; it's better than nothing but
  110. fairly easy to fool.
  111.  
  112. We want to hear from you!
  113. -------------------------
  114.  
  115. Please let us know when you install the toolkit and what kind of services
  116. you are building for public use.  We are working on a directory
  117. service that will help people find public services and discover how to
  118. invoke them.  When you install a new, public service, send a message to
  119. the "register" service at "services@eitech.com", with a description of
  120. your service in the body (for now, in any format you wish).  To see
  121. what public services others have produced, try our "directory" service.
  122.  
  123. If you have problems, questions or suggestions write a message to the
  124. "servicemail-help@eitech.com" mailing list.  You can join this mailing
  125. list by sending a message to the
  126. "listserv subscribe servicemail-help your-real-name" service at
  127. "services@eitech.com".  This mailing list contains bug fixes,
  128. explanations, and announcements of new versions.
  129.  
  130.