Complete mail subsystem for Xenix

[Greg A. Woods]

In article <1731 at chinacat.Unicom.COM> chip at chinacat.Unicom.COM (Chip Rosenthal) writes:
> 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.

Yes, you do want some original "/bin/mail" support.  BTW, did SCO
really move /bin/mail to /usr/bin?  What sillyness!  No, I actually
thought SCO removed /bin/mail entirely, and renamed /usr/bin/{mailx,Mail}
to /usr/bin/mail.

Anyway, smail *does* provide this functionality quite well.  We've
been using it for a long time now on various types of systems.

The svbinmail trick, which can be used on XENIX as well, is the
secret.  If /usr/bin/mail was renamed mailx, and if svbinmail (linked
to /bin/mail) exec()'ed either smail (for sending), or your MUA (for
reading), depending upon the use of arguments.

> 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:".

The /bin/mail on most non-XENIX systems doesn't have '-s subject'
anyway, and /bin/mail on SysV does *not* treat the entire input as the
body either.  /bin/mail on SysV assumes the first non-conforming, or
blank, line will constitute the end of the header, and the start of
the body (though the SVID does not document this behavior).

As for the embedded header problem, you can't have it both ways.  On
SysV this cannot be fixed without breaking /usr/bin/mailx, which
relies upon this feature.  The real bug is in cron, which could use
mailx, or send a properly formatted message to mail.  I usually fix
all scripts that use mail to do something like the following:

	(
		echo "Subject: $0: {failure,notice}"
		echo
		cat /tmp/$$stderr
	) | mail $admin

>[.... many lines of complication deleted! ....]
> 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.

Whew.  What about "set sendmail=/bin/smail"?  Or is SCO's
/usr/bin/mail missing this SVID defined feature?  I can't remember.

> 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. [....]

K.I.S.S.  Need I say more?

Let us look at this from the point of view of simple functionality:

1. a simple MTA for aliasing and routing mail.

	- smail-2.5 can do this quite well

2. simple mail user agent for sending mail (i.e. /bin/mail in SysV).

	- use svbinmail (part of smail-2.5) installed as /bin/mail to
	  decide if the caller is sending, or reading, mail, and exec
	  either smail or fancy MUA (may require changes to the
	  decision-making logic for fancy MUA's).

3. local delivery agent (LDA) for sending to files and pipes (called
   upon by smail only).

	- lmail-2.6 does this quite well
	- deliver may work fine too, but I've never tried it.

4. your favorite MUA (mine is mush) (uses smail only for the MTA).

	- or rename /usr/bin/mail to mailx and stick with it, if the
	  "set sendmail=/bin/mail" feature works.

It has been a very long time since I had to set up such a system on
XENIX, so don't believe everything I say!  :-)

The biggest thing to worry about is compatability of mailbox locking
schemes.  The MUA and LDA must respect each others locks, or otherwise
you'll lose mail!
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL