NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/sgi/11298

Internet Message Format | 1992-07-23 | 5.6 KB

Path: sparky!uunet!wupost!waikato.ac.nz!comp.vuw.ac.nz!rata.vuw.ac.nz!tony
Newsgroups: comp.sys.sgi
Subject: Re: Summary: Problem with /bin/mail...
Message-ID: <[e-mail]>
From: [e-mail] (Tony Martindale)
Date: Fri, 24 Jul 1992 03:20:24 GMT
Followup-To: comp.sys.sgi
References: <[e-mail]>
Organization: C.S.C., Victoria University of Wellington, New Zealand
Keywords: /bin/mail
Summary: Response to Robert Stephens' posting
Lines: 117


In article <[e-mail]> [e-mail] (roberts) writes:
>[e-mail] writes:
>
>>   I have several gripes with this "fix".  Firstly, it bounces mail.
>
>First, bouncing mail that would otherwise be misdelivered is the right
>thing to do.  Using your criterion, /bin/mail should never have checked
>for passwd entries in the first place, since doing so causes it to "bounce
>mail."

 You take my statement too far.  Ok, in the context of the problem you
are addressing bouncing the mail is the best/correct thing to do.  I
am coloured by our experience here where our mail was bounced when
normally it should have delivered (even using your criteria).

>> Secondly it is a band-aid type solution/fix, the problem indicated
>> could be better dealt with by adjustments/fixes in other parts of the
>> overall picture (YP/NIS map reliability for example).
>
>Second, I am sure SGI and much of the workstation industry would gladly
>welcome your solutions to the problems of NIS map reliability.  I suggest
>you forward your adjusted/fixed sources to Sun Microsystems so they
>may eventually be made available to the wider community.  I trust your
>solutions also correct for operator error.

 My point is that there are other ways to solve the problem, my
example was just that.

>>                                                        Thirdly this is
>> a specific problem to large (my assumption) YP/NIS dependent sites,
>> using the DNS MX records (MB records and/or OSI directory services in
>> the future) is a far better solution to the "problem".
>
>Third, I do not think it is a very good idea to continue to misdeliver
>mail for the next 3 or 4 decades while we wait for OSI to figure out how
>to save us from ourselves.

 Agreed.  However, the DNS is a working alternative.

 If I understand the problem correctly, there are a number of ways of
solving it without changing the behaviour of /bin/mail.  One could
argue that it is simply more an system managment/administration issue
that you have chosen to address using /bin/mail.

>>                                                         Not to mention
>> the fact that this change was not noted in the Release Notes (or at
>> least the ones we have) and why wasn't backward-compatibility there
>> from the beginning not instead of in retrospect?
>
>You are correct.  The change did not make it into the release notes.
>It should have been noted there.  That's one of the reasons I posted a
>long explanation here.
>
>Restoring wrong behaviour is bad engineering.  Relying on wrong behaviour
>is bad engineering.  I added the backward-compatibility mode "in retrospect"
>because I was not aware up-front that there were any customers interested
>in bad engineering.  I was wrong.

 In our environment (and I would imagine others) your definition of "wrong
behaviour" does not make sense.

>>   But, this still does not explain the problems we were having.
>
>Then what are you on about?
>
>> was bouncing in the way I described (see original message below) for
>> users with valid home directories!  I have sent mail to Robert
>> informing him of this, with no response to date.
>
>Please note that I am a development engineer not a customer support engineer.
>I am neither required nor expected to respond to questions posted to this
>group, and I have only a very limited time I can spend doing so.  I have
>even less time available to try and diagnose customer problems via e-mail.
>If you need faster problem resolution, I suggest you call your local SGI
>field office.

 Note that what I am saying here is that there is a bug in addition to
the disputed "addtional featurism".
 Thanks for taking the time to respond so far, I will take this up
with our local SGI agents, with your permission I will include our
discussion so far.

>>   Again, if anyone can shed any more light on this it would be
>> appreciated.  I would also like to see SGI take responsibility for
>> what has been done to /bin/mail and release a
>> fixed/backward-compatible version.
>
>I will gladly take responsibility for having made message delivery via
>/bin/mail more reliable.  Note that reliable does not mean "doesn't bounce."
>As stated by Eric Allman in the design goals section of the document
>"SENDMAIL - An Internet Mail Router":
>
>    Message delivery should be reliable, in the sense of guaranteeing
>    that every message is correctly delivered or at least brought to the
>    attention of a human for correct disposal; no message should ever be
>    completely lost.
>
>A misdelivered message is as bad as lost.  It is better to bounce than
>to lose.  It may cause headaches for administrators, but it will result
>in more reliable mail.

 As I conceded above, bouncing in the
>A broken/backward-compatible version will be available in a future release
>for use by those who don't mind the possibility of misdelivered mail.
>
>    - Robert Stephens
>
>---
>The above comments are entirely my own.  They do not necessarily represent
>the views or opinions of Silicon Graphics Inc.


--
Tony Martindale                     Computing Services Centre,
email: [e-mail]          Victoria University of Wellington,
phone: [phone]               P.O. Box 600, Wellington, NEW ZEALAND.