home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2214 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  5.5 KB

  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!wupost!usc!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!uicvm.uic.edu!yang.earlham.edu!bsu-ucs.uucp!bsu-cs!news.cs.indiana.edu!
  2.  rutgers!ub!csn!nc
  3.    ar!elroy.jpl.nasa.gov!decwrl!decwrl!infopiz!mccall!ipmdf-newsgate!list
  4. Newsgroups: vmsnet.mail.pmdf
  5. Subject: Problems with NETFIND (cont).
  6. Message-ID: <8B12FB6920A002B6@SCSW5.SLAC.STANFORD.EDU>
  7. From: mls@slac.stanford.edu (Mike Sullenberger (415) 926-2294)
  8. Date: 27 Aug 92 19:17:00 GMT
  9. Organization: The Internet
  10. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  11. Resent-Date: 27 Aug 1992 12:17 -0700 (PDT)
  12. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  13. CC: info-pmdf@YMIR.CLAREMONT.EDU, info-multinet@tgv.com,
  14. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  15. Resent-Message-ID: <01GO2QTWFFTU95OHO5@YMIR.CLAREMONT.EDU>
  16. X-Vms-To: in%"schwartz@latour.cs.colorado.edu"
  17. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  18. Content-Transfer-Encoding: 7BIT
  19. Lines: 98
  20.  
  21. >Date: Wed, 26 Aug 1992 03:32:31 -0600
  22. >From: Mike Schwartz <schwartz@latour.cs.colorado.edu>
  23. >Subject: RE:  BIG complaint about NETFIND
  24. >To: mls@SLAC.STANFORD.EDU
  25. >
  26. >Mike,
  27.  
  28. >I added some code to Netfind to check for SMTP servers that report
  29. >erroneous info.  So, even if you don't make the change to the server I
  30. >suggested, people should no longer get invalid information about your site.
  31. >Note that this change has not yet propogated to the Netfind server run by
  32. >the Gopher folks - I told them about it, but for now they are still running
  33. >an older version.
  34. > - Mike
  35.  
  36. Is the fix that you have made global or did you just put in a flag for
  37. SERV01.SLAC.STANFORD.EDU?  If it is not a global change then there are very
  38. likely many site Postmasters that are wondering why mail is being addressed to
  39. totally inappropriate hosts.
  40.  
  41. If your are going to try doing SMTP Mailer functions then you need to do ALL of
  42. the things that an SMTP Mailer needs to do and one of the primary things is that
  43. it OBEYS the Domain Nameservice MX records.  Under NO circumstances should you
  44. send an SMTP EXPN command to any node except for the nodes that are  pointed to
  45. by MX records (unless there are not any MX records), also remember to go through
  46. your MX records in the correct order.
  47.  
  48. --------------------------------------------------------------------------------
  49.  
  50. >Date: Wed, 26 Aug 1992 11:24:38 -0600
  51. >From: Mike Schwartz <schwartz@latour.cs.colorado.edu>
  52. >Subject: RE:  BIG complaint about NETFIND
  53. >To: mls@SLAC.STANFORD.EDU
  54.  
  55. >Ok, I'll fix the seed database entries.
  56.  
  57. > - Mike
  58.  
  59. --------------------------------------------------------------------------------
  60.  
  61. >Date: Wed, 26 Aug 1992 11:37:32 -0600
  62. >From: Mike Schwartz <schwartz@latour.cs.colorado.edu>
  63. >Subject: RE:  BIG complaint about NETFIND
  64. >To: mls@SLAC.STANFORD.EDU
  65.  
  66. >This is also a consequence of the fact that the Gopher people don't keep
  67. >their Netfind server up-to-date.  I fixed this problem a while ago on
  68. >the University of Colorado server.
  69. >
  70. >I'd like to point out that Netfind is a purely voluntary effort.  I am
  71. >not paid to do it - it is simply the outcome of a research prototype I
  72. >built.  The tone of your messages imply that I am somehow obligated to fix
  73. >things with respect to your domain.  I'm doing this out of a community
  74. >spirit.  Perhaps in the future when you see things like this you can take
  75. >the situation into account before you fire off an angry message.
  76. > - Mike
  77.  
  78. You don't get the point.  I am not asking you to make changes to NETFIND so that
  79. I can use it, but so that it does not cause problems to other people on the
  80. network.  These are changes I certainly feel that you are obligated to fix and
  81. to fix them quickly.  Anytime that a program such as NETFIND comes on the
  82. network which provides mis-information and forces me to waste my time to clear
  83. up the confusion, then I will certainly fire off angry messages.
  84.  
  85. --------------------------------------------------------------------------------
  86.  
  87. >Date: Thu, 27 Aug 1992 09:41:09 -0600
  88. >From: Mike Schwartz <schwartz@latour.cs.colorado.edu>
  89. >Subject: RE:  A problem with NETFIND (fyi)
  90. >To: mls@SLAC.STANFORD.EDU
  91.  
  92. >Mike, I'm surprised at you.  This "problem with Netfind" was in reality a
  93. >problem with the information your mailer gives out.  Moreover, one day
  94. >after you told me about it, I changed Netfind to detect such problems,
  95. >and not give out the invalid information.
  96. > - Mike
  97.  
  98. Stop calling SERV01.SLAC.STANFORD.EDU a MAILER Node.  Just because it happens to
  99. run an SMTP Deamon on it is NOT relevant.  If an outside SMTP mailer ignores the
  100. MX records and sends SMTP commands to the node then that mailer is BROKEN (in
  101. your case NETFIND is BROKEN) and it deserves whatever it might get.
  102.  
  103. I forwarded our communication to a wider list so that other Postmasters on the
  104. network would not have to waste alot of their time figuring out why people from
  105. all over the world were sending mail destined for people that were not even at
  106. their site to a some host in their domain.
  107.  
  108. Actually you have done one service to the network.  You have pointed out very
  109. dramatically how easy it is to envade someones privacy on the network.  It looks
  110. like I will now have to look into shuting down access from offsite to all of the
  111. services that NETFIND abuses, maybe I should have shutdown these services before
  112. now.  There are a lot of government sites, ours included, that do not look
  113. kindly on this type of probing.  If we want to allow general electronic access
  114. to essentually private information (there are many privacy issues that need to
  115. be resolved first) then we would do it the correct way by putting up, for
  116. example, an OSI X.500 directory server or a WHOIS server.
  117.  
  118. Mike Sullenberger
  119.