Xref: utzoo comp.mail.sendmail:91 comp.dcom.lans:1835
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
Message-ID: <287@hal.UUCP>
Date: 21 Sep 88 21:41: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> <733@ncar.ucar.edu>
Reply-To: ane@hal.cwru.edu (Aydin "Bif" Edguer)
Organization: Biometry Computing Facility
Lines: 78

In article <733@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>In article <286@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes:
>> In article <729@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>> >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.
Okay.
	Point #1: You should be running the nameserver (at least caching)
	          on all your machines.
	Point #2: Your C library functions should be compiled to use the
		  nameserver on all your machines.
	Point #3: Your networking software (ftp, telnet, sendmail, etc)
		  should all be compiled using the libraries that use
		  the nameserver on all your machines.
Why?
	This leads to consistent behavior.
	This is easier to maintain.
	No more...
 >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.
 [note: this should never happen on your machine since ftp uses
  the nameserver too!  Unless your running with improperly compiled
  programs.]
Well, that is just the ideal case.  As you have pointed out the world
is not ideal.  You may not have that much control over the environment.
I've run this issue into the ground by now but I would also like to help you.
Here is a possible solution to your problem.
Problem statement:
	1) You want to find problems with incompatibilities
	   between an /etc/hosts and the nameserver.
	2) You want to find the problems before a user tells you
	   that their mail is not going through.
Solution statement:
	1) Write a shell program which will
		a) go through a file in /etc/hosts format and extract
		   the fully qualified domain names.
		b) take each name found and use nsquery (distributed with
		   named) to look up each name in the nameserver.
		c) Examine the output of nsquery for failure and notify
		   you.
		d) EXTRA CREDIT: Make it add an entry to your local mod
		   file for the nameserver.
	2) Automate the process of getting the /etc/hosts from offending
	   machines by using batched ftp (there have been a couple posted 
	   to the net.)
	3) You should only need to do this ONCE.  After that time people
	   should either 
		a) not be modifying their /etc/hosts files.
		b) make them modify the local mod file for the nameserver
		   at the same time they are modifiying the /etc/hosts
		   file on their machines.
		c) notify you whenever they make a change to their
		   /etc/hosts file.
The second possible solution I posted last time -
	Hack on sendmail to look up parent domains and forward the mail
	to the parent domain (allowing the authoritative server to figure
	out the correct address.)  This should always work unless the
	network goes down (in which case the mail won't be delivered
	anyway).  The only case this will fail is when a domain has not
	been registered, in which case IT SHOULD NOT BE USED.  The
	NIC can get very ornery when it happens.  The offending site
	can lose ALL Internet priviledges.

 > 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.
I don't suggest sacrificing their mail (not even to the great god Murphy)
but instead point out that you DO make their mail work.  You should point
out that a bounced message will only be delayed a short while, till resent
with more information, not lost.  After all we're talking Internet not UUCP.

Aydin Edguer