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

Internet Message Format | 1992-07-21 | 12.0 KB

Path: sparky!uunet!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!mail-news
Newsgroups: comp.sys.sgi
Subject: Summary: Problem with /bin/mail after upgrade to Irix 4.0.4 - has not been resolved
Message-ID: <[e-mail]>
From: [e-mail] (Tony Martindale)
Date: Tue, 21 Jul 1992 23:47:36 GMT
Sender: [e-mail]
Organization: C.S.C., Victoria University of Wellington, New Zealand
Summary: A summary of the reponses I received and the status of the problem, followed by the original message and replies
X-Mailer: mail-news 4.0
Lines: 272



  I received one response via email from Robert Stephens
<[e-mail]> of SGI, which was the same as that posted
to this group.  He said that "As of 4.0, IRIX /bin/mail is pickier
about validating local users," and gave slight justification for /bin/mail's
change in behaviour.  He said that /bin/mail now checks for a valid
home directory on the actual host that /bin/mail is running on.

  C. Harald Koch <[e-mail]> posted a followup to Robert's
comment, stating that he considered the new featurism a bug due to the
fact there are several situations where no home directory is required
or desired.

  Robert then responded to this with full justification for the
/bin/mail modification.  Basically it now copes with the situation where
the YP/NIS aliases map is not available but passwd is, the mail is
delivered locally and is "lost" - that is, held on a local host that
the intended recipient does not log onto very often if at all.  To the
plea to change /bin/mail back to what it was Robert replied that he
had already added an option that will override the "new" behaviour,
this will be available in a future release.

  I have several gripes with this "fix".  Firstly, it bounces 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).  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".  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?

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

  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.


  My original posting and subsequent discussion:

%%%%%%
  We have a Sicicon Graphics 4D/340S with no graphics hardware.  Over
the weekend we upgraded from Irix 3.3.2 to 4.0.4, comming into work on
Monday I was greeted with a lot of bounced mail like the following:

Date: Sun, 28 Jun 1992 20:36:58 GMT
From: Mail Delivery Subsystem <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Returned mail: unknown mailer error 8

   ----- Transcript of session follows -----
mail: Can't send to gnat
mail: Return to [e-mail]
554 <[e-mail]>... unknown mailer error 8

   ----- Unsent message follows -----

 [message deleted]


  As we run IDA sendmail, I checked out the distributed sendmail.cf to
see if the local mailer flags had changed significantly, they hadn't.
But for the record the Mlocal/Mprog definitions we use are:

Mlocal, P=/bin/mail, F=EDFMlsm, R=25/10, S=10, A=mail -s -d $u
Mprog,  P=/bin/sh,  F=DFMhlsue, R=10, S=10, A=sh -c $u

As distributed with 4.0.4 they are:

Mlocal, P=/bin/mail, F=EDFMlsmhu, S=10, R=20, A=mail -s -d $u
Mprog,  P=/bin/sh,   F=lsDFMe, S=10, R=20, A=sh -c $u


  So next I try talking with /bin/mail directly.  I had a frustrating
time trying this with differing results depending on the user code I
was using and who I was sending to!  Wierd.  But I could reproduce
the problem that sendmail was having with a test user set up for the
purpose:

tanksout@kauri% /bin/mail -s -d notmxer
|>From tanksout
To: notmxer
From: tanksout

Hello?


mail: Can't send to notmxer
mail: Return to tanksout


  If /usr/sbin/Mail is used the sender receives the following:

|>From [e-mail] Mon Jun 29 02:31:09 1992
Received: from kauri.vuw.ac.nz by kauri.vuw.ac.nz with UUCP id AA13355
  (5.65c/IDA-1.4.4 for [e-mail]); Mon, 29 Jun 1992 02:31:09 GMT
Date: Mon, 29 Jun 1992 02:31:09 GMT
From: Tony test csc mail logon <[e-mail]>
Message-Id: <[e-mail]>
Apparently-To: [e-mail]

***** UNDELIVERABLE MAIL sent to notmxer, being returned by kauri.vuw.ac.nz!tanksout *****
mail: Error # 8 'Invalid recipient' encountered on system kauri.vuw.ac.nz

Received: by kauri.vuw.ac.nz id AA13348
  (5.65c/IDA-1.4.4 for notmxer); Mon, 29 Jun 1992 02:31:08 GMT
Date: Mon, 29 Jun 1992 02:31:08 GMT
From: Tony test csc mail logon <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: test


  Since we still had the 3.3.2 /usr partition around I tried the old
/bin/mail - no problems.  So my fix has been to run the old binary
which is working just fine.  Interestingly 4.0.4 /bin/mail is setuid
whereas the 3.3.2 version was just setgid.  Appart from running IDA
sendmail the only other significant change that we have made is to
make /usr/mail read/writable by everyone with the sticky bit on.

  So my questions are:

    Is this a known problem, what is going on (I wish we had the source)?

    If so, is there a fix available?


  Any information or help would be appreciated.  Thanks in advance.

%%%%%%


