home *** CD-ROM | disk | FTP | other *** search
/ Otherware / Otherware_1_SB_Development.iso / amiga / comms / network / amigauuc.lha / AmigaUUCP / man / Domains < prev    next >
Text File  |  1990-01-08  |  9KB  |  260 lines
  1.  
  2. NAME
  3.     UULIB:Domain
  4.  
  5. SYNOPSIS
  6.     -
  7.  
  8. DESCRIPTION
  9.  
  10.     The UULIB:Domain file holds routing information for addresses
  11.     you send USENET mail to.  This file is normally required ONLY if
  12.     your machine can talk to MORE THAN ONE USENET host.
  13.  
  14.     For machines that can talk to ONLY ONE USENET host, you need
  15.     only set the 'DefaultNode' entry in UULIB:Config to the name
  16.     of the one host.
  17.  
  18.     A domain is something like 'CTS.COM' or 'BERKELEY.EDU'.  Lets
  19.     say you have direct USENET connections to UCBVAX.Berkeley.EDU and
  20.     FUBAR.CTS.COM.
  21.  
  22.     Now, you want to send an email message to CHARLIE.Berkeley.EDU
  23.     and another email message to GALAXY.CTS.COM ... obviously you will
  24.     want the first message to be routed through UCBVAX and the second
  25.     routed through FUBAR.  The appropriate domain entries would be:
  26.  
  27.     *.berkeley.edu  MF    UU  ucbvax.UUCP
  28.     *.cts.com        MF    UU  fubar.UUCP
  29.  
  30.     You will also want a default of some sort ... say you send mail
  31.     to PHOTON.CSNET, you want unknown domains to be routed to somewhere
  32.     that knows how to deal with them.  So you would also have another
  33.     entry in UULIB:Domain:
  34.  
  35.     *            MF    UU  ucbvax.UUCP
  36.  
  37.     That specifies the machine to route mail through to reach an
  38.     unknown address.
  39.  
  40.     *** NOTE *** UUCP sites that you directly connect to need not be listed
  41.     in UULIB:Domain, the UULIB:L.Sys file is automatically scanned for such
  42.     sites.  For said machines any additional domain information is ignored
  43.     (such as .UUCP).  In case the name of an immediately adjacent UUCP site
  44.     conflicts with another site you can enter that other site into the domain
  45.     list explicitly using the MD Type described below.
  46.  
  47.             FORMAT OF DOMAIN FILE
  48.  
  49.     Each line in the domain file may be blank, contain a '#' and then
  50.     a comment, or contain a domain record.  Each domain record is broken
  51.     up into four fields:
  52.  
  53.     Domain Type Class Address-Info
  54.  
  55.     Domain = domain in question, you may use '*' instead of a domain
  56.          name to match ONE OR MORE SUBDOMAINS or the machine name.
  57.          Case is ignored.
  58.  
  59.          For example:   *.COM
  60.                 *.Berkeley.EDU
  61.                 *
  62.  
  63.     Type   = MF or MD.    MF stands for mail forwarder, MD stands for
  64.          mail destination.    The difference can be shown with an
  65.          example:
  66.  
  67.     ucbvax.berkeley.edu  MD UU  ucbvax.UUCP
  68.     *.berkeley.edu         MF UU  ucbvax.UUCP
  69.  
  70.     In the first case the domain is actually a complete machine
  71.     name which we can directly talk to, thus MD is used telling
  72.     the mail system that we REPLACE the address with this address.
  73.  
  74.     In the second case the machine is what we must go THROUGH to
  75.     reach machines with the given domain (note that more explicitly
  76.     specified domains always have priority of less explicitly
  77.     specified domains).  The mail system will PREPEND the address
  78.     field with the forwarding machine address.
  79.  
  80.     Class = UU
  81.     Currently only UU, meaning USENET class, is supported.    This
  82.     field is reserved to allow specification of different types
  83.     of low level mailers so the mail system is not necessarily
  84.     limited to using the USENET as the transport layer.
  85.  
  86.     AddrInfo
  87.     for the UU class AddrInfo contains a ! separated UUCP path
  88.     where the first machine MUST be an immediately adjacent node.
  89.     The remainder of the path is tagged onto the rmail line along
  90.     with the original path specification.
  91.  
  92.     NOTE:    For any machine in the bang (!) path of the AddrInfo
  93.     field which is directly connected to the previous machine
  94.     (the first machine is always directly connected to your
  95.     machine), the domain is optional.  That is, the machine may
  96.     be listed with or without a domain separated by dots.  The
  97.     examples below show parts of paths both with and without
  98.     domain names.
  99.  
  100.     when you route through the INTERNET, however, you must be
  101.     more careful.  Only known USENET paths may be addressed
  102.     without worrying about the domain part of the machine name.
  103.  
  104.             REGISTERED DOMAINS
  105.  
  106.     We will eventually have our own domain that is registered with the
  107.     network community.    When this occurs we will probably set up an
  108.     automated system that keeps everybody's UULIB:Domain file consistant.
  109.     Each UULIB:Domain file will then have an entry for all machines in
  110.     our domain.  Thus, while UULIB:Domain is not being used so much at
  111.     the moment I expect it will be used in a major way in the future.
  112.  
  113.  
  114. ADDRESSES IN A SMALL ISOLATED NETWORK
  115.  
  116.     Using the UULIB:Domain file in local networks drastically
  117.     simplifies most other parts of the UUCP mail system.  The
  118.     greatest advantage of using a Domain file is that you can
  119.     refer to machines in your local net by name rather than by
  120.     path and can refer to them by name in any groups you might
  121.     have constructed in UULIB:Aliases.    you can also use the Domain
  122.     file to re-route email to machines that may have moved to
  123.     somewhere else in your local network (say a buddy moves back
  124.     east) without bouncing the email.  Which we can't do anyway yet..
  125.     automatic bouncing will be in a future release.
  126.  
  127.     Lets say you have a group of people all running UUCP connected
  128.     like this:
  129.                    d
  130.                   /   f
  131.                  /     /
  132.             a---b---c---h
  133.                /     \     \
  134.               /       \   g
  135.              x           e
  136.  
  137.     If your machine is b.UUCP and you want to email to user@h.UUCP,
  138.     then the appropriate path is:
  139.  
  140.         To: c!h!user
  141.  
  142.     If your machine is d.UUCP and you want to email to g.UUCP,
  143.     then the appropriate path is:
  144.  
  145.         To: b!c!g!user
  146.  
  147.     There is another alternative.  You can setup your UULIB:Domain
  148.     file with all of these paths and just say:
  149.  
  150.         To: user@g.UUCP
  151.  
  152.     The Domain file would be different for each node but you have
  153.     removed the complexity one step.  The Domain file for a.UUCP
  154.     would look like this:
  155.  
  156.         *        MF UU   b.UUCP
  157.  
  158.     This assumes that b.UUCP also implements Domains.  The Domain
  159.     file for b.UUCP would look like this:
  160.  
  161.         *        MF    UU  c.UUCP
  162.         x.UUCP  MF    UU  a.UUCP
  163.  
  164.     Because, apart from x.UUCP, the only nodes b.UUCP cannot reach
  165.     directly are reachable via c.UUCP.
  166.  
  167.     The Domain file for c.UUCP would be:
  168.  
  169.         *        MF    UU  b.UUCP
  170.  
  171.     Because the only nodes c.UUCP cannot reach go through b.UUCP,
  172.     so we set the default route for unknown nodes to go through
  173.     b.UUCP.  Here we assume that b.UUCP uses UULIB:Domains as
  174.     well and knows how to get to x.UUCP which is not immediately
  175.     adjacent to it.
  176.  
  177.     The Domain file for c.UUCP assuming the b.UUCP does NOT use
  178.     a Domains file (which is safest actually) is:
  179.  
  180.         *        MF    UU  b.UUCP
  181.         x.UUCP  MF    UU  b.UUCP!a.UUCP
  182.  
  183.     Alternately you can use MD (mail destination):
  184.  
  185.         *        MF    UU  b.UUCP
  186.         x.UUCP  MD    UU  b.UUCP!a.UUCP!x.UUCP
  187.  
  188. ADDRESSES IN A SMALL NETWORK WITH A SINGLE CONNECTION TO THE OUTSIDE WORLD:
  189.  
  190.                    d
  191.                   /   f
  192.                  /     /
  193.             a---b---c---h---ucbvax.berkeley.edu
  194.                /     \     \
  195.               /       \   g
  196.              x           e
  197.  
  198.     This is another possible configuration... one person in your
  199.     little Amiga network has a connection to the outside world.
  200.     In this case everyone in your network should have UULIB:Domain
  201.     entries to properly route email back and forth. Specifically, if
  202.     you are giving somebody your email address and your machine is
  203.     x.UUCP, you want to be able to give them:
  204.  
  205.         ucbvax.berkeley.edu!h!x!user
  206.  
  207.     As your address rather than
  208.  
  209.         ucbvax.berkeley.edu!h!c!b!a!x!user
  210.  
  211.     In otherwords, you want to HIDE your local network from the
  212.     outside world.  This would require h.UUCP to have the
  213.     following UULIB:Domain file:
  214.  
  215.         *        MF    UU  ucbvax.berkeley.edu
  216.         a.UUCP  MF    UU  c!b
  217.         b.UUCP  MF    UU  c
  218.         d.UUCP  MF    UU  c!b
  219.         e.UUCP  MF    UU  c!b
  220.         f.UUCP  MF    UU  c
  221.         g.UUCP  MF    UU  c
  222.         x.UUCP  MF    UU  c!b!a
  223.  
  224.     Each of the other nodes in the network would have a similar
  225.     Domain file.  Note that when you have a connection to the
  226.     outside world the default, '*', should point to the outside
  227.     world.  The '*' entry for a.UUCP, for example, would be:
  228.  
  229.         *        MF    UU  b!c!h!ucbvax
  230.  
  231.     If everyone in your local net implemented '*' properly it
  232.     would suffice to redirect '*' to, say, just b.UUCP, and b.UUCP
  233.     would direct it to c.UUCP, etc...  The cleanest way to deal
  234.     with it is actually to redirect it to the last node in your
  235.     local net that talks to the outside world:
  236.  
  237.         *        MF    UU  b!c!h
  238.  
  239.     This allows the sysop at h.UUCP the latitude to do further
  240.     routing.  For example, what if h.UUCP was able to connect to
  241.     two machines on the outside world!
  242.  
  243.                   ucbvax.berkeley.edu
  244.                  /
  245.             ----h
  246.                  \
  247.                   pacbell.pacbell.com
  248.  
  249.     In this case you want to give h.UUCP the latitude to redirect
  250.     email to the .pacbell.com domain to pacbell.pacbell.com
  251.     instead of going the long path through ucbvax.berkeley.edu ...
  252.  
  253.         *            MF    UU  ucbvax
  254.         *.PacBell.COM   MF    UU  pacbell
  255.  
  256.     Thus, all the other nodes in your local network should direct
  257.     unknown addresses through h.UUCP rather than bypass h.UUCP's
  258.     domain system by giving an explicit route through it.
  259.  
  260.