Xref: utzoo comp.mail.sendmail:98 comp.dcom.lans:1843 Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!oliveb!ames!ncar!woods From: woods@ncar.ucar.edu (Greg Woods) Newsgroups: comp.mail.sendmail,comp.dcom.lans Subject: Re: sendmail, the resolver and /etc/hosts Message-ID: <733@ncar.ucar.edu> Date: 21 Sep 88 16:56:53 GMT References: <713@ncar.ucar.edu> <1469@valhalla.ee.rochester.edu><1473@valhalla.ee.rochester.edu> <285@hal.UUCP> <729@ncar.ucar.edu> <286@hal.UUCP> Reply-To: woods@handies.UCAR.EDU (Greg Woods) Organization: Scientific Computing Division/NCAR, Boulder CO Lines: 62 In article <286@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: > > 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. You see it as a fact. People who have had mail bounce see it as an excuse. Unfortunately, it is THEY that I have to deal with on a day-to-day basis, not you. > >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. The problem with these options is that they cannot be implemented until mail has ALREADY BOUNCED. I want to do something that will get the mail there BEFORE it bounces. >If the hosts and domains are truly "REGISTERED" then the NIC knows them and >you can find them using a nameserver. Does this mean that the NIC's root servers provide host information for registered hosts in domains that do not yet have working name servers? That is what would be required for your statement to be correct. >Tack on a "@registered.domain:" in front of "user@unregistered.do.main". Again unacceptable, because it requires changes on the part of the users and because we don't find out that this is needed until after the mail bounces. >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. Agreed, execpt that my boss doesn't want to deal with this sort of thing. From his point of view, it is my job to do whatever is necessary to make it work. You are right that we ought to complain when these situations are detected, though. But my users aren't willing to sacrifice having their mail go through just to make a point. > >>Any site in the NIC's host file is available to the nameserver. >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. This statement, even if true, is irrelevant. It is the hosts in our file that the users want to send to. Most of them are not even aware of the distinction. All they know is that they can FTP there but they can't mail there, and in their eyes it is my fault, since I'm in charge of mail. In any case, these examples happen only once a month or so. One could argue that in that event it's no big deal. And depending on which user has his mail bounce, that might be true. But all it takes is one wrong bounce for the wrong user to make life difficult for me. The next time it happens, I'll post the example. I don't save them all, so I don't have any handy. >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. But you still have to have the mail bounce before you determine that this is needed. That is what I am trying to prevent in the first place. --Greg