home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sgi / 11185 < prev    next >
Encoding:
Text File  |  1992-07-22  |  4.2 KB  |  97 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!sgi!nimrod.wpd.sgi.com!roberts
  3. From: roberts@nimrod.wpd.sgi.com (roberts)
  4. Subject: Re: Summary: Problem with /bin/mail...
  5. Message-ID: <nkdpn0c@sgi.sgi.com>
  6. Sender: roberts@nimrod.wpd.sgi.com
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. Date: Wed, 22 Jul 1992 18:24:45 GMT
  9. Lines: 86
  10.  
  11. Tony.Martindale@comp.vuw.ac.nz writes:
  12.  
  13. >   I have several gripes with this "fix".  Firstly, it bounces mail.
  14.  
  15. First, bouncing mail that would otherwise be misdelivered is the right
  16. thing to do.  Using your criterion, /bin/mail should never have checked
  17. for passwd entries in the first place, since doing so causes it to "bounce
  18. mail."
  19.  
  20. > Secondly it is a band-aid type solution/fix, the problem indicated
  21. > could be better dealt with by adjustments/fixes in other parts of the
  22. > overall picture (YP/NIS map reliability for example).
  23.  
  24. Second, I am sure SGI and much of the workstation industry would gladly
  25. welcome your solutions to the problems of NIS map reliability.  I suggest
  26. you forward your adjusted/fixed sources to Sun Microsystems so they
  27. may eventually be made available to the wider community.  I trust your
  28. solutions also correct for operator error.
  29.  
  30. >                                                        Thirdly this is
  31. > a specific problem to large (my assumption) YP/NIS dependent sites,
  32. > using the DNS MX records (MB records and/or OSI directory services in
  33. > the future) is a far better solution to the "problem".
  34.  
  35. Third, I do not think it is a very good idea to continue to misdeliver
  36. mail for the next 3 or 4 decades while we wait for OSI to figure out how
  37. to save us from ourselves.
  38.  
  39. >                                                         Not to mention
  40. > the fact that this change was not noted in the Release Notes (or at
  41. > least the ones we have) and why wasn't backward-compatibility there
  42. > from the beginning not instead of in retrospect?
  43.  
  44. You are correct.  The change did not make it into the release notes.
  45. It should have been noted there.  That's one of the reasons I posted a
  46. long explanation here.
  47.  
  48. Restoring wrong behaviour is bad engineering.  Relying on wrong behaviour
  49. is bad engineering.  I added the backward-compatibility mode "in retrospect"
  50. because I was not aware up-front that there were any customers interested
  51. in bad engineering.  I was wrong.
  52.  
  53. >   But, this still does not explain the problems we were having.
  54.  
  55. Then what are you on about?
  56.  
  57. >                                                                  Mail
  58. > was bouncing in the way I described (see original message below) for
  59. > users with valid home directories!  I have sent mail to Robert
  60. > informing him of this, with no response to date.
  61.  
  62. Please note that I am a development engineer not a customer support engineer.
  63. I am neither required nor expected to respond to questions posted to this
  64. group, and I have only a very limited time I can spend doing so.  I have
  65. even less time available to try and diagnose customer problems via e-mail.
  66. If you need faster problem resolution, I suggest you call your local SGI
  67. field office.
  68.  
  69. >   Again, if anyone can shed any more light on this it would be
  70. > appreciated.  I would also like to see SGI take responsibility for
  71. > what has been done to /bin/mail and release a
  72. > fixed/backward-compatible version.
  73.  
  74. I will gladly take responsibility for having made message delivery via
  75. /bin/mail more reliable.  Note that reliable does not mean "doesn't bounce."
  76. As stated by Eric Allman in the design goals section of the document
  77. "SENDMAIL - An Internet Mail Router":
  78.  
  79.     Message delivery should be reliable, in the sense of guaranteeing
  80.     that every message is correctly delivered or at least brought to the
  81.     attention of a human for correct disposal; no message should ever be
  82.     completely lost.
  83.  
  84. A misdelivered message is as bad as lost.  It is better to bounce than
  85. to lose.  It may cause headaches for administrators, but it will result
  86. in more reliable mail.
  87.  
  88. A broken/backward-compatible version will be available in a future release
  89. for use by those who don't mind the possibility of misdelivered mail.
  90.  
  91.     - Robert Stephens
  92.  
  93. ---
  94. The above comments are entirely my own.  They do not necessarily represent
  95. the views or opinions of Silicon Graphics Inc.
  96.  
  97.