home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / mail / uucp / 1659 < prev    next >
Encoding:
Text File  |  1992-08-14  |  6.4 KB  |  140 lines

  1. Newsgroups: comp.mail.uucp
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!news.utdallas.edu!corpgate!bnrgate!bwdls61!bwdlh118!clewis
  3. From: clewis@ferret.ocunix.on.ca (Chris Lewis)
  4. Subject: Re: Internet <--> UUCP gateway
  5. Message-ID: <1992Aug14.145727.12384@bwdls61.bnr.ca>
  6. Originator: clewis@bwdlh118
  7. Sender: usenet@bwdls61.bnr.ca (Use Net)
  8. Nntp-Posting-Host: bwdlh118
  9. Organization: Que?
  10. References: <1992Aug8.014028.16205@cfctech.cfc.com> <1615bbINNbsn@grasp1.univ-lyon1.fr> <1992Aug13.222953.24812@cfctech.cfc.com>
  11. Date: Fri, 14 Aug 1992 14:57:27 GMT
  12. Lines: 126
  13.  
  14. In article <1992Aug13.222953.24812@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes:
  15. |In article <1615bbINNbsn@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel) writes:
  16. |>kevin@cfctech.cfc.com (Kevin Darcy) writes:
  17. |>> THE UUCP MAPS DO *NOT*, IN AND OF THEMSELVES, REFLECT OPTIMAL
  18. |>> MAIL PATHS OVER THE INTERNET!!!
  19.  
  20. I'd state it a little stronger - the UUCP maps *seldom* reflect optimal
  21. paths over the internet.
  22.  
  23. |>But now that top-level domains seem to be more and more aliased in the
  24. |>UUCP maps, all those semi-bread-dead hosts (ie who are UUCP and
  25. |>use a smart host for the domain addresses they don't know about)
  26. |>will use the pathalias generated route for *any* destination if the
  27. |>admins do not themselves remove the pertinent information from the
  28. |>maps before running pathalias... (I sometimes get UUCP routed mail
  29. |>3 or 4 days after being sent, instead of the usual 1-2 hours when the
  30. |>sender used its smart host).
  31.  
  32. I was under the impression that the top level domains *shouldn't* be
  33. aliased in the maps, except in d.Top.
  34.  
  35. |>This leads to the eternal question: should domain mail always
  36. |>be sent to an Internet smart host for relaying (in some rare situations
  37. |>it's cheaper and faster not to go on the Internet and back to
  38. |>UUCP). But, curiosity, are there lots of sites who are more than
  39. |>say 2 or 3 hops away from their Internet relay (see below)? Also lots of
  40.  
  41. Actually many sites have no formal internet relay at all.
  42.  
  43. |>them just rely on 1 or 2 UUCP connections... I mean for a typical site
  44. |>(such as a XXX-only UUCP customer) there is no real interest
  45. |>to parse domain information from the maps as routing will always be
  46. |>better when there is no explicit route at the relay node.
  47.  
  48. The heuristics can be reasonably fairly smart, without having to spend
  49. too much time hand tuning.
  50.  
  51. Case in point: my machine ferret.ocunix.on.ca.
  52.  
  53. [smail 2.5, UUCP only]
  54.  
  55. I've set my system up to run only with the Canadian maps instead of the
  56. full maps for two reasons:
  57.  
  58.     1) it's a little hard on my machine to run pathalias on that much
  59.        data, especially since the likelyhood of actually wanting to
  60.        reach any of the 10000+ hosts that far away are lower.
  61.        Especially since my smart-host is more likely to be able
  62.        to "route smart" than me.
  63.     2) the risks of being toasted by goofy map entries is much higher.
  64.  
  65. This is being done automatically by my unpackmaps 4.0 - it has a list of
  66. which maps I wish to discard.
  67.  
  68. Obviously, I use my smart-host as a forwarder to hosts not listed in the paths
  69. file.  In my case, since I'm a uunet.ca subscriber, they are my smart-host.
  70.  
  71. Secondly, unpackmaps 4.0 has a new feature that allows you to strip domain
  72. names and translate them into shorter paths.  You supply a route to an
  73. internet site ("domain-forwarder"), and unpackmaps will replace all paths to
  74. sites that are *longer* than the supplied domain-forwarder route with a simple
  75. punt to the domain forwarder.  Again, I've chosen uunet.ca as my domain
  76. forwarder.
  77.  
  78. [While it would have been better to short-circuit domain routes that "cost"
  79. more than the domain-forwarder's, you can't do this without hacking pathalias.]
  80.  
  81. Other people who are using unpackmaps with mixed UUCP and SMTP connections
  82. apply filters to strip out domainized names completely.
  83.  
  84. While uunet.ca is obviously going to take pains to keep it's database up to
  85. date, chosing any "reasonable" well-run internet site works just as well.
  86.  
  87. In fact, if you're running with a local subset of the maps, it's frequently
  88. a good idea to choose your smart-host as outside of your map area
  89. (because if you don't know it, you might as well pump it out to somebody
  90. outside your area to find), while keeping your domain-forwarder local.
  91.  
  92. |Are you assuming that all MX forwarders keep up-to-date and accurate paths? 
  93. |That has not been my observation. At least if I process a full set of maps 
  94. |myself, I can be fairly certain that messages will get to their remote 
  95. |destinations EVENTUALLY. Without pathalias, it's just "punt and pray". 
  96.  
  97. It's my experience that "punt and pray" works more reliably than full
  98. maps.  Because the maps seldom list the real internet links, and uunet.ca's
  99. mailer is a little less likely to be broken than mine ;-)
  100.  
  101. Using the full pathalias database for everything leaves you at the mercy
  102. of some nimnut who hasn't updated their map in years, or advertises
  103. nonexistant links.  I have a lot more trouble with the latter than with my
  104. forwarder not being able to figure it out.
  105.  
  106. |Besides, what about unqualified addresses? My nearest relay doesn't run 
  107. |pathalias, so that'd be a GUARANTEED extra hop for it to forward to someone
  108. |else for pathalias address-resolution. If I can supply the bang-path myself, 
  109. |that extra hop is eliminated.
  110.  
  111. If you run with your state (provincial) or regional maps, this extra hop
  112. for smart-hosting is irrelevant - it's gotta go a long way anyways.
  113.  
  114. |Many relays will barf on unqualified addresses, 
  115.  
  116. Mark 'em dead.  You have to choose your relay intelligently - ie: one that knows
  117. how to handle them.
  118.  
  119. |too, or, even worse, will remedially tack on their OWN domain, resulting in 
  120. |mutant addresses ("cfctech.PoDunk.Edu", anyone?).
  121.  
  122. Mark 'em dead.  I have over a dozen *broken* "major hub" sites marked dead in
  123. my local overrides.  They mangle addresses even when the incoming From: line
  124. is *already* domainized.
  125.  
  126. |UUCP sites downstream from 
  127. |such relays are practically FORCED to either run pathalias to resolve such 
  128. |addresses, or to "qualify" all UUCP addresses by tacking on the infamous, 
  129. |risky ".UUCP" (scary stuff).
  130.  
  131. You do your damndest to not be below one of these sites.
  132.  
  133. |>I would tend to suggest admins to describe well their neighborhood and
  134. |>prefer using a smart host for relaying domain adresses rather than
  135. |>information from the map (I do not agree with you Kevin, I consider
  136. |>MX routing as more reliable as UUCP maps just because lots of entries
  137. |>are not updated to accurate information).
  138.  
  139. I agree too.
  140.