home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / mail / uucp / 1656 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  4.7 KB

  1. Path: sparky!uunet!caen!rphroy!cfctech!kevin
  2. From: kevin@cfctech.cfc.com (Kevin Darcy)
  3. Newsgroups: comp.mail.uucp
  4. Subject: Re: Internet <--> UUCP gateway
  5. Message-ID: <1992Aug13.222953.24812@cfctech.cfc.com>
  6. Date: 13 Aug 92 22:29:53 GMT
  7. References: <1992Aug05.043403.394@ecst.csuchico.edu> <1992Aug8.014028.16205@cfctech.cfc.com> <1615bbINNbsn@grasp1.univ-lyon1.fr>
  8. Organization: Chrysler Financial Corp., Southfield, MI
  9. Lines: 77
  10.  
  11. In article <1615bbINNbsn@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel) writes:
  12. >kevin@cfctech.cfc.com (Kevin Darcy) writes:
  13. >> THE UUCP MAPS DO *NOT*, IN AND OF THEMSELVES, REFLECT OPTIMAL
  14. >> MAIL PATHS OVER THE INTERNET!!!
  15. >> [sample deleted, but it reflects really good the situation].
  16. >
  17. >But now that top-level domains seem to be more and more aliased in the
  18. >UUCP maps, all those semi-bread-dead hosts (ie who are UUCP and
  19. >use a smart host for the domain addresses they don't know about)
  20. >will use the pathalias generated route for *any* destination if the
  21. >admins do not themselves remove the pertinent information from the
  22. >maps before running pathalias... (I sometimes get UUCP routed mail
  23. >3 or 4 days after being sent, instead of the usual 1-2 hours when the
  24. >sender used its smart host).
  25. >
  26. >This leads to the eternal question: should domain mail always
  27. >be sent to an Internet smart host for relaying (in some rare situations
  28. >it's cheaper and faster not to go on the Internet and back to
  29. >UUCP). But, curiosity, are there lots of sites who are more than
  30. >say 2 or 3 hops away from their Internet relay (see below)? Also lots of
  31. >them just rely on 1 or 2 UUCP connections... I mean for a typical site
  32. >(such as a XXX-only UUCP customer) there is no real interest
  33. >to parse domain information from the maps as routing will always be
  34. >better when there is no explicit route at the relay node.
  35.  
  36. Are you assuming that all MX forwarders keep up-to-date and accurate paths? 
  37. That has not been my observation. At least if I process a full set of maps 
  38. myself, I can be fairly certain that messages will get to their remote 
  39. destinations EVENTUALLY. Without pathalias, it's just "punt and pray". 
  40.  
  41. Besides, what about unqualified addresses? My nearest relay doesn't run 
  42. pathalias, so that'd be a GUARANTEED extra hop for it to forward to someone
  43. else for pathalias address-resolution. If I can supply the bang-path myself, 
  44. that extra hop is eliminated. Many relays will barf on unqualified addresses, 
  45. too, or, even worse, will remedially tack on their OWN domain, resulting in 
  46. mutant addresses ("cfctech.PoDunk.Edu", anyone?). UUCP sites downstream from 
  47. such relays are practically FORCED to either run pathalias to resolve such 
  48. addresses, or to "qualify" all UUCP addresses by tacking on the infamous, 
  49. risky ".UUCP" (scary stuff).
  50.  
  51. >I would tend to suggest admins to describe well their neighborhood and
  52. >prefer using a smart host for relaying domain adresses rather than
  53. >information from the map (I do not agree with you Kevin, I consider
  54. >MX routing as more reliable as UUCP maps just because lots of entries
  55. >are not updated to accurate information).
  56.  
  57. It would be nice if some sort of utility was run periodically on Internet 
  58. hosts which would double-check and/or supplement the UUCP map data with DNS-
  59. derived information. If the map data were more complete and accurate, I 
  60. believe pathalias would be a much more useful tool. Integrating the hosts.txt 
  61. data with the UUCP maps (as we do here) results in dramatic path-
  62. optimizations, but real live DNS data would be superior by an order of 
  63. magnitude...
  64.  
  65. >
  66. > [interesting table showing connectivity of hosts in the UUCP maps]
  67. >
  68. > [...]
  69. >
  70. >I considered as "internet sites" hosts (name = host.foo.bar) where
  71. >the given FQDN has an A record in the DNS. This is an approximation but
  72. >works pretty well. It would have been better to consider an Internet
  73. >sites those having an MX pointing in their own domain or an A record.
  74.  
  75. Hmmmm... I don't agree that just because a host's MX points within its own 
  76. domain that it should be considered an "Internet host" for these purposes.
  77. What about the fairly-common case of a large UUCP network sitting behind a 
  78. corporate/organizational gateway? The only _bona fide_ Internet host there
  79. is the gateway, but I think with your criteria you'd end up counting all of
  80. the UUCP hosts behind it too.
  81.  
  82. ------------------------------------------------------------------------------
  83. kevin@cfctech.cfc.com           | Kevin Darcy, Unix Systems Administrator
  84. ...sharkey!cfctech!kevin       | Technical Services (CFC)
  85. Voice: (313) 759-7140           | Chrysler Corporation
  86. Fax:   (313) 758-8173           | 25999 Lawrence Ave, Center Line, MI 48015
  87. ------------------------------------------------------------------------------
  88.