From: roberts@nimrod.wpd.sgi.com (roberts)
Subject: Re: Summary: Problem with /bin/mail...
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 22 Jul 1992 18:24:45 GMT

Tony.Martindale@comp.vuw.ac.nz 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."

> 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.

>                                                        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.

>                                                         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.
 
>   But, this still does not explain the problems we were having.

Then what are you on about?

>                                                                  Mail
> 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.

>   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.

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.