My original request:
When sending mail from an NIS client using emacs to a destination mail
alias that is defined in the /etc/aliases file on the NIS master, I
get a return message from the Mailer-Daemon stating
"550 ... User unknown". The original message does get delivered
correctly however.
When I try the same thing using /usr/ucb/mail, everything
works correctly (the message gets delivered and I do NOT
get the "User unknown" error message.
It also works correctly when I send the message from
the NIS master.
I looked at how emacs invokes sendmail and found that it pipes
the mail message to sendmail as follows:
cat msg | /usr/lib/sendmail -oi -t -f MY-USER-ID -oem -odb
where msg contains:
To: MAIL-ALIAS
Subject: a test
<message body>
The "-t" option is used to read the mail message for recipients. If
I don't use the "-t" option and instead specify the recipient on the
command line, I don't have the problem.
It seems like the problem is with sendmail -- any fixes? I am
running 4.1.3 on a Sparc 10 Model 30.
Thanks to all who responded.
per@erix.ericsson.se (Per Hedeland)
Dave Mitchell <D.Mitchell@dcs.shef.ac.uk>
eddy@telecomm.tadiran.co.il (Edward Resnick - Sys Adm Team (1723))
Rich Schultz <rich@ccrwest.org>
perryh@pluto.rain.com (Perry Hutchison)
epl@Kodak.COM (Gene Loriot (epl@Caps.Kodak.COM.))
I fixed the problem by installing sendmail jumbo patch 100377-15 on the 4.1.3
machines and sendmail jumbo patch 101665-02 on the 4.1.3_U1 machines.
Per Hedeland provided a general list of problems with sendmail.
From per@erix.ericsson.se Tue Apr 26 10:25:50 1994
Return-Path: <@pgate:per@erix.ericsson.se>
Date: Tue, 26 Apr 94 12:28:44 +0200
From: per@erix.ericsson.se (Per Hedeland)
To: kozak@atc.boeing.com
Subject: Re: "-t" option for sendmail with NIS alias
X-Newsgroups: info.sun-managers
In-Reply-To: <9404251950.AA02873@phoney.phoney>
In article <9404251950.AA02873@phoney.phoney>, you write:
|> It seems like the problem is with sendmail -- any fixes? I am
|> running 4.1.3 on a Sparc 10 Model 30.
Canned reply follows below (see #10 in particular) - this *might* have
been fixed in one of the numerous recent sendmail patches, but...
Hope this helps...
--Per Hedeland
per@erix.ericsson.se or
per%erix.ericsson.se@sunic.sunet.se or
...uunet!erix.ericsson.se!per
------------
Here is a list of the bugs/problems with Sun's braindead 'Remote'
sendmail.cf option (OR) that I've found to date. Note that some of the
bugs may have been fixed in recent versions; however, due to the
apparent nature of the implementation of OR (lots of special-cased code
separate from the normal sendmail functionality), it is unlikely that
all known and unknown bugs will ever be fixed.
1. If the connection between client and server sendmail is broken during
the DATA phase (i.e when the actual letter is transferred), the letter
is lost, without any information to user or Postmaster, the only trace
is a "SYSERR: net hang reading from..." type of message in syslog.
2. Anyone can fake sender addresses with sendmail -f.
3. Sendmail -t forgets to remove temp file (fixed post-4.0.3, I believe).
4. Sendmail -t called from emacs (actually whenever it can't do a
getlogin()) with a local recipient address will put the *recipient*
address in the From: line.
5. If a sendmail deamon is run (e.g. if you want to be kind enough to handle
the occasional mail mis-addressed to user@client rather than having it
sit in some queue for several days before being bounced), it will ignore
the OR option, and happily do local delivery causing /bin/mail to write
/var/spool/mail via NFS, or send directly to hosts in the YP map while
setting the sender address to user@client. In addition, the local
delivery is somehow half-baked, ignoring e.g. .forward files.
6. Since (in the normal non-deamon case) the sendmail.cf apart from OR is
essentially ignored, it isn't possible to do *any* host-specific
handling, e.g. splitting up mail to root depending on which client
generated it.
7. If the mailhost isn't reachable, each letter sent will cause the
corresponding sendmail process to sit in a loop doing repeated attempts
- apart from the load, this means that if the client is shut down or
rebooted before successful delivery, the mail is lost.
8. It doesn't work at all if /var/spool/mail is auto-mounted.
9. Sendmail -t will remove one empty line between header and body, with
the effect that initial body lines that have leading whitespace, or
that start with <word>:, are moved to the header.
10. Sendmail -t where the destination is a local alias will generate a
"User unknown" error message (although the letter will be delivered
correctly) - if PostmasterCopy is in effect, there will (of course)
be an additional "User unknown" for Postmaster.
11. If a letter without a terminating newline is sent (except when using
sendmail -t), it will not be transferred to the server, instead the
connection will time out, and the net result will be as for 1 above
(this is presumably the major case where those symptoms are observed).
12. Sendmail -t where the destination is a local user with a .forward
file readable by the sender and containing a command or file name will
fail with a "Cannot mail directly to programs" (or files) type of
message. (In addition, the message doesn't look anything like a normal
sendmail error message, is delivered directly (i.e. over NFS) with a
hardwired call to /bin/mail, and doesn't contain the original message,
even though it claims to do.) Apparently fixed in patch 100377-04.
I realize that 6 and 7 are consequences of intentional design decisions, and
that 5 might be considered operator error; I still consider them deficiencies.
I definitely recommend using one of the minimalist sendmail.cf's for this
purpose that have been floating around the net instead of the OR option. The
only inconveniences with this are that you have to actually spell out the
name of the mailhost, and that you have to make sure the client's queue is
checked - if you don't want to run a deamon (which I think is the best
solution - the load from this should be neglible), you can have sendmail -q
run from crontab e.g. hourly. On the other hand, you can use the same
sendmail.cf on non-Sun mail clients. I have done just this, and all of the
problems went away (the file I'm using can be found on euagate.eua.ericsson.se
as /pub/unix/mail/sendmail.client.cf).
NOTE: Just commenting out the OR from a "standard" Sun sendmail.cf file is
*not* the right thing to do, in fact it may cause problems that are as bad
as or worse than those caused by OR.
thanks again,
Chuck
- - - - - - - - - - - - - - - - - - - - - - -
Chuck Kozak Advanced Computing Technologies
Boeing Helicopters
MS P28-24 8-7961
Phone: (610) 591-7774 FAX: (610) 591-7524
Internet: kozak@atc.boeing.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:00 CDT