Using Smail under Xenix.

[Chip Salzenberg]

According to wayne at etxaz.UUCP (Wayne Johnson):
>To get smail to work you need to understand that the Xenix mail system
>is not a single program but a chain of programs.

[Good pocket description of Xenix mail system deleted.]

>To get proper headers smail should send its output to /usr/lib/mail/execmail.
>We do it by linking /usr/lib/mail/execmail to /bin/lmail and changeing
>the folowing line in smail's defs.h file:
>
>#define LMAIL(frm,sys)	"/bin/lmail -f %s",frm /* SV local delivery agent */

This approach leaves /usr/bin/mail disconnected from Smail.  Although I
seldom use /usr/bin/mail, many system utilities do so; and it's nice to
apply Smail aliasing to *all* mail. 

My patches for Smail 2.5 under Xenix let /usr/bin/mail work with Smail. 
They involve replacing /usr/lib/mail/execmail with a tiny program that
just runs Smail, and then using the /usr/bin/mail option "set execmail"
so that /usr/bin/mail always uses execmail, even for local mail.  Those
patches were posted in comp.sources.misc some time ago; check your
archives or send me mail if you're interested.  (If you can. :-])

>We also found it necessary to run smail setgid bin and make the spool
>directory writable by group bin or mail just dissapears.

Now this is just plain wrong.  Smail 2.5 doesn't write into any mail
directories, so it doesn't need setuid or setgid permissions.  Something
else is wrong here besides the permissions on /usr/spool/mail.

>We are using Elm 2.1 now and are quite happy.  Even the filter program
>works with a few modifications.

But for real flexibility, you should use "deliver" (plug, plug).
-- 
Chip Salzenberg             <chip at ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	   Beware of programmers carrying screwdrivers.