Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!mailrus!ncar!woods
From: woods@ncar.ucar.edu (Greg Woods)
Newsgroups: comp.mail.sendmail
Subject: Re: Overlaying smail and mx-sendmail?
Message-ID: <810@ncar.ucar.edu>
Date: 5 Oct 88 16:10:11 GMT
References: <8602@shamash.UUCP>
Reply-To: woods@handies.UCAR.EDU (Greg Woods)
Organization: Scientific Computing Division/NCAR, Boulder CO
Lines: 34

In article <8602@shamash.UUCP> jwabik@shamash.UUCP (Jeff Wabik) writes:
>
>	First address resolution happens via MX records;
>	Second address resolution happens via the pathalias database;
>	Third address resolution happens someplace else (like uunet 8^)
>

....to which several people responded with the answer that you can tack a dot
onto the end of the address, pass it through the resolver via the $[ $] 
canonical name lookup feature, and check for the presence or absence of the
dot afterwards to indicate resolver success or failure. When  Paul Vixie first
pointed this out to me, I was quite excited about the possibility of having
the best of both worlds. However, when I implemented it I discovered a very
serious problem with doing this. Namely, if your name server returns a
temporary failure, the message will bounce if the domain in the address is
not in the UUCP maps (which is happening more and more often these days as
Internet-connected sites begin depending more and more on the resolver
and less and less on static tables like UUCP maps, as well they should).
Yes, you can PARTIALLY alleviate this by repeating the resolve attempt
in case the name server times out, but if the timeout is due to some network
problem (such as the gateway between your local net and the rest of the 
Internet is down), then the second attempt will also time out, resulting
in addresses that work most of the time but sometimes bounce. Needless to
say, this can be very confusing for the users. This is not to say that you
absolutely shouldn't do this procedure, but you should be aware of this
behavior first. In a user community such as ours, that includes lots of users
that are barely computer literate, variable behavior of the mail system  will
cause too many headaches, so I have had to abandon the idea of implementing
this hack here. In an environment with fewer users, or where the average 
level of mail expertise among the users is higher than it is here, this might
work well.  But be aware of implementing a mail system that behaves differently
with the same address under different network states.

--Greg