Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

/usr/lib/sendmail.smtp

3 views
Skip to first unread message

David Elliott

unread,
Nov 9, 1989, 12:27:24 AM11/9/89
to
In article <13...@boulder.Colorado.EDU> hart...@boulder.Colorado.EDU (George Hartzell) writes:
>In article <20...@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
d...@sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"You can lead a robot to water, but you can not make him compute."

Roger B.A. Klorese

unread,
Nov 9, 1989, 1:38:43 AM11/9/89
to
In article <13...@boulder.Colorado.EDU> hart...@boulder.Colorado.EDU (George Hartzell) writes:
>In article <20...@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's not being used by my /usr/lib/sendmail.cf, or so the daily run
>>summary mailed to root says so.

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

The default MIPS sendmail.cf uses the file as a list of hosts to which it
uses SMTP as a transfer agent. One of the /usr/adm/periodic/daily scripts
sed's /etc/hosts (which, of course, doesn't work if you use BIND) and
generates /usr/lib/sendmail.smtp.
--
ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939
928 E. Arques Ave. Sunnyvale, CA 94086 rog...@mips.COM
{ames,decwrl,pyramid}!mips!rogerk
"I want to live where it's always Saturday." -- Guadalcanal Diary

Brain in Neutral

unread,
Nov 9, 1989, 9:40:39 AM11/9/89
to
From article <1989Nov9.0...@sony.com>, by d...@sony.com (David Elliott):

> In article <13...@boulder.Colorado.EDU> hart...@boulder.Colorado.EDU (George Hartzell) writes:
>>In article <20...@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...)
>
> I believe that all of this is documented in the sendmail installation
> guide, and if it isn't, someone at MIPS should document it.

It's not in the sendmail inst. guide, I don't think. It was documented
in the UMIPS 3.10 stuff, but I haven't come across it in the RISC/os 4
stuff yet (though perhaps it's in there).

The purpose of sendmail.smtp is to make you realize that you should throw
away as much of the MIPS mail stuff as you can and replace it all with BSD
sendmail/Mail/mail. It is possible to get rid of everything except
/bin/mail. Perhaps even that, but I haven't figured out how.

This business of munging through /etc/hosts nightly is a hack, too. There's
a cron script that puts a link in /usr/hosts for *EVERY SINGLE NAME* in
/etc/hosts, so if your host file is any size at all (mine is, even though I
use BIND) you end up with this huge directory full of links you'll never
use more than a fraction of a percent of.

The astute reader will have guessed by now that although I like my MIPS,
mail support is the single thing I have experienced the most frustration
with.

Paul DuBois
dub...@primate.wisc.edu

David Elliott

unread,
Nov 9, 1989, 10:55:27 AM11/9/89
to
In article <10...@uakari.primate.wisc.edu> b...@primate.wisc.edu writes:
>This business of munging through /etc/hosts nightly is a hack, too. There's
>a cron script that puts a link in /usr/hosts for *EVERY SINGLE NAME* in
>/etc/hosts, so if your host file is any size at all (mine is, even though I
>use BIND) you end up with this huge directory full of links you'll never
>use more than a fraction of a percent of.

Well, you can't blame MIPS for providing this. Take a look on any BSD
system and you'll find /usr/hosts/MAKEHOSTS, which does basically the
same thing. On unmodified systems, it will actually create entries
for ucbarpa and ucbvax.

MIPS simply provides the service so that when you change your hosts
file, /usr/hosts gets updated. If you don't want the service, you
can easily shut it off:

touch /usr/adm/periodic/daily/10.makehosts.system.stop

In fact, the whole point of the periodic stuff is that a set of
services can be provided to help the general user ("Why doesn't
/usr/hosts get fixed when I add new hosts?"), but can be shut off
without causing problems when doing system updates (how many
systems require you to scavenge through the system, backing up
files you changed, just to do an update?).

Cliff Marcellus

unread,
Nov 14, 1989, 10:35:16 AM11/14/89
to
In article <13...@boulder.Colorado.EDU>, hart...@boulder.Colorado.EDU (George Hartzell) writes:

[ trimmed ]

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

> explaining what it is used for. When I started using my own (actually
> the standard CU-Boulder) sendmail.cf everything broke. The problem
> seemed to be related the fact that /bin/mail under RISCos is a very
> systemV version, while most of the machines around here have a
> /bin/mail that is berkeley-V7 derived (based on bounced messages that
> ended up at postmaster about "arguments before users" or something).
> I suspect that MIPS' sendmail.cf is designed to call their /bin/mail
> properly while ours is designed to call our /bin/mail properly.
>
I'm glad to see I'm not the only one that wonders what sendmail.smtp is
for...

Anyway, onward -- I to switched over to the UofC standard. Here, we
have a "sendmail configuration program" that a bunch of us adopted a
few years back which, by answering a few simple questions, will go
(re)configure sendmail for you... saved all of us having to maintain it,
made sure we were all consistant (yeah, right!), and (BIG PLUS) saves
new sys.admin. types here from the horrors of sendmail... Well, it
worked fine on all my machines EXCEPT the MIPS. The fixed were :
to get mail OUT of the MIPS (thanks to R. LaT., MIPS/Sunnayvale)
create the file /etc/sendmail.ok. (This is actually in the /bin/mail
manual page -- it should also be with the sendmail manual page)
To get incoming mail, I needed to change my sendmail.cf so that the
local mailer ("Mlocal") such that the argument vector called "rmail"
instead of "mail" (ie. "A=/bin/rmail"). This information in the
4.3BSD manual page mail -- not in the MIPS documentation. Something
aloing the lines that "rmail" is designed for use with UUCP and SENDMAIL
for security reasons. I suspect that because my pure BSD machines use
"A=/bin/mail", that the BSD version of /bin/mail looks at the mail address
and then calls "rmail" or "mail" as appropriate, whereas the Sys V (a.k.a
RISC/os) version does not.... you may wish to try this.

Cliff
--
Cliff Marcellus UUCP : {any backbone}!calgary!ssg-vax-a!cliff
Dept of Physics and Astronomy DOMAIN : cl...@ssg-vax-a.phys.UCalgary.CA
The University of Calgary SPAN : CANCAL::CLIFF
OPINIONS WITHIN ARE MY OWN AND DO NOT REFLECT THOSE OF THE UNIVERSITY OF CALGARY

0 new messages