🚀 go-pugleaf

In article <jpc.713145891@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>I'm using sendmail+IDA 1.4.4.1.  One day I tried linking it with Bill
>Wisner's resolv+-2.1 resolver.  The /etc/host.conf file looked like
>this:
>
>nis
>bind
>
>which should mean that ordinary DNS lookups go to NIS first, followed
>by BIND.  After I did this, I discovered that some of outgoing mail was
>not being delivered because MX mail forwarding wasn't happening.  For
>example, when I tried to send a message to abcd@mips9.msfc.nasa.gov,
>sendmail kept trying to get mips9 to accept a mail connection; this
>doesn't work.  Using Sun's resolver, the message would get sent to
>fedex.msfc.nasa.gov, which is MX host returned by DNS; this is the
>correct action.

  I'm not familiar with 'resolv+' so my comments are partly speculation.
My speculation is based on experience on other systems where the
search order (between NIS, /etc/hosts, DNS) can be configured.  Because
of the problems I have seen, I have claimed that configuring the
search order in this way is wrong.  There must be a way of configuring
on a software package basis.  For telnet/ftp etc, searching NIS first
can make considerable sense, but for sendmail it tends to cause problems.

  Here is my speculative explanation:

  Host lookups are used for two purposes.  They are used for establishing
connections, but sendmail also uses them to ensure that a hostname is
in canonical form.  The $[ hostname $] operation canonicalizes.  Now
with DNS the canonicalization usually works quite well, due to the strict
data format requirements.  With NIS or /etc/hosts lookup the
canonicalization is at the whim of the maintainer of the data.

  Let me illustrate with your example, and assume an /etc/hosts lookup.

  If the entry is

128.158.1.109		mips9.msfc.nasa.gov	mips9

  then

     $[ mips9 $]		returns		mips9.msfc.nasa.gov
     $[ mips9.msfc.nasa.gov $]	returns		mips9.msfc.nasa.gov

  However, if the entry is

128.158.1.109		mips9		mips9.msfc.nasa.gov

  then

     $[ mips9 $]		returns		mips9
     $[ mips9.msfc.nasa.gov $]	returns		mips9


  I suspect the second of these is what is happening, and this is the
main cause of your problem.  By the time a connection is to be made,
sendmail is looking up just 'mips9'.  At this time it is expecting a
fully qualified hostname, so does not append the local domain.  The
MX lookup fails in these circumstances.  As a result it drops back
to an A-record lookup, finds it in your hosts (or NIS) map, and
attempts a direct connection.