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