🚀 go-pugleaf

In article <810@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>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^)
>>

[Discussion about the $[ $] construct in sendmail]

>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).

If the name server is trying to resolve a name on behalf of sendmail, this
name (assuming it is not local; I would guess that this is not your problem)
should be fully-qualified with a domain.  If we go with this basic assumption,
then my response below should be valid.

>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. 

When the name server times out, and you send it to smail, smail should 
resolve it to a path regardless of whether or not it can find that particular
machine in the maps.  There are published gateways to .EDU, .COM, .GOV, etc.
If smail is configured right, it should try, for the host name
host.organization.top-level,

	1) host.organization.top-level
	2) a gateway to .organization.top-level
	3) a gateway to .top-level

Since the gateways exist to all the top-level domains (or they should), smail
should always resolve to some path. Whether this path also goes across the
Internet is a matter for the maps. (At least this is the way I remember smail
working -- Ed Rynes handles the smail part of our mail system; I handle
sendmail).  Also, the top-level domain gateways are assumed to handle such
mail correctly. 

Even if smail fails totally on resolution, you can have it set up to punt 
everything either back to sendmail (preserving the non-smail behavior) or 
to a smart host like uunet.

>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. 

True.  It does not affect our users as much as yours; ours seem to be a little
more computer literate (which makes my job a little easier than yours, I would
think).

>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.

Well, even a vanilla Internet mail system will behave differently under
different network states -- for example, a mail delivery system is supposed to
try all possible MX records for a given host, so if the primary MX forwarder
for a host is down, the mail will go to the next forwarder in the preference
list. (Sendmail does not do this -- at least, I've seen mail in the queue for
a site whose primary forwarder is unreachable, but whose secondary forwarders
are reachable (I have a program that lists all MX forwarders for a given host,
so it's easy to verify).)  But then, that's neither here nor there, as long 
as the mail gets delivered.  

What system do you use that guarantees delivery?  In my opinion, using 
sendmail and smail this way gives a higher probability of delivery than
just using one or the other.

>--Greg

Chet 
chet@cwjcc.CWRU.EDU


| Chet Ramey            chet@cwjcc.CWRU.EDU    chet@alpha.CES.CWRU.EDU
|
|		Just another jerk takin' pride in his work...