Tony C. Cheng, 5-7978@ETS <TCHENG%AQUA.DECNET@iuvax.cs.indiana.edu> (07/05/90)
Following is a description of the mail problem happened on our Unix System V
box which we use as a StarGROUP unix server. If anyone ever encountered problem
like this one, please tell me the solutions you'd applied. Any hint will be
hightly appreciated!
ps. Currently I'm thinking that if I replace the System V /bin/mail with a
BSD mail, it might work.
==================
From: ROSE::TCHENG "Tony C. Cheng, 5-7978@ETS" 27-JUN-1990 10:14:09.80
To: JACOBSJ
CC: @TEK
Subj: mail receiving on wright01
I've been studying and thinking about the mail receiving problem in the past
few days, it is about time to give out a full description of the problem, and
I want to emphasize that the steps toward a solution is getting closer.
Some directories and file on wright01 are involved here:
/usr/lib/mailx/mailx.rc
/usr/lib/sendmail.cf
/usr/spool/mqueue
/usr/mail/<login name>
/usr/mail/<login name>.lock
/etc/profile
The Unix System V uses its "mail" program for local e-mailing, but when
remote machines get involved, users need to use "mailx" in conjuctions
with "sendmail" program instead of "mail" for e-mailing.
The way "mail" works is that each time someone sends out a mail to another
user on the same host, the mail message will be first queued in the
/usr/spool/mqueue directory in two parts:
dfAAxxxxxxx --- message body
qfAAxxxxxxx --- message header
("x" is a digit representation)
Then the parts will be composed as a whole text again and put in
a /usr/mail/<login name> file under the mail receiver's username, and
the system will prompt the user about mail arrival.
The local mail in this fashion was working fine on wright01. The problem
comes from mails sent by remote hosts. Mails from outside world will only
be held in the /usr/spool/mqueue directory for a while and then bounced back
to their senders. From those queued messages, we know that wright01 can
definitely receive incoming mails from other hosts, but however, they cannot
be appended to the /usr/mail/<login name> file. Instead, the received mail
will only cause wright01 to create a <login name>.lock file under that
/usr/mail directory. Which means that, for some reasons, "mailx" fails to
recognize the /usr/mail as a postoffice or create a /usr/mail/<login name>
file to hold message for that <login name> user.
As a result, all we need to do is to make setups for "mailx" or
"sendmail", so "mailx" knows to use /usr/mail as postoffice to
distribute mails.
John, tonight I will need to shutdown wright01 again to test some new
configuration in /usr/lib/mailx/mailx.rc, /usr/lib/sendmail.cf
and /etc/profile. Hope that I will get better outcome.
_Tony
----------------------------------------------------------------------*
Tony C. Cheng
Education Technology Services
Indiana Universityjeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (07/10/90)
In article <49783@iuvax.cs.indiana.edu> TCHENG%AQUA.DECNET@iuvax.cs.indiana.edu (Tony C. Cheng, 5-7978@ETS) writes: > [ lots of extraneous stuff] >The local mail in this fashion was working fine on wright01. The problem >comes from mails sent by remote hosts. Mails from outside world will only >be held in the /usr/spool/mqueue directory for a while and then bounced back >to their senders. From those queued messages, we know that wright01 can >definitely receive incoming mails from other hosts, but however, they cannot >be appended to the /usr/mail/<login name> file. Instead, the received mail >will only cause wright01 to create a <login name>.lock file under that >/usr/mail directory. Which means that, for some reasons, "mailx" fails to >recognize the /usr/mail as a postoffice or create a /usr/mail/<login name> >file to hold message for that <login name> user. Actually, the program that tries to append incoming mail to the user's mailbox is whatever is defined in sendmail's config file as the "local" mailer. I assume in your case it's /bin/mail (not mailx). /bin/mail should tell you if it can't append to the mailbox file; unfortunately, it isn't very good about saying exactly *why*. So I assume you're getting errors from /bin/mail in the transcript section of the returned mail saying something like "cannot append to /usr/mail/username". If you can use /bin/mail locally to deliver mail, and it only bounces incoming remote mail, then this certainly suggests that it's dependent on how sendmail is invoking it. Check the permissions on the /usr/mail directory, on /bin/mail (is it setuid?), and check the u and g options in the sendmail.cf file, which determine what group and user id sendmail will invoke the mailer under (if the mailer's S flag isn't set). This should all add up to a permissions problem making /bin/mail unable to open the mailbox files. ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night