Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!romp!auschs!awdprime!sandino.austin.ibm.com!jeffe From: jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) Newsgroups: comp.mail.misc Subject: Re: Anyone has experience on this? Message-ID: <2701@awdprime.UUCP> Date: 9 Jul 90 21:07:03 GMT References: <49783@iuvax.cs.indiana.edu> Sender: news@awdprime.UUCP Organization: IBM AWD, Austin, TX Lines: 34 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/ file. Instead, the received mail >will only cause wright01 to create a .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/ >file to hold message for that 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