home *** CD-ROM | disk | FTP | other *** search
/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / SMAILBIN.ZIP / DOC.ZIP / README < prev    next >
Encoding:
Text File  |  1990-04-03  |  6.7 KB  |  131 lines
  1.         Read.Me - Updated 9/15/87
  2.  
  3. What smail does:
  4.  
  5.   smail is capable of handling UUCP syntax (bang paths, bang
  6.   domains, and at domains are supported) mail transportation
  7.   over UUCP/uux/rmail channels.  It will support machines that
  8.   only have UUCP connections, and machines with UUCP links to
  9.   the outside world plus a small number of local machines that
  10.   are reached via SMTP.  The domain intelligence is embedded
  11.   in the smail database (e.g. the pathalias output), not the
  12.   sendmail.cf file, so if you have a fancier domain structure
  13.   that involves SMTP or anything other than uux in the domain
  14.   structure, you'll want to modify the sendmail.cf file here or
  15.   merge pieces of the enclosed sendmail.cf into your own.
  16.  
  17.   smail runs under 4.2BSD and System V, as a back end to sendmail;
  18.   and under System V without sendmail.  It also replaces rmail, which
  19.   becomes a link to smail.  In a sendmail environment, smail depends on
  20.   sendmail to crack the headers, as smail just deals with the envelope.
  21.   smail makes your host capable of using the INTERNET definition in the
  22.   Usenet software.
  23.  
  24.   Features of smail include:
  25.  
  26.   (1) Using pathalias data to choose the best route to your destination.
  27.   (2) Handling of user@domain, domain!user, and host!user syntax.
  28.   (3) Generation of domain!user syntax to be forwarded by other systems.
  29.   (4) Logging of traffic through your machine, by sender, recipient, and
  30.       size of message, so you can, track use and detect abuse of your
  31.       machine.
  32.   (5) Mail being forwarded through your machine to another uux link is
  33.       passed from rmail directly to uux, so there's less overhead on
  34.       your machine (sendmail stays out of the loop.)
  35.   (6) Sendmail-like alias capability for hosts without sendmail.
  36.   (7) Generation of RFC822 required headers for locally generated mail.
  37.   (8) Robust delivery scheme that reroutes only if stated path is inaccessible.
  38.   (8) Mail that is undeliverable is returned to sender.
  39.   (9) Simplicity.
  40.  
  41. Prerequisites:
  42.  
  43.   A copy of a recent posting of pathalias.  (The one posted
  44.   by Peter Honeyman in January 1986 is recommended.)
  45.  
  46.   A current copy of the UUCP map, or at least a copy of the
  47.   appropriate part of it that you're interested in.
  48.  
  49.   A properly registered domain name for your organization, such
  50.   as ATT.COM.  (It is possible to run smail using a domain name
  51.   under .UUCP, but since this can't be officially registered,
  52.   it is appropriate only for testing.)
  53.  
  54.   You can get pathalias from the mod.sources Usenet archive
  55.   (contact sources-request@uunet.uu.net or uunet!sources-request)
  56.  
  57.   You can get a UUCP map each month from Usenet newsgroup mod.map.
  58.   The UUCP map is quite large (currently about 2MB) so please don't ask
  59.   to have a copy mailed to you - get a copy from a nearby Usenet site.
  60.  
  61.   You can get a domain name by joining the UUCP Zone.  There are
  62.   low membership dues for this, and a registration process that
  63.   will take 2-8 weeks.  This Read.Me file may be out of date by
  64.   the time you read it, so we ask you to contact us for current
  65.   dues rates and procedures.  Contact uucp-query@Stargate.COM or
  66.   cbosgd!stargate!uucp-query and ask for the UUCP Zone information
  67.   packet.  (If you already belong to a network such as CSNET, DDN,
  68.   or BITNET, your organization may already have a domain name.  If
  69.   you are also on UUCP, it is recommended that you also join the
  70.   UUCP Zone at the lower rate for organizations whose primary
  71.   affiliation is with another network.  See the file "Registry"
  72.   for more information.
  73.  
  74. Overall structure:
  75.  
  76.   smail is installed in /bin/smail with a link in /bin/rmail.  Uuxqt
  77.   calls rmail, which either forwards the message on to the next hop
  78.   directly or, on a sysetm with sendmail, calls sendmail.  sendmail
  79.   may decide the message should be delivered by UUCP, and invoke smail,
  80.   which will look up a route and invoke uux.  (Note that the choice
  81.   about when to invoke sendmail and when to process a message directly
  82.   can be configured in smail.)
  83.  
  84.   smail uses a database which is generated from pathalias.  You take the
  85.   current UUCP map, add some local information and topology data (to tell
  86.   it about the domain tree) and run pathalias.  The result is sorted and
  87.   installed in /usr/lib/uucp/paths.  There is no hashing done on this
  88.   file - when smail looks up a name it uses a binary search.
  89.  
  90. Configuration considerations:
  91.  
  92.   You'll note two configuration options in defs.h: HANDLE and ROUTING.
  93.   These control which sorts of addresses smail/rmail will handle, and
  94.   which type of routing they will do.  The HANDLE define only affects
  95.   rmail, since smail sets it implicitly.  In any case, we recommend
  96.   that you leave HANDLE alone, unless you are making major changes.
  97.  
  98.   ROUTING has three choices: JUSTDOMAIN, ALWAYS, and REROUTE.  rmail
  99.   will run as JUSTDOMAIN, the defs.h default.  This means rmail will
  100.   only apply routing if it sees "rmail user@domain", and will just call
  101.   uux if it sees "rmail host!user".  (If the uux fails, it will call
  102.   smail -r, which will apply ALWAYS routing to try to get the mail
  103.   there anyway.  If the ALWAYS routing fails, then REROUTE routing is
  104.   applied.  This has the advantage of being low overhead on your
  105.   system, not second guessing a route someone else asked for, and still
  106.   recovering nicely from the mistakes of another system.  Your host
  107.   becomes a "smart host" that can get mail anywhere.)
  108.  
  109.   Many people will note huge paths going through their machine.  These
  110.   paths are generated by replies to netnews messages, and tend to be 10
  111.   or 20 hops long - far longer than necessary.  If you are a bit aggressive,
  112.   you can change -r to -R, which will cause such failed mail to be rerouted,
  113.   thus, mail to a!b!c!d!e!f!g!user will look up a route to g, and send the
  114.   mail to route!g!user.  (If it can't find g, it will try f, then e, and
  115.   so on until it finds someone it recognizes.)  If you are REALLY aggressive,
  116.   you can change ROUTING to REROUTE in defs.h, to get the same effect for
  117.   ALL rmail being passed through your machine.  This may help cut phone
  118.   bills, but it has some disadvantages.  It can lengthen a path sometimes,
  119.   e.g. mail to tektronix!user might turn into ihnp4!tektronix!user if your
  120.   routing database says mail to tektronix goes through ihnp4.  It makes it
  121.   hard to route around a dead host, or to redirect traffic from a mailing
  122.   list to several different directions.  It may also make mail go a different
  123.   path than what your user thought it was, and it affects other hosts that
  124.   route mail through you if you set ROUTING to REROUTE in defs.h.  So only
  125.   do this if you know what you are doing, and are willing to live with the
  126.   disadvantages.
  127.  
  128. #
  129. #@(#)Read.Me    2.5 (smail) 9/15/87
  130. #
  131.