Xenix mail system (sorry, I got a little long winded)

[Jim O'Connor]

In article <132500003 at cpe>, tif at cpe.UUCP writes:
> 
> I realize that there are only two of us Micnet fans out here, but I
> thought I'd mention that Micnet adds a couple of quirks to this:
> 
> There can be a machine whose only access to uucp is via Micnet.
> Therefore, the outgoing mail has to be sent down Micnet to get
> to the uucp machine where it is actually uux'ed.  Also, his
> incoming mail has to be sent down Micnet to his machine where
> it actually gets stuffed in his mailbox.

The first part of this (i.e. non-uucp micnet machine needing to send mail
to another micnet site or a remote uucp site) is most easily handled by using

#define RMAIL(flags,from,sys) "remote -u %s - %s rmail",from,sys /* */

instead of

#define RMAIL(flags,from,sys) "%s %s - %s!rmail",UUX,flags,sys /* */

in the "defs.h" file of smail2.5, which causes the micnet only machine to use
"remote" rather than "uux" for delivering non-local mail.  The only other
thing you need to do is to install a minimal "paths" file which only has
paths to your micnet neighbors and a "smart-host" entry to your machine that
has a more complete paths file and runs uucp.  The "smart-host" will then
take care of figuring out an address and delivering by uucp, if necessary.
This approach has (IMHO) the great advantage of only having to store and
maintain the paths file on the uucp machine.

Leave LMAIL defined as "execmail.x", which does a good job with local mail,
unless you want to know what's going on, in which case I recommend deliver.

The other part of the problem is a little more difficult (i.e. machine which
uses both uucp and micnet to deliver remote mail) since smail2.5 only
knows about one remote delivery command, i.e. whatever is defined by RMAIL.
The situation can be handled (without getting into the smail2.5 source) by
using

#define RMAIL(flags,from,sys) "delagent -f%s -un%s -s%s ",from,flags,sys  /* */

where delagent is a program I wrote which looks up the name "sys" in a file,
and if found, uses the command listed there as the delivery method.  E.g.
the entries

DEFAULT	/usr/bin/uux - -a%F -%U %S!rmail
uunet	/usr/bin/uux - -a%F -r  %S!rmail
fsc2086	/usr/bin/remote - -u %F %S rmail
fsc1086	/usr/bin/remote - -u %F %S rmail

would cause mail to "fsc2086" or "fsc1086" to delivered with "remote",
mail to "uunet" to be delivered via "uux" with the spool option on, and
mail to any other system (the DEFAULT entry) to be delivered via "uux"
with whatever options were specified as an argument to delagent.  The
%F, %S, and %U tokens are replaced by the strings supplied with the
-f, -s, and -u arguments.

This not only adds support for micnet, but adds extra flexibilty (at the
price of extra complexity) to the entire system.

> Both of us (remember us two Micnet fans) came up with a two part solution.
> (Honestly, I can't remember right now why I needed a two part solution.)
> One for a micnet only machine, and one for a micnet/uucp machine.

I admit, I'm the other micnet fan.  The reasoning behind a two part solution
is that the micnet/uucp solution is not very pretty, and there is no need to
burden the micnet only machine with it.  There is no reason, howvever, why
my "delagent" micnet/uucp setup could not be used on a micnet only machine
(provided the micnet only machine's paths file directs all uucp mail
addresses through a machine whcih can do uucp).

> It's not as elegant as I'd like but it works.  A single solution that
> is no less efficient than the original XENIX mail system would be best.

Smail3.  As long as you don't define efficiency in terms of the size of
the binary file, smail3 is definitely going to be (it is, here) the nicest
way to replace (read "enhance") the regular Xenix mailing system.
I have written the necessary entries to coax smail3 into delivery mail
via the "remote" command, so micnet support for it will be available.

In the meantime, though, my "delagent.c" addition to smail2.5 is available
(there's one more thing it needs to be able to do, but I can fix that 
before I send it out), for anyone wanting to set things up as I've described.
I'll admit, it's not pretty, but it has worked reliably for some time now.

--jim