home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / mail / misc / 3933 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  5.3 KB

  1. Xref: sparky comp.mail.misc:3933 comp.mail.uucp:2282
  2. Newsgroups: comp.mail.misc,comp.mail.uucp
  3. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!postscript.cs.psu.edu!fenner
  4. From: fenner@postscript.cs.psu.edu (Bill Fenner)
  5. Subject: Re: Mixed format addresses
  6. Message-ID: <Bz4xxE.7M1@cs.psu.edu>
  7. Sender: news@cs.psu.edu (Usenet)
  8. Nntp-Posting-Host: postscript.cs.psu.edu
  9. Organization: Penn State Computer Science
  10. References: <ByzBuu.2Hq@cs.psu.edu> <eBmLVB4w165w@willard.UUCP>
  11. Date: Sat, 12 Dec 1992 07:24:50 GMT
  12. Lines: 95
  13.  
  14. In article <eBmLVB4w165w@willard.UUCP> dawson@willard.UUCP writes:
  15. |In particular, I was referring to sites that want Internet
  16. |connectivity, and furthermore accept requests for UUCP connections from
  17. |those who cannot afford to be directly on the Internet, yet refuse to accept
  18. |that it is they (each and every sysadmin of each and every Internet site),
  19. |who should make email to and from their UUCP friends WORK.
  20.  
  21. Ok, wait, let me get this straight.  You say that site foo.bar.edu accepts
  22. a UUCP connection to your site, and therefore that makes me, at
  23. cmf.nrl.navy.mil, responsible for being able to get mail to you?  Uh-uh.
  24. If you want to look like part of the Internet, then get a domain name.  If
  25. you don't want to play by the (easy and free) rules, then don't complain
  26. that the game's no fun.
  27.  
  28. |> Well, the point is that if you don't ask someone if you can use someone else
  29. |> as a gateway, you shouldn't be surprised if they get mad at you when they fin
  30. |> out that you're the reason their phone bills just doubled.
  31. |
  32. |So, they should ask THEIR mail feed systems to do filtered mail delivery.
  33.  
  34. Huh?  The Internet isn't store-and-forward like UUCP; for the most
  35. part, anyway.  If I want to send mail to foo.bar.edu, I'll open a
  36. connection to foo.bar.edu (or mail.bar.edu, if they have an MX record)
  37. and send it.  Who's going to do the filtering?
  38.  
  39. |There ought to be a universally available (easily accessible to both UUCP
  40. |and Internet connected sites) means of determining which systems are willing
  41. |to provide gateway services between the Internet and the "UUCP-net".
  42.  
  43. I'm not arguing that there shouldn't be.  I'm just saying that there
  44. isn't now [that I know of].  It's not the data in the UUCP maps - 3 of
  45. the 7 sites that I asked about their entries in d.Top responded.  Two
  46. said that the entry was deprecated cruft (one of them said he barely
  47. had any UUCP connections at all any more), and one said they would
  48. route mail if I was a customer.
  49.  
  50. (This, btw, is the biggest problem with the UUCP maps.  Some of the
  51. data is so ancient that there's no way it's current.  Not usually a
  52. problem with the DNS; since the DNS is a distributed database, you can
  53. be easily in charge of your little section, as opposed to having to
  54. mail your database updates to central site X.)
  55.  
  56. |It has everything to do with the discussion.  Reasoning for MX over pathalias
  57. |includes "it works so much better."  Does it really?  I don't think so.  Why?
  58. |Because so many are using old, out-of-date mail delivery software.
  59.  
  60. The same people who are using old, out-of-date mail delivery software
  61. are the same ones who are likely to use old, out-of-date pathalias
  62. data.  At least, with the DNS, once you get it right, there's almost no
  63. way to use out-of-date info.  With the UUCP maps, it's easy for
  64. automated unpacking systems to break, sysadmin doesn't notice, *poof*,
  65. you're using old data.
  66.  
  67. |You'll NEVER have the case where EVERYONE is registered in MX.
  68.  
  69. You mean the DNS.  Why not?  That was the original design goal.
  70.  
  71. |Even so, the MX system could soon be overwhelmed by the load of systems
  72. |joining one domain or another.
  73.  
  74. The DNS is a distributed, scalable database.  The UUCP maps are significantly
  75. more likely to get overwhelmed by numbers of systems than the DNS is.
  76.  
  77. |I don't see how this system
  78. |of managing email routing is any better (by itself) than pathalias in its
  79. |management of system resources or in its ability to properly route email.
  80.  
  81. Using the DNS, I have no need to store any information about anyone on
  82. my computer; I can just look it up.  Using the UUCP maps, I have to keep
  83. 6.7 megs of map files, and a 1.6 meg (33k line) paths file.  Which seems
  84. like the more desirable system?
  85.  
  86. |The maps and the MX records are truly authoritative.  Convincing Internet
  87. |sites that routing to sites in the UUCP pseudo-domain is possible, despite
  88. |"no" response from DNS queries, should be an interesting trick.
  89.  
  90. Well, all you need is a site that is willing to be a gateway for you, which
  91. is where we seem to have started this conversation.
  92.  
  93. |Hence my earlier comments on an apparent lack of responsibility.
  94. |Internet sysadmins have not yet been convinced that proper routing of
  95. |email is a matter of responsible networking, or they would surely take it
  96. |upon themselves to set up sites (which already do name service resolution)
  97. |to also perform pathalias routing.
  98.  
  99. It makes no sense for an Internet-only site to run pathalias; the maps are
  100. of no use for them.  Therefore, the site must find a way from the Internet
  101. to UUCP.  The easiest way for it to do that is an MX record.
  102.  
  103. Why not register in the .US domain?  It's free, easy, and will let you get
  104. E-Mail from the Internet with no trouble.  The .UUCP pseudo-domain is an
  105. old hack that should have disappeared years ago.  That's the problem with
  106. "transitionary" hacks, though - they never go away...
  107.  
  108.   Bill
  109.