Xref: utzoo comp.mail.sendmail:90 comp.dcom.lans:1831 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!ane From: ane@hal.UUCP (Aydin "Bif" Edguer) Newsgroups: comp.mail.sendmail,comp.dcom.lans Subject: Re: sendmail, the resolver and /etc/hosts Summary: I still disagree but... Message-ID: <286@hal.UUCP> Date: 21 Sep 88 15:43:36 GMT References: <713@ncar.ucar.edu> <1469@valhalla.ee.rochester.edu><1473@valhalla.ee.rochester.edu> <285@hal.UUCP> <729@ncar.ucar.edu> Reply-To: ane@hal.cwru.edu (Aydin "Bif" Edguer) Organization: Biometry Computing Facility Lines: 100 In<1473@valhalla.ee.rochester.edu>deke@ee.rochester.edu(Dikran Kassabian)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. In article <729@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > My users want mail to work. Okay. I want it to work to. I want the network to work also. I don't want the temporary fixes like checking /etc/hosts to last so long they become the defacto standard that must be lived with. Lets not go backwards. > They don't want to hear a lot of excuses about how > it's the other site's fault. Unfortunately, it is not an excuse. It is a fact. >Especially since the "simple" hosts-file-based mailer on the other >machine can get it there. That is the reality. Your "simple" name server based mailer can do the same thing. Here are some options available to you. 1) Ask why they are going to all the "trouble" of remembering addresses for their friends. Tell them about mail aliases. Add an alias for foo@[127.0.0.1] to their .mailrc. They'll thank you for making life easier and it will solve your problem. 2) Add the names to your name server. No code hacking is required. This is what Charles Hedrick suggested. In Charles Hedrick writes: >>>In /etc/named.boot, just include an extra file that defines local >>>additions. The only problem I can think of with this is that these >>>local definitions will take precedence, so you have to remember to >>>remove them once you no longer need them. >And besides, if they don't have a working name server, >how the hell do I find out who the "Zone Contact" Try using the whois(1) command. Or send mail to Postmaster@site.do.main. Or call the NIC. >Face it, folks, it ain't a perfect reality we live in. Agreed. I'm just not sure if I agree with your solutions to the imperfections. >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. If the hosts and domains are truly "REGISTERED" then the NIC knows them and you can find them using a nameserver. There are UNREGISTERED hosts or subdomains inside registered domains. In a case such as this, the REGISTERED domain is responsible for delivery to the unregistered subdomains. Tack on a "@registered.domain:" in front of "user@unregistered.do.main". >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. Not really. If no one ever complains then they won't have any reason to change. That is a reality. If your boss tells their boss that he cannot reach them because THEIR software is broken, maybe THEY will have to change. Add the alias to show how much you want things to work but point out how this is just a work around of THEIR PROBLEM. >In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >>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. I hate to make this seem like a "yes you are/no I'm not" match, but there are solutions USING THE NAMESERVER. The /etc/hosts file is necessary only when the nameserver is down . >>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. OKAY. It may not be the ONLY thing you should do. But it is ONE of the things you should do. I do not agree that you should be hacking on the name server or resolvers. Sendmail on the other hand could use some hacking. (WHEN WILL IDA FOR SENDMAIL 5.59 GET POSTED??!!!) If you want to do this hacking then I would suggest instead that is the nameserver cannot resolve a name it try for the domain above. Example: to: fred.cs.BlueU.Edu. fails try: cs.BlueU.Edu. if that fails try: BlueU.Edu. This should NEVER fail. If it does - contact the NIC immediately This should at least resolve to an MX. >>Any site in the NIC's host file is available to the nameserver. > WRONG. See first paragraph. As far as I know this is not wrong. Could you please point out a case where it is not true. Note I said the NIC's host file not your /etc/host file. >>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. You might have to remember 4 3-digit numbers instead of some.long.name.edu. But if you use aliases you don't have to remember either one. Look. If it works for you then go with it. I disagree with your solution but good luck anyway. Aydin Edguer