🚀 go-pugleaf

Yep. There is such a creature in the NS3.0 sendmail. Not in
sendmail.cf . Just like I said, it's in sendmail.

And while NS3.0 is distinguishable from NS2.x in that it came with
pages of sendmail documentation, this documentation only mentions the
true effects of sendmail ruleset 'D', along with sendmail's dependence
on NetInfo, DNS, and NIS.

In my case, I have a gutted sendmail.cf which resolves EVERYTHING (at
least, everything that I've seen go through the site) to one of the
following mailers: local, prog, error, uucp, or local. I have no
definitions of or references to mailers 'ddn', 'ether', or 'etherl'.

Regardless, upon receiving mail from the 'uucp' mailer for local
delivery, sendmail queries DNS for something. The side effect is that
the mail delivery is delayed until my *SLIP* line comes up, a few
packets are exchanged with my slip nameserver (which used to have
nothing to do with mail delivery), and sendmail learns that the
nameserver is not going to help. Then, as expected, the mail arrives,
error-free. 

I hate having my SLIP line jumping up and down for no reason; my slip
host doesn't have a lot of dial-in lines and this wastes them. It
delays mail delivery. It ties up my outgoing line for the inactivity
timeout I set for SLIP. It's added complexity. What I want to know
is, what combination of NetInfo tweaking and sendmail.cf editing is
required to convince sendmail that it need not ask my SLIP host for
anything after receiving UUCP mail?

The quick answer I already have: delete /etc/resolv.conf . This leaves
me with no transparent access (ftp, telnet) to remote hosts; I have to
discover their IP addresses manually. I am open to other advice!

Users of sendmail 5.64 are really encouraged to share their war
stories. Users who, like me, are running SL/IP into a domain other
than their UUCP MX address domain, are also of interest....

--
Ward C. Travis		Pittsburgh PA	"The fact is the sweetest dream that
travis@transarc.com	(412) 338 4388	       labor knows."  - R. Frost