/bin/mail on 3B2.

[Mark Horton]

In article <511 at gagme.chi.il.us> greg at gagme.chi.il.us (Gregory Gulik) writes:
>I am using a 3B2 running System V 3.2, and using smail for E-mail.
>
>I noticed that /bin/mail doesn't call smail to process Internet
>type addresses, and it doesn't handle them itself.
>
>A lot of programs have /bin/mail hardcoded into them, which fails
>when a domain type address is specified.
>
>Is there anything I can do to /bin/mail, or is there a direct replacement
>for it that will work properly?

I gather you already have smail, which doesn't come with System V.
smail 2.* comes with a replacement program for /bin/mail called
svbinmail.  The standard smail installation procedure moves /bin/mail
to /bin/lmail and installs svbinmail as /bin/mail.  This is much like
plugging an answering machine in between your phone set and the line.
lmail still does local delivery and serves as a user interface, while
smail handles nonlocal UUCP delivery or calls sendmail.  All svbinmail
does is decide whether to call lmail or smail.

I think smail 3.* can be installed in much the same way, although that's
a very different program that happens to have the same name.

smail 2.* was posted to comp.sources.unix long ago and can probably be
found in your local archives or on UUNET.

By the way, while it's true that many programs have /bin/mail hardcoded
into them, this is not a good idea.  /bin/rmail is probably a more stable
target.  Eventually IEEE 1003.2 systems will have a standard way to do
this, which will probably be neither mail nor rmail.  It's best to allow
the program to be configured from a file so recompilation isn't necessary.
For example, mailx lets you "set sendmail=/bin/mail" or whatever
in the /usr/lib/mailx/mailx.rc file, ditto for Berkeley Mail.  There are
many back ends on different UNIX systems, you don't know what your program
will wind up running on.  (Beware of locking protocols, too, they are not
all the same, and you need to lock the mailbox to write back to it.)

	Mark