home *** CD-ROM | disk | FTP | other *** search
/ back2roots/padua / padua.7z / padua / uucp / duucp-1.17 / AU-117b-man.lha / man / Domain < prev    next >
Encoding:
Text File  |  1993-12-29  |  8.4 KB  |  249 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 say
  19.     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. ADDRESSES IN A SMALL ISOLATED NETWORK
  105.  
  106.     Using the UULIB:Domain file in local networks drastically
  107.     simplifies most other parts of the UUCP mail system.  The
  108.     greatest advantage of using a Domain file is that you can
  109.     refer to machines in your local net by name rather than by
  110.     path and can refer to them by name in any groups you might
  111.     have constructed in UULIB:Aliases.    you can also use the Domain
  112.     file to re-route email to machines that may have moved to
  113.     somewhere else in your local network (say a buddy moves back
  114.     east) without bouncing the email.  Which we can't do anyway yet..
  115.     automatic bouncing will be in a future release.
  116.  
  117.     Lets say you have a group of people all running UUCP connected
  118.     like this:
  119.                    d
  120.                   /   f
  121.                  /     /
  122.             a---b---c---h
  123.                /     \     \
  124.               /       \   g
  125.              x           e
  126.  
  127.     If your machine is b.UUCP and you want to email to user@h.UUCP,
  128.     then the appropriate path is:
  129.  
  130.         To: c!h!user
  131.  
  132.     If your machine is d.UUCP and you want to email to g.UUCP,
  133.     then the appropriate path is:
  134.  
  135.         To: b!c!g!user
  136.  
  137.     There is another alternative.  You can setup your UULIB:Domain
  138.     file with all of these paths and just say:
  139.  
  140.         To: user@g.UUCP
  141.  
  142.     The Domain file would be different for each node but you have
  143.     removed the complexity one step.  The Domain file for a.UUCP
  144.     would look like this:
  145.  
  146.         *        MF UU   b.UUCP
  147.  
  148.     This assumes that b.UUCP also implements Domains.  The Domain
  149.     file for b.UUCP would look like this:
  150.  
  151.         *        MF    UU  c.UUCP
  152.         x.UUCP  MF    UU  a.UUCP
  153.  
  154.     Because, apart from x.UUCP, the only nodes b.UUCP cannot reach
  155.     directly are reachable via c.UUCP.
  156.  
  157.     The Domain file for c.UUCP would be:
  158.  
  159.         *        MF    UU  b.UUCP
  160.  
  161.     Because the only nodes c.UUCP cannot reach go through b.UUCP,
  162.     so we set the default route for unknown nodes to go through
  163.     b.UUCP.  Here we assume that b.UUCP uses UULIB:Domains as
  164.     well and knows how to get to x.UUCP which is not immediately
  165.     adjacent to it.
  166.  
  167.     The Domain file for c.UUCP assuming the b.UUCP does NOT use
  168.     a Domains file (which is safest actually) is:
  169.  
  170.         *        MF    UU  b.UUCP
  171.         x.UUCP  MF    UU  b.UUCP!a.UUCP
  172.  
  173.     Alternately you can use MD (mail destination):
  174.  
  175.         *        MF    UU  b.UUCP
  176.         x.UUCP  MD    UU  b.UUCP!a.UUCP!x.UUCP
  177.  
  178. ADDRESSES IN A SMALL NETWORK WITH A SINGLE CONNECTION TO THE OUTSIDE WORLD:
  179.  
  180.                    d
  181.                   /   f
  182.                  /     /
  183.             a---b---c---h---ucbvax.berkeley.edu
  184.                /     \     \
  185.               /       \   g
  186.              x           e
  187.  
  188.     This is another possible configuration... one person in your
  189.     little Amiga network has a connection to the outside world.
  190.     In this case everyone in your network should have UULIB:Domain
  191.     entries to properly route email back and forth. Specifically, if
  192.     you are giving somebody your email address and your machine is
  193.     x.UUCP, you want to be able to give them:
  194.  
  195.         ucbvax.berkeley.edu!h!x!user
  196.  
  197.     As your address rather than
  198.  
  199.         ucbvax.berkeley.edu!h!c!b!a!x!user
  200.  
  201.     In otherwords, you want to HIDE your local network from the
  202.     outside world.  This would require h.UUCP to have the
  203.     following UULIB:Domain file:
  204.  
  205.         *        MF    UU  ucbvax.berkeley.edu
  206.         a.UUCP  MF    UU  c!b
  207.         b.UUCP  MF    UU  c
  208.         d.UUCP  MF    UU  c!b
  209.         e.UUCP  MF    UU  c!b
  210.         f.UUCP  MF    UU  c
  211.         g.UUCP  MF    UU  c
  212.         x.UUCP  MF    UU  c!b!a
  213.  
  214.     Each of the other nodes in the network would have a similar
  215.     Domain file.  Note that when you have a connection to the
  216.     outside world the default, '*', should point to the outside
  217.     world.  The '*' entry for a.UUCP, for example, would be:
  218.  
  219.         *        MF    UU  b!c!h!ucbvax
  220.  
  221.     If everyone in your local net implemented '*' properly it
  222.     would suffice to redirect '*' to, say, just b.UUCP, and b.UUCP
  223.     would direct it to c.UUCP, etc...  The cleanest way to deal
  224.     with it is actually to redirect it to the last node in your
  225.     local net that talks to the outside world:
  226.  
  227.         *        MF    UU  b!c!h
  228.  
  229.     This allows the sysop at h.UUCP the latitude to do further
  230.     routing.  For example, what if h.UUCP was able to connect to
  231.     two machines on the outside world!
  232.  
  233.                   ucbvax.berkeley.edu
  234.                  /
  235.             ----h
  236.                  \
  237.                   pacbell.pacbell.com
  238.  
  239.     In this case you want to give h.UUCP the latitude to redirect
  240.     email to the .pacbell.com domain to pacbell.pacbell.com
  241.     instead of going the long path through ucbvax.berkeley.edu ...
  242.  
  243.         *            MF    UU  ucbvax
  244.         *.PacBell.COM   MF    UU  pacbell
  245.  
  246.     Thus, all the other nodes in your local network should direct
  247.     unknown addresses through h.UUCP rather than bypass h.UUCP's
  248.     domain system by giving an explicit route through it.
  249.