Dear Sun-Managers:
Well, I seem to have been victimized by a bug in sendmail. (Maybe?)
My problem (full submission included at end) is that mail delivered to
an alias which is a program does not get the sender's environment, IF AND
ONLY IF the spool directory is NFS mounted. This is a result of
sendmail running in "remote" mode (OR option set in sendmail.cf and
spool directory NFS mounted), forcing delivery to occur on the
mailhost.
I located 2 bugs on SunSolve that helped me:
> Bug Id: 1140272
> Category: utility
> Subcategory: sendmail
> Release summary: 4.1.3
> Synopsis: Vacation doesn't work when you NFS mount /var/spool/mail
> Integrated in releases:
> Patch id:
> Summary:
> Vacation doesn't work when you NFS mount /var/spool/mail.
>
> *Bug Id: 1027580
> Category: utility
> Subcategory: sendmail
> Release summary: v4, 4.0.3, 4.0, 4.1.1, 4.1.1revb
> Synopsis: A buggy entry kills an entire list
> Summary:
> When the remote option (OR in /etc/sendmail.cf) is in effect, mail to
> a list of users will get lost if any one of the recipient addresses
> cannot be resolved.
>
> In an early stadium sendmail will decide to punt the message to the
> mailspool server, using SMTP. The remote sendmail daemon will quit
> as soon as the incorrect name is transferred.
>
> Work-around: Disable the remote option in the sendmail.cf file. This
> requires aliases for all users, or a hack of sendmail.cf
> referring every username to "username@mailspool-server"
>
The first bug tells me that program execution is a problem in remote
mode.
The second bug tells me a possible work-around. (I have installed the
latest patch, 100377-05, but it didn't help.)
I have tested the work-around (commented out "OR"), and it does indeed work.
QUESTION #1: What are the ramifications of using the work-around?? I
am confused by this whole issue of "remote mode". We have all aliases
available to every client via NIS, anyway. Why should I even want to
use "remote mode"?
QUESTION #2: Is my problem yet another bug in sendmail, or is there
some good reason why the sender's environment is not used at alias
resolution time?? ("Managing NFS and NIS", p. 202, seems to indicate
that at least "$HOME" should be available in remote mode.)
Thanks in advance to anyone who can answer these questions,
Bob Cronin
(RJCronin@uop.com)
Much thanks to Hal Stern for setting me off in the right direction!
(... and for writing "Managing NFS and NIS" -- terrific book!!)
>From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
----- Begin Included Message -----
>From rjcronin Wed Aug 11 17:05:27 1993
To: sun-managers@eecs.nwu.edu
Subject: Environment lost in Centralized E-mail
Content-Length: 2390
X-Lines: 81
Status: RO
Dear Experts:
We have recently set up a second NIS domain for a new batch of about 50
SPARCstations and a new SS10 fileserver. All machines are running
4.1.3.
In our older domain ( all 4.1.1 ), mail delivery goes to the client,
but alias resolution is forced to occur on the mailhost for the domain
(i.e., clients' sendmail.cf gives /dev/null as name of alias file via
the FS parameter). Our new NIS domain has been set up for mail
delivery on that domain's mailhost, per Chapter 9 in Hal Stern's
"Managing NFS and NIS". (hopefully, anyway.)
Everything seems to work well for normal mail delivery in the new
domain, but there is a problem with an alias we have set up to
automatically decode uuencoded mail. The alias pipes the E-mail to a
sub-shell for processing, but the sender's environment is not being
picked up.
Specifically, we have the following aliases setup for each NIS domain:
# Decode attachment and put it in your home directory.
DECODE: "|( cd $HOME/DecodedMail ; /usr/bin/uudecode )"
DECODER: "|( cd $HOME/DecodedMail ; /usr/bin/uudecode )"
This works well in the client delivery situation, but $HOME is not
correctly set in the central delivery scheme.
To test this hypothesis, I created the following alias:
ECHOENV: "|( env > /tmp/environment )"
On the newly created domain, the result is:
newbrunswick% /usr/ucb/mail -v ECHOENV < /home/lekempf/decodetestfile
newbrunswick% Trying 138.90.72.141... connected.
220 epcot.eng.dpl.uop.com Sendmail 4.1/SMI-4.1 ready at Wed, 11 Aug 93 12:53:00 CDT
>>HELO newbrunswick.eng.dpl.uop.com
250 epcot.eng.dpl.uop.com Hello newbrunswick.eng.dpl.uop.com, pleased to meet you
>>MAIL FROM:<lekempf>
250 <lekempf>... Sender ok
>>RCPT TO:<echoenv>
250 <echoenv>... Recipient ok
>>DATA
354 Enter mail, end with "." on a line by itself
>>.
250 Mail accepted
>>QUIT
221 epcot.eng.dpl.uop.com delivering mail
newbrunswick%
epcot% cat /tmp/environment
HOME=/
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
epcot% ls -lasg /tmp/environment
1 -rw-rw-rw- 1 lekempf wheel 44 Aug 11 12:53 /tmp/environment
Thus, $HOME is evaluated as "/" instead of "/home/lekempf"
HOWEVER, if the same alias is used in the old domain, $HOME and all of
the user's normal environment variables are correct.
Where did we go wrong?
Thanks in advance, and I will summarize,
Bob Cronin
(RJCronin@uop.com)
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:06 CDT