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