Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!mips!sony.com!dce
From: dce@sony.com (David Elliott)
Newsgroups: comp.sys.mips
Subject: Re: /usr/lib/sendmail.smtp
Message-ID: <1989Nov9.052724.21405@sony.com>
Date: 9 Nov 89 05:27:24 GMT
References: <2042@cs-spool.calgary.UUCP> <13666@boulder.Colorado.EDU>
Reply-To: dce@icky.Sony.COM (David Elliott)
Distribution: na
Organization: Sony Microsystems Corp.
Lines: 37

In article <13666@boulder.Colorado.EDU> hartzell@boulder.Colorado.EDU (George Hartzell) writes:
>In article <2042@cs-spool.calgary.UUCP>, cliff@.UCalgary writes:
>>Does anyone know what /usr/lib/sendmail.smtp is used for?  (I'm unable
>>to find why in the RISC/os 4.10 docs, perhaps I missed it...)

>It is used in the MIPS sendmail.cf, though the don't have a comment
>explaining what it is used for.

I believe it's explained in the system administration documentation
describing how to set up sendmail.

/usr/lib/sendmail.smtp came about because the sendmail.cf I used as
a model for the templates had a list of local hostnames (this was
before %y looked at /etc/hosts or YP), and I didn't think it was
reasonable to force people to modify sendmail.cf every time they
added a new host.

Thus, sendmail.smtp is built from /etc/hosts each night out of the
/usr/adm/periodic/daily scripts, which also restarts sendmail when
the configuration changes.  I never considered this a clean solution,
but it did the trick.

Now, as far as George's problem with /bin/mail, I believe it stems from
the fact that System V mail already had a -r flag.  Bill Earl may
remember this better than I, but I think I modified /bin/mail so that
it dealt with -r specially when mail was called as rmail.  Thus, in
your sendmail.cf, you have to modify the "local" mail specification to
say A=rmail instead of A=mail.  This solution works on all systems
where /bin/mail can be executed as rmail.

I believe that all of this is documented in the sendmail installation
guide, and if it isn't, someone at MIPS should document it.
-- 
David Elliott
dce@sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"You can lead a robot to water, but you can not make him compute."