home *** CD-ROM | disk | FTP | other *** search
/ PC-Online 1996 May / PCOnline_05_1996.bin / linux / source / contrib / smail / smail-3.1 / smail-3 / smail-3.1.28 / samples / bigsite / bargw / maps / README < prev    next >
Text File  |  1990-10-24  |  9KB  |  264 lines
  1. #ident "@(#)samples/bigsite/bargw/maps/README    1.2 10/24/90 05:20:13"
  2.  
  3. -*-
  4.  
  5. README - info about the /usr/lib/smail/maps directory
  6.  
  7. The Smail routers use information found in the /usr/lib/smail/maps
  8. directory to determine routes to other sites.  Such information
  9. is usually in the format of pathalias output.
  10.  
  11. -*-
  12.  
  13. Path resolving:
  14.  
  15. Smail resolves routes by searching the following files in order from
  16. top to bottom.  These files are in the same format as pathalias
  17. output files.  Items higher on the list take priority over lower items.  
  18.  
  19.     force.path        - force routes for given sitenames
  20.     domain.path        - formed from domain.map
  21.     world.path        - major path file
  22.     uuname.path        - formed from uuname output
  23.  
  24. Pathalias output files are of the form:
  25.  
  26.     site    site_a!site_b!...!site!%s
  27.  
  28. Where site can be a simple sitename (e.g., amdahl) or a domain
  29. (e.g., .amdahl.com) or a compound name (e.g., hplabs.hp.com).
  30. Normally a complete match in one file will result in the
  31. path site_a!site_b!... being used to reach site.  If only a
  32. partial "right-hand-side" match is found, the longest
  33. match will be used.
  34.  
  35. It should be noted that transports like uux only understand
  36. simple sitenames.  This site_a, the leading site, should be a 
  37. simple site if possible.  One could use a method file to
  38. direct such paths to a transport that understands non-simple
  39. site names.  This is why a pathalias map entry should
  40. only show links from the local site to simple sitenames.
  41. One can always do:
  42.  
  43.     bargw    simple(DAILY), site(HOURLY)
  44.  
  45.     simple.domain.part = simple
  46.     site = site.com
  47.  
  48. and avoid the issue.
  49.  
  50. See below for details on each file.  See smail(5) & smail(8) for
  51. more information about routers.
  52.  
  53. -*-
  54.  
  55. duplicate site names:
  56.  
  57. Sometimes two different sites have the same site name.  There
  58. are several rules on how to deal with this case.
  59.  
  60. If one publishes in an external map (such as world.map) that
  61. one talks to  "curds", one must treat "curds" as if it is
  62. a directly connected.  This is true even if the perfered path to
  63. "curds" may be thru some other site.
  64.  
  65. One must NEVER be directly connected to two sites with the same name.
  66. One can not be connected to two sites samed "foobar".
  67.  
  68. One must never establish a connection to a site that has the same
  69. name as an unpublished site internally in our local domain.
  70.  
  71. One must never name an internal domain site the same as a site
  72. that we already directly connect to in some form.  One should
  73. not give an internal site a name of a site that is registered
  74. elsewhere.
  75.  
  76. If one does not have a direct connection to "werehwon", paths of the
  77. form:  werehwon!...!user  are ambiguous.  If "werehwon" is a simple
  78. site name, then user@werehwon is ambiguous.  Note that the address 
  79. of user@werehwon.domain is NOT ambiguous if a path to wherehwon.domain 
  80. in known.
  81.  
  82. One may dis-ambiguate an ambiguous address in any way one likes.
  83. However one should try to honor published addresses in order
  84. from top to bottom:
  85.  
  86.     * internet addresses registered by SRI-NIC  (if on the internet)
  87.     * addresses registered in a d.* Usenet map
  88.     * addresses registered in a u.* Usenet map
  89.     * addresses registered in your local.map map
  90.  
  91. If one receives a connection request from a site "foo" (lets call it
  92. new-foo), and one other site has already registered as "foo" (lets call
  93. it old-foo), one should resolve the conflict as follows:
  94.  
  95.     * If one directly talks to old-foo, refuse the connection.
  96.  
  97.     * Encourage new-foo to change its name.  Warn them of problems
  98.       they will face with their Email being mis-directed to old-foo.
  99.  
  100.     If none of the above can be done, then do the following:
  101.  
  102.     * Pick some domain based name such as "foo.domain" that
  103.       is unique and where "domain" is not "uucp".  This assumes 
  104.       that foo really is in the domain named "domain"!
  105.     
  106.     * If "foo.domain" is not already registered either as
  107.       ".domain" in the case where ".domain" is not a top level 
  108.       domain such as ".arpa"  or".edu"; Or if "foo.domain" is not 
  109.       registered, require them to first publish a map containing 
  110.       at least the following information:
  111.  
  112.         #N foo-bar, foo.domain
  113.         ... etc ...
  114.         foo-bar    yoursite(COST)
  115.         foo-bar    .foo.domain
  116.         foo.domain = foo-bar
  117.     
  118.       where foo-bar was a unique simple name.  Then add
  119.       the following lines to the forces file:
  120.  
  121.          foo-bar    foo!%s
  122.          foo.domain    foo!%s
  123.          .foo.domain    foo!%s
  124.  
  125.      If they can not publish a map entry for some reason,
  126.      refuse the connection.
  127.  
  128. -*-
  129.  
  130. unpublished connections:
  131.  
  132. It is possible to have a connection to a site where such a connection
  133. has not been published.  A few notes of care should be taken in
  134. dealing with such unpublished connections, depending on if the
  135. site you are connecting to has registered its name somewhere or not.
  136.  
  137. If the site has a registered map entry, simply use the private.map
  138. to record the connection.
  139.  
  140. If the site is not registered, warn them that if someone registeres
  141. a site with the same name, Email directed to them could be sent
  142. to that other site.  Don't record the connection in any map (other 
  143. than maybe as a comment in private.map), but rather allow the
  144. uuname.path file to record the routing information.
  145.  
  146. -*-
  147.  
  148. Internal domain sites:
  149.  
  150. Most sites internal to the BAR.FOO.COM will remain unpublished.  The
  151. visible domain on the Smail mailer for these sites should be set to
  152. FOO.BAR.COM so that route problems do not arise.  Only major
  153. FOO.BAR.COM sites such as servers or sites with names we wish
  154. to reserve should be noted in the world.map.
  155.  
  156. When selecting internal names it is very useful if they do not
  157. conflict with a published site.  Due to the way domain.path
  158. is used only the name Site.FOO.BAR.COM will always be correctly
  159. routed.
  160.  
  161. NOTE: It is important that we never establish a connection between
  162.       an outside site with the same name as an internal site.
  163.       It is also important that we never give an internal site
  164.       the same name as a site we directly talk to.
  165.  
  166. -*-
  167.  
  168. force.path file:
  169.  
  170. The force file allows one to force explicit paths to specific sites
  171. regardless of that the maps may say.  The force file should be
  172. used as a last resort when resolving conflicts.  The use of map
  173. information is not only more general, but allows finer control.
  174.  
  175. The force.path file is formed from the force file by removing
  176. comments and sorting it.
  177.  
  178. -*-
  179.  
  180. domain.path file:
  181.  
  182. The domain.path file contains path information about sites in the
  183. local domain only.  That is, each site found in the first field
  184. of the domain.path file is assumed to be in the local domain.
  185.  
  186. In for case of bargw, this local domain is BAR.FOO.COM.  A site 
  187. of the form:
  188.  
  189.         foo.BAR.FOO.COM 
  190.  
  191. will match the site named "foo" in the domain.path file.  One does
  192. not need to have both "foo" and "foo.BAR.FOO.COM" in the file.
  193.  
  194. -*-
  195.  
  196. world.path file:
  197.  
  198. When pathalias forms world.path the following information is used.  
  199. The mkpath.conf file tells mkpath how to build the world.path file.
  200. The uuwho command works off of the map files that form world.path.
  201.  
  202. A site of the form "foo.uucp" will match the site named "foo" in
  203. the world.path file.  One does not need to have both "foo" and 
  204. "foo.uucp" in the file.
  205.  
  206. Information found in maps higher on the list take priority over 
  207. information found in lower maps.  However the cost of a link is
  208. the lowest cost known.  Once can alter or force the cost of a link
  209. by the dead, delete and adjust directives.  (See below)
  210.  
  211.     tweak.map               - dead, delete, adjust and other Usenet info 
  212.     private.map             - map of unpublished links from this site
  213.     world.map            - the Usenet map we publish 
  214.     delete <sitename>       - remove Usenet info about our site (amdahl) 
  215.     newmap/*.map            - Usenet maps that have not yet been posted 
  216.     Usenet maps             - maps in /usr/spool/uumaps/[du].* 
  217.  
  218. -*-
  219.  
  220. uuname.path file:
  221.  
  222. The uuname.path file consists of a set of pathalias lines of the form:
  223.  
  224.     site    site!%s
  225.  
  226. where site is a file listed by uuname.  This serves as a catch all in
  227. case the site slips thru the other files, or in case the site
  228. can not be in a map file.
  229.  
  230. -*-
  231.  
  232. Regarding the dead {} directive:
  233.  
  234. Declaring a site or link (sitea!siteb) dead does NOT distroy the 
  235. site or link!  If no other link can be found, the least costly 
  236. dead link will be used.  In fact, declaring a link or site to 
  237. be dead will create that link if it does not already exist!  
  238.  
  239. The dead directive should never be used in Usenet maps 
  240. except maybe d.Project.  You should not publish a dead 
  241. directive in your maps.
  242.  
  243.  
  244. Regarding the delete {} directive:  
  245.  
  246. Deleting a link (sitea!siteb) removes knowledge that 
  247. sitea talks to siteb, however siteb!sitea could still
  248. exist.  Deleting a site removes all information about 
  249. that site as well as links to & from that site. A deleted 
  250. site or link may be recreated by later information.  
  251.  
  252. The delete directive never be used in Usenet maps.  
  253. You should not publish a delete directive in your maps.
  254.  
  255.  
  256. Regarding the adjust {} directive:  
  257.  
  258. An adjust directive on a site adds cost to all outgoing links 
  259. from that site.  By default the cost added is 4000.  If
  260. a site does not already exist, adjust creates it.
  261.  
  262. The adjust directive never be used in Usenet maps.  
  263. You should not publish an adjust directive in your maps.
  264.