[comp.mail.sendmail] smail3 setup question about mail waiting

gary@sci34hub.UUCP (Gary Heston) (07/19/90)

I've been working on installing the latest version of smail on this
system, as a precursor to installing it on all the local systems I
get to take care of. (smail seems to be far easier to set up; the 
biggest hassle I've had is not having the nroff macros for the
man pages and docs. :-) )

I've run into one problem, which I'm not sure how to fix properly.

The system is a SCI 3000 (386 Multibus), running ISC 1.0.6.
As shipped, the AT&T /bin/mail program with the -e option is used
to check for mail waiting. /bin/mail is smart enough to check the
contents of /usr/mail/$LOGNAME (the mail spool file) to see if it
contains a "Forward to..." command, and does not flag that as mail.
I.e., if your have forwarded your mail and log in, the script
fragment:

  if mail -e
    then echo "you have mail"
  fi

does not execute the echo. Unfortunantly, mail also doesn't know anything
about aliasing, .forward files, or domain addresses, either. To gain the 
benefits of smail handling these, a public domain program called binmail
is included to replace /bin/mail. binmail checks to see if the input is
something smail needs to handle, and hands it off to a local mail handler
if it's not.

The problem is that now, the mail -e test does not work correctly. If no
mail is present, it exits correctly. If anything is in the mail spool
file, it hangs. (This is normally tested in /etc/profile. If it hangs 
there, it means logging in elsewhere as root [bypasing the test] and
killing the process. If run from a shell prompt, it's possible to DEL
out of it.)

My current workaround is to replace the first line of the above shell
fragment with:

  if [ -s "/usr/mail/$LOGNAME" ]

which doesn't hang, but it also reports a "Forwarded to..." entry as
waiting mail. This primarily affects me, since I have several userids
forwarded to me. However, due to the variety of mail readers in use
here (mailx, ISC TenPlus, GNU Emacs) I need to make the /bin/mail
program handle things correctly. I've tried using different names
for the original bin mail, as well as moving it to another directory 
and still calling it mail. These don't work--apparently, it checks
the full path it's invoked by, and if it's not /bin/mail, tough.

I haven't been able to locate anything in the smail docs about this,
other than the instructions regarding using binmail in place of
/bin/mail. I'm not much of a C programmer, unfortunantly, or I'd
try tackling the binmail program and expanding it. 

Has anyone else run into this? Any suggestions? Any idea why it fails
when mail is there, but not otherwise?

-- 
    Gary Heston     { uunet!sci34hub!gary  }    System Mismanager
   SCI Technology, Inc.  OEM Products Department  (i.e., computers)
"The esteemed gentleman says I called him a liar. That's true, and I
regret it." Retief, a character created by Keith Laumer.