2nd try: Port of Sendmail: response and comments

[Jim Jagielski]

Please excuse the length of this posting, but this is a response to
an e-mail message that I got and could not reply to.

This may also be of interest to the net:...

>From claris!wet!epsilon at ames.arc.nasa.gov Thu Jul 19 08:21 EDT 1990
>Received: From [128.102.18.3] By jagmac2.gsfc.nasa.gov Using SMTP
>	  (5.64/jj-1.6) id AA01096; Thu, 19 Jul 90 08:21:05 -0400
>From: claris!wet!epsilon at ames.arc.nasa.gov
>Received: by ames.arc.nasa.gov (5.64/1.2); Thu, 19 Jul 90 05:20:56 -0700
>Received: by claris.com (4.1/SMI-3.2)
>	id AA10137; Thu, 19 Jul 90 05:14:44 PDT
>Date: Thu, 19 Jul 90 05:14:41 PDT
>Message-Id: <9007191214.AA10137 at claris.com>
>Apparently-To: jim at jagmac2.gsfc.nasa.gov
>Status: RO
>
>In article <2826 at dftsrv.gsfc.nasa.gov> you write:
>>Recompiling the source with NAMED_BIND undefined makes everything work!
>>Evidently, with this symbol defined, sendmail attempts to interface with
>>the nameserver directly, using MX records and resolver routines. Obviously,
>>if you don't have named running you don't need this.
>
>You MUST use MX records if you're Internet-connected.  You don't
>need named running if /etc/resolv.conf points somewhere reasonable.
>In fact, I seriously doubt I'd ever run named on an A/UX machine.
>
>>                                                     This trick is that
>>even WITH named running, you also don't need this, since the gethostent()
>>routines (such as gethostbyname, etc...) will do the nameserver resolving
>>for you!
>
>WRONG.  They query A records, not MX records.  The only sites
>that can use this version are those running TCP/IP on a
>non-Internet-connected network on which every host handles its
>own mail.  (e.g. this does not work if there are diskless
>workstations, or firewall gateways, etc.)  Most isolated IP
>networks run with name service unless they're very small.
>
>					-=EPS=-
>

My response is that I AM Internet connected, and compiling with
NAMED_BIND undefined results in Sendmail working but compiling
with NAMED_BIND defined results in Sendmail ONLY working if the
host address is COMPLETELY spelled out (i.e. bar.gsfc.nasa.gov
rather than just bar). Otherwise, mail is bounced with the 
"unknown host" error. It also is no help to comment out the
RES_DEFNAMES and RES_DNSRCH option setting... although it
would result in the domain being attached to all single token
hosts, sendmail would STILL refuse to recognize aliases in
/etc/hosts either with or without named running.

As far as the comment that the only sites who could use this version
are those "running TCP/IP on a non-Internet-connected network", well,
all I can do is repeat that I AM Internet connected. I do, however,
handle by own mail and do require a gateway to get out of gsfc.nasa.gov.
named is running...

It does not good to say that "You MUST use MX records" if when
sendmail is compiled to do so, it refuses to do what nameserving
is supposed to do and when NOT using MX records (i.e. no getmxrr())
then it DOES work. If you have any idea WHY it works out this way,
let me know, but just sprouting dogma is no help. Comments are requested
to help, not to inflate one's own ego on how much more you know about some-
thing than someone else... have you looked at the code? Have you tried
compiling and running it both ways? Do you have an CONSTRUCTIVE comments?
In anycase, the focal point seems to be in the use of MX records. As far
as I understand them (and I DON'T claim to be an expert) is that they are
used to specify a machine that knows how to deliver mail to another
machine that is not directly connected to the net... however, my experience
has been that when using MX records, addresses are not resolved correctly
unless totally spelled out. The version of sendmail that came with
A/UX 1.1 (5.59) wasn't like that...

Until then, I'll keep on distributing the port as is. People
can compiled both with or without NAMED_BIND defined, but I
would appreciate feedback on the difference encountered both ways.

--
=======================================================================
#include <std/disclaimer.h>
                                 =:^)
           Jim Jagielski                    NASA/GSFC, Code 711.1
     jim at jagmac2.gsfc.nasa.gov               Greenbelt, MD 20771

"Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach
 the very, very top, and then it tends to slope away rather sharply."