%%%%%%
Date: Mon, 29 Jun 92 18:56:34 -0700
From: [e-mail] (roberts)
To: [e-mail]
Subject: Re:  Problem with /bin/mail after upgrade to Irix 4.0.4
Cc: [e-mail] (Tony Martindale)

As of 4.0, IRIX /bin/mail is pickier about validating local users.  It used
to be sufficient to find an entry for the local user in the passwd file.
Since many sites use network-wide passwd files, /bin/mail now checks for a
valid home directory (as specified in the passwd entry) on the local machine.
If the home directory does not exist, the recipient is considered invalid.

    - Robert Stephens
      Silicon Graphics Inc.

%%%%%%


%%%%%%
In article <[e-mail]> you write:
In <[e-mail]> [e-mail] (roberts) writes:

|>As of 4.0, IRIX /bin/mail is pickier about validating local users.  It used
|>to be sufficient to find an entry for the local user in the passwd file.
|>Since many sites use network-wide passwd files, /bin/mail now checks for a
|>valid home directory (as specified in the passwd entry) on the local machine.
|>If the home directory does not exist, the recipient is considered invalid.

I personally consider this a bug, not a feature. Because of this check, I
can't set up a POP or IMAP mailbox for a user without creating a home
directory for that user. I don't want a zillion home directories for all my
POP users; these people will never actually login, so they don't need home
dirs. All these extra directories only clutter the filesystem.

Change it back, please!

--
"If looks could kill, I     | C. Harald Koch  Alias Research, Inc. Toronto, ON
would have to make a saving | [e-mail]                (work-related mail)
throw!"                     | [e-mail]     (permanent address)
     -Gerry Smit, 19-May-92 | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)
%%%%%%


%%%%%%
Harald Koch writes:
|> I personally consider this a bug, not a feature. Because of this check, I
|> can't set up a POP or IMAP mailbox for a user without creating a home
|> directory for that user. I don't want a zillion home directories for all my
|> POP users; these people will never actually login, so they don't need home
|> dirs. All these extra directories only clutter the filesystem.

Consider the bug it fixes.  If network aliases go "down" but network
passwds stay "up" for any significant period of time, mail can be
lost.  If a user on hostA sends mail to "foo" expecting network aliasing
to change "foo" into "foo@hostB", and if network aliases are "down" but
network passwds are "up", the mail will be delivered locally to "foo"
on hostA.  Since "foo" is not a user on hostA, and does not expect to
receive mail on hostA, the mail is effectively lost.

This is not so rare as you might suspect.  Here at SGI, we use network
aliases and passwds.  Before I made the change, 80% of our hosts had
bad /usr/mail/non-local-user type mailfiles, some containing significant
amounts of mail that had collected, silently, over a period of months and
years.  None of this mail had been seen by the intended recipients, and
no error messages had ever been sent to the senders.

Note that a common mistake made with aliases files can disable NIS aliases.
The dbm/ndbm(3B) limit of 1024 bytes for the sum of the sizes of a
key/content pair is often (unintentionally) violated in alias files
when a user sets up a large mailing list or adds new members to an existing
mailing list.  When such an alias entry exceeds the 1024 byte limit,
the NIS aliases database may be "trashed" until the error is discovered.
Since the resulting mail "failures" are silent, it may take some time before
the problem is noticed.  All this while, the NIS passwd database is probably
working just fine, and lots of mail may be delivered to unexpected places.

The old "if I can find a passwd entry for a user, it's safe to deliver his
mail locally" rule pre-dates the use of network alias and passwd files and
the use of such files destroys the assumptions behind that rule.  The intent
of the passwd check is to:

    1) Detect bogus user names.

    2) Insure that mail is delivered to the "right" (expected) place.

The assumptions behind the old rule were:

    1) The "right" place to deliver mail for a user is on the host where
       he has a login account.

    2) The passwd file contains entries for all and only the users who
       have login accounts on the local host.

The use of network passwd files rendered assumption 2) untrue and changed the
behaviour of /bin/mail.  Unfortunately, this relaxed (I claim overly-relaxed)
behaviour was unwittingly exploited in cases where non-local mail delivery was
desired.  Because things seemed to work most of the time, and because
"failures" were silent and often went undetected, no real thought was given to
creating a mechanism to implement safe non-local delivery.

My change to /bin/mail was made in order to restore the original functionality
and to accept mail only for those users who have login accounts on the local
host.  Unfortunately, this fix will break any configuration that relies on
/bin/mail's previous and unintentionally forgiving nature.

As you correctly point out, the use of networked hosts and remote mail
retrieval protocols like POP and IMAP have rendered assumption 1) untrue in
some cases.  This does not, however, justify relaxing the delivery rules to
such a point that mail can be delivered to surprizing places.  What it does
seem to indicate is that there now needs to be a specific and direct way to
designate the "right" place to deliver mail in the non-local case.  Perhaps
some new field in the passwd entry is needed to indicate a user's non-local
mail host (if any).

|> Change it back, please!

In the interest of flexability and backward-compatibility, I've already
implemented an option to /bin/mail that may be used to override this new
behavior.  It will be available in a future release.

    - Robert Stephens
      Silicon Graphics Inc.
%%%%%%


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