home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / talk / abortion / 47754 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  5.0 KB

  1. Xref: sparky talk.abortion:47754 news.admin.misc:322 comp.mail.misc:3675
  2. Path: sparky!uunet!gossip.pyramid.com!pyramid!weitek!nadja
  3. From: nadja@jetsun.weitek.COM (Nadja Adolf)
  4. Newsgroups: talk.abortion,news.admin.misc,comp.mail.misc
  5. Subject: Re: Clearly NOT a FORGERY
  6. Message-ID: <1992Nov12.223026.8023@jetsun.weitek.COM>
  7. Date: 12 Nov 92 22:30:26 GMT
  8. References: <1992Nov11.161634.7564@rotag.mi.org> <1992Nov12.010902.24671@jetsun.weitek.COM> <1992Nov12.070041.10433@rotag.mi.org>
  9. Organization: WEITEK Corporation, Sunnyvale CA
  10. Lines: 105
  11.  
  12. In article <1992Nov12.070041.10433@rotag.mi.org> kevin@rotag.mi.org (Kevin Darcy) writes:
  13. >In article <1992Nov12.010902.24671@jetsun.weitek.COM> nadja@jetsun.weitek.COM (Nadja Adolf) writes:
  14. >>In article <1992Nov11.161634.7564@rotag.mi.org> kevin@rotag.mi.org (Kevin Darcy) writes:
  15. >>>In article <1992Nov11.003355.29646@jetsun.weitek.COM> nadja@jetsun.weitek.COM (Nadja Adolf) writes:
  16. >>
  17. >>Ha! If you aren't in the maps, you may not be reachable at all. 
  18.  
  19. >The kind of host to which I'm referring would still be reachable using its
  20. >fully-qualified domain name (FQDN).
  21.  
  22. **********************************************
  23. Kevin lets us know how much he hates uucp. :-)
  24. **********************************************
  25.  
  26. >I wouldn't call that a "smart" mailer. In fact, I'd probably get the other
  27. >sysadmin to fix his brain-dead software, if I ever saw that happening.
  28. >Additionally, if these "smart" mailers are Internet hosts, such a practice 
  29. >may very likely qualify as a violation of RFC 1123: with regard to the "local 
  30. >part" of a hybrid address (which is what the bangpath is considered, in 
  31. >Internet terms) gateways are supposed to interpret that "as necessary" to 
  32. >route the mail to its destination, and cutting off the path doesn't sound 
  33. >like it qualifies thereunder.
  34.  
  35. YO, KEVIN, WAKE UP!
  36. And it may well cut it off if another site has that name, or if the path 
  37. isn't recognized. Believe it or not, there are a lot of screwed up sites
  38. out there, and if a node on the path is out, if you don't have a UUCP
  39. registry, your mail may meet the bit bucket.
  40.  
  41. >By comparison, do you know of any smart mailers who cut off FQDN's? If not, 
  42. >then the hosts in question are still reachable via their FQDN's, and don't 
  43. >*NEED* map entries. That was my point. With a little skullduggery on the part 
  44. >of my upstream feed, rotag.mi.org wouldn't need a map entry to get its mail 
  45. >either. But I prefer to maintain one anyway, for added reliability, and to be 
  46. >a good net.citizen. The point is, map entries are not CRITICAL for many folks' 
  47. >mail routing. So it hardly makes sense to flame people, like ncsu.edu, for 
  48. >having out-of-date map entries, or no map entries at all. What's their 
  49. >incentive to keep a complete set of UUCP map entries up to date?
  50.  
  51. There incentive is having the mail arrive.
  52.  
  53. >>And the address you are describing (rotag.mi.org)
  54. >>is NOT a UUCP address. UUCP addresses are of the form node.uucp, or
  55. >>wolves.uucp. UUCP addresses are NOT the same as Internet, or ARPANET,
  56. >>or any other net - it's plain old-fashioned UNIX to UNIX Copy Protocol.
  57.  
  58. >"Plain old-fashioned UUCP"? You mean like this:
  59.  
  60. Yes. Not domain-coup addressing. :-)
  61.  
  62. >Script started on Thu Nov 12 00:56:34 1992
  63. >/dev/ttyp0: Not owner
  64. >rotag% uux - -r heifetz.uucp\!rmail nadja@jetsun.weitek.com
  65. >bad system name: heifetz.uucp
  66. >uux failed ( 68 )
  67. >rotag% ^D
  68. >script done on Thu Nov 12 00:57:28 1992
  69.  
  70. >Gee, I guess you were wrong about "<node>.uucp" being an address
  71. >comprehendable by "plain old-fashioned UUCP", huh? Surprise, surprise.
  72.  
  73. Give it a rest. Try sending email to the literal address 'user@node.uucp.'
  74. If your tables are up to date, you'll reach my home machine, and receive
  75. a message telling you that you probably didn't really want to talk to
  76. user@node.uucp.
  77.  
  78. >Trust me on this one, Nadja -- although both are valid addresses for the same
  79. >UUCP machine, a *lot* more mailers will be able to deliver mail reliably to 
  80. >"<user>@rotag.mi.org", than to "<user>@rotag.uucp".
  81.  
  82. No shit, Sherlock. Especially if rotag.uucp isn't on the maps. :-)
  83. And of course, we won't mention the importance of the records for 
  84. reaching addresses of the FDQN form. :-)
  85.  
  86. >>A message to a UUCP machine will frequently travel by Internet to the
  87. >>nearest UUCP gateway - and if you are on the UUCP maps, you can always
  88. >>send it via uunet.uu.net. And if you aren't, it may hop around, right
  89. >>back to the sender.
  90.  
  91. >A gross oversimplification. First of all, if you're a UUCP machine, you could 
  92. >have all the map entries in the world, and STILL not be able to get mail that 
  93. >originates on Internet hosts, unless you have an MX record registered in the 
  94.     [more blather relating to Kevin's poor view of UUCP]
  95.  
  96. Kevin justifies his failure to keep the routing maps up to date by giving
  97. us examples of what happens when people don't keep the maps up to date...
  98.  
  99. >>There are some books on UUCP protocols. I suggest you read them.
  100.  
  101. >Been there. Done that.
  102.  
  103. Maybe you should take a Reading Comprehension course?
  104.  
  105. >                                - Kevin
  106.  
  107. nadja@weitek.com
  108.  
  109. nadja@node.uucp
  110. nadja@node.com
  111.  
  112. -- 
  113. The Earth Pig Bourne....
  114.  
  115. nadja@node.com (prefered email address)
  116. nadja@weitek.com
  117.