Xref: utzoo comp.mail.sendmail:88 comp.dcom.lans:1828 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!woods From: woods@ncar.ucar.edu (Greg Woods) Newsgroups: comp.mail.sendmail,comp.dcom.lans Subject: Re: sendmail, the resolver and /etc/hosts Summary: why I want to do this; I have good reasons Message-ID: <729@ncar.ucar.edu> Date: 21 Sep 88 06:46:11 GMT References: <713@ncar.ucar.edu> <1469@valhalla.ee.rochester.edu><1473@valhalla.ee.rochester.edu> <285@hal.UUCP> Reply-To: woods@handies.UCAR.EDU (Greg Woods) Organization: Scientific Computing Division/NCAR, Boulder CO Lines: 69 In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >>Many times a user on one of my systems begins a correspondance with someone >>at a site we previously never mailed to. The user at the remote site >>gives our local user an address that he "knows" is good, 'cause its in the >>hosts table. Our user sends mail to that address and it bounces... there >>isn't a nameserver to answer for that host in that domain. This is *precisely* the situation I am running into, and all too often the "user" in question is our Division Director, or some other bigwig here. >In that case contact the Zone Contact for this domain - It is their >responsibility to maintain their files, not yours. That isn't a good answer, although a lot of people seem to think it is, based on the mail I've gotten. My users want mail to work. They don't want to hear a lot of excuses about how it's the other site's fault. Especially since the "simple" hosts-file-based mailer on the other machine can get it there. That is the reality. It's all well and good for us hackers to know that it is, in fact, the other site's fault. We all know they've had plenty of time to convert. But my users don't *care* about that; they really don't! And besides, if they don't have a working name server, how the hell do I find out who the "Zone Contact" is? Face it, folks, it ain't a perfect reality we live in. There are hosts and domains out there that were registered before the days of name servers, that are legitimately registered, and that my users want to send to. My bosses want to send there. Therefore, I have to support it. That's it. Period. What those other sites *should* be doing is TOTALLY IRRELEVANT to the reality I (and apparently some others too) am faced with. >If you are running the nameserver then the /etc/hosts file is necessary >only during those times the nameserver is down, such as in standalone >mode or during testing. Untrue, see above. >>What is the "right thing" to do here? >The "right thing" would be to contact the other site. That doesn't get mail working. That is the "right thing" in one sense, but in reality it does NOTHING to solve my problem. Nor does it deal with the "it works on the other machine" hassles. Nor does it help me justify the added effort to keep up the name server, resolver, and hacked versions of sendmail and other applications. >Any site in the NIC's host file is available to the nameserver. WRONG. See first paragraph. >My suggestion AS A TEMPORARY FIX would be just to use the internet number >for the site rather than the site name. Not a good temporary fix from the user's point of view. Fine for us, but the users don't want to deal with this nonsense. All they understand is that the information is available and my mailer can't find it. Thanks to those who sent me patches. None of them were for the exact software I have, so I haven't been able to make any of them work yet. In BIND 4.7.2, there were 4 patches to gethostnamaddr.c. With the BIND 4.8 code, none of them would apply. I can only find two of the places in the code where they should go, and even after putting them in by hand, neither nslookup nor sendmail can resolve host names I placed in /etc/hosts that aren't available through the name servers. Running nslookup under dbx(1) shows that gethostbyname() is never called unless a server is specified on the command line, so it never gets to the patched part of the code. I hope to have more luck with the 5.59 sendmail patch I got, although what I have is hacked 5.58, so I'm expecting more trouble. --Greg