home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / mail / uucp / 2104 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  4.0 KB

  1. Path: sparky!uunet!cs.utexas.edu!torn!nott!cunews!revcan!ecicrl!clewis
  2. From: clewis@ferret.ocunix.on.ca (Chris Lewis)
  3. Newsgroups: comp.mail.uucp
  4. Subject: Re: Are costs relevant ? (was Re: UUCP map entries)
  5. Message-ID: <4013@ecicrl.ocunix.on.ca>
  6. Date: 21 Nov 92 03:33:42 GMT
  7. References: <1dtdonINN58c@grasp1.univ-lyon1.fr> <4001@ecicrl.ocunix.on.ca> <1eaojtINN6a9@grasp1.univ-lyon1.fr>
  8. Organization: Elegant Communications Inc., Ottawa, Canada
  9. Lines: 84
  10.  
  11. In article <1eaojtINN6a9@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) writes:
  12. >clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
  13. >cl> Try sending mail to the postmasters, my experience is that it often
  14. >cl> helps to unjam links, or at least to get the map entries fixed.
  15.  
  16. >I did !   Still waiting for a reply... Just wondering if they read the
  17. >mail.  Other users from other sites also having trouble due to this map
  18. >entry also did... still waiting for an answer.
  19.  
  20. Well, that happens.  And it also happens that people fix things.
  21. One of the problems being that these maps tend to get out of date,
  22. and even if you do fix them, some regions haven't had map updates
  23. for as much as a year, so the SA gets just as frustrated as you.
  24.  
  25. >What is the next action to take ?  Shall the map coordinator for the
  26. >region be contacted to inform him of the trouble and eventually take
  27. >the entry out of the map, or is this out of his attributions ?
  28.  
  29. The d.Top file is explicitly for listing links or sites that
  30. cause major problems with routing.  Ie: many sites lose connections
  31. to largish parts of the net because of one bogus link.  It sounds as
  32. this may qualify.  It is *supposed* to have low latency in shipping
  33. out new ones, but...
  34.  
  35. I believe you send off to rutgers to request that one be entered.
  36. If other sites are having the same problem, have them all ask.
  37.  
  38. >The more I send mail to .UUCP domain the more I see trouble, every day
  39. >new links who can't handle what they indicate for several reasons
  40. >(going from the mailer unable to handle UUCP to those who have
  41. >just misconfigured their local name).
  42.  
  43. Well, actually, my experience isn't that bad.  I've had to mark
  44. about 3 machines dead.  Mostly because their mailers are broken,
  45. not that their links don't work.
  46.  
  47. I run a mailing list of ~200 systems.  *Most* of my bounces are
  48. due to users evaporating, not bogus routing.
  49.  
  50. >My list of "dead {site}" is growing daily. The one published in the
  51. >maps not.
  52.  
  53. That happens. Sigh.
  54.  
  55. Mel has been doing this for at least 6 years.  It ebbs and flows.
  56. It's also a lot of work.  I dunno what the answer is.
  57.  
  58. >Well all this, also arrives to what you indicate in the Unix Email
  59. >software FAQ: use domains.
  60. >
  61. >> On the other hand, I often find it more reliable to only run with
  62. >> local maps (eg: province or state), and select a well administered
  63. >> machine as smart-host.  I get virtually no bounces from mnie.
  64.  
  65. >That is definitely the solution for sites, but when I see the top-level
  66. >domains aliases in the maps and more and more sites who have one
  67. >unique UUCP connection using them in without filtering anything, it's
  68. >just stupid.
  69.  
  70. Yes.  We've had our share of people advertising .edu links.
  71.  
  72. >The shortest way from an Internet host to my machine is following the MX
  73. >routing, but when just one node before a site has digested the maps
  74. >it generates a folkoric route...
  75.  
  76. I don't quite understand you here.  Are you talking about sites
  77. rabid-routing *after* your MX forwarder?
  78.  
  79. [Note that unpackmaps can be used to short-circuit internet addressing.]
  80.  
  81. >> The *real* problem is SAs not keeping their maps up to date.
  82.  
  83. >Nor (for lots of them) knowing how to use the maps in an efficient and
  84. >workable manner.
  85.  
  86. >So what to do...  Would map coordinators like to give their opinions ?
  87. >What are the policies they use about entries with wrong or non working
  88. >links ?
  89.  
  90. I think the policy is that they will fix them IF they have the time.
  91. -- 
  92. Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
  93. Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
  94. Ferret list: ferret-request@ferret.ocunix.on.ca
  95.