Complete mail subsystem for Xenix

[Chip Rosenthal]

In article <885 at wshb.csms.com>
	michaelb at wshb.csms.com ( WSHB Operations Eng) writes:
>What I am thinking of doing is just completely leaving the SCO mail stuff
>out during the installation and putting in a more unix like mail system,
>ie. no /usr/lib/mail/execmail or other wierdness.

I agree with you 90% :-)

I have run two different mail configurations under SCO XENIX.  One was
Elm+smail2.5+deliver, the other (and current configuration) is Elm+smail3.1.

However, neither of these approaches provides a "binmail" function - and
that is required.  For example, cron needs to be able to call "mail" to
send its messages.  Furthermore, the plain vanilla mailx/Mail user agent
is sometimes nice to have.  Both of these functions are served by the SCO
/usr/bin/mail program, and therefore, you are going to want to keep that.

So why not just ln smail to /bin/mail?  Well - the semantics are different.
You need the "-s subject" support of binmail.  Furthermore, binmail treats
the entire input as message body, where smail handles embedded headers.
The difference is subtle.  If the cron output contains an error message
such as "/usr/spool/blurfl: bad directory", smail will think you are
sending a message with no body, just a header line called
"/usr/spool/blurfl:".

I often use SCO's /usr/bin/mail to do mailbox editing.  Unfortunately,
the Elm editing function puts you in the editor with the entire mailbox,
whereas the /usr/bin/mail function lets you edit a single message.

Unless you are willing to write or port a binmail (absolutely required)
and maybe a mailx/Mail (nice to have), you need SCO's /usr/bin/mail.
Since you need that, you need to provide a /usr/lib/mail/execmail for
/usr/bin/mail to talk to.  So, do not plan on divesting yourself of
SCO's mail system totally.

At the very least, you need to load on their /usr/bin/mail, provide a
/usr/lib/mailrc which says "set execmail", and provide a
/usr/lib/mail/execmail which either kicks stuff over to smail (either
flavor - 2.5 or 3.1) or let smail masquarade as execmail.

Myself, I just load up SCO's entire mail system, move their /usr/bin/rmail
and /usr/lib/mail/execmail out of the way, and then dump my junk on top.

>Should I get smail3.1 working? Or should I think about
>going full force and snarfing sendmail and rmail sources from uunet?

I am a satisfied smail3.1 customer - I feel no compunction to mess around
with sendmail.  Smail3.1 compiles right out of the box on XENIX/386 3.2.
A /usr/lib/mail/execmail replacement, written by Chip Salzenberg, is
included in the smail3.1 distribution.  My preference is to hack smail3.1
so it understands the execmail switches, and just install it under that
name.  Both these hacks should look familiar - we've done them for smail2.5
as well.

>This box will have only uucp connections for the near future, but might
>wind up with a thinwire on the back in a couple of years. Do I need to plan
>for this now or cross that bridge when I get there?

Smail2.5/deliver is usable with an external SMTP client - but it's not
pretty.  I've done it for an Excelan LAN Workplace system.  As soon as I
got my hands on an smail3.1 which linked with the Excelan socket library,
I immediately converted over to smail3.1.

When you do SMTP, I think you will want smail3.1.  Smail3.1 is a good
thing.  It's more work than smail2.5, but a lot less than sendmail.
However, there isn't anything you need today that smail2.5/deliver won't
do.  Knowing you will need to convert someday, though, is one point in
favor of doing it now.

On the other hand, it seems silly to put a lot of energy into preparing
for a possible event years down the road.  Hell, I feel satisfied if I
have a coherent computing plan in place which runs through next month,
let alone next year. :-)

-- 
Chip Rosenthal  512-482-8260  |  We was raising insurance premiums, ma.
Unicom Systems Development    |  We was spreading fear of arson.
<chip at chinacat.Unicom.COM>    |   - Michelle Shocked