From: kevin@cfctech.cfc.com (Kevin Darcy)
Newsgroups: comp.mail.uucp
Subject: Re: Internet <--> UUCP gateway
Date: 13 Aug 92 22:29:53 GMT
Organization: Chrysler Financial Corp., Southfield, MI

In article <1615bbINNbsn@grasp1.univ-lyon1.fr> Christophe.Wolfhugel@univ-lyon1.fr (Christophe Wolfhugel) writes:
>kevin@cfctech.cfc.com (Kevin Darcy) writes:
>> THE UUCP MAPS DO *NOT*, IN AND OF THEMSELVES, REFLECT OPTIMAL
>> MAIL PATHS OVER THE INTERNET!!!
>> [sample deleted, but it reflects really good the situation].
>
>But now that top-level domains seem to be more and more aliased in the
>UUCP maps, all those semi-bread-dead hosts (ie who are UUCP and
>use a smart host for the domain addresses they don't know about)
>will use the pathalias generated route for *any* destination if the
>admins do not themselves remove the pertinent information from the
>maps before running pathalias... (I sometimes get UUCP routed mail
>3 or 4 days after being sent, instead of the usual 1-2 hours when the
>sender used its smart host).
>
>This leads to the eternal question: should domain mail always
>be sent to an Internet smart host for relaying (in some rare situations
>it's cheaper and faster not to go on the Internet and back to
>UUCP). But, curiosity, are there lots of sites who are more than
>say 2 or 3 hops away from their Internet relay (see below)? Also lots of
>them just rely on 1 or 2 UUCP connections... I mean for a typical site
>(such as a XXX-only UUCP customer) there is no real interest
>to parse domain information from the maps as routing will always be
>better when there is no explicit route at the relay node.

Are you assuming that all MX forwarders keep up-to-date and accurate paths? 
That has not been my observation. At least if I process a full set of maps 
myself, I can be fairly certain that messages will get to their remote 
destinations EVENTUALLY. Without pathalias, it's just "punt and pray". 

Besides, what about unqualified addresses? My nearest relay doesn't run 
pathalias, so that'd be a GUARANTEED extra hop for it to forward to someone
else for pathalias address-resolution. If I can supply the bang-path myself, 
that extra hop is eliminated. Many relays will barf on unqualified addresses, 
too, or, even worse, will remedially tack on their OWN domain, resulting in 
mutant addresses ("cfctech.PoDunk.Edu", anyone?). UUCP sites downstream from 
such relays are practically FORCED to either run pathalias to resolve such 
addresses, or to "qualify" all UUCP addresses by tacking on the infamous, 
risky ".UUCP" (scary stuff).

>I would tend to suggest admins to describe well their neighborhood and
>prefer using a smart host for relaying domain adresses rather than
>information from the map (I do not agree with you Kevin, I consider
>MX routing as more reliable as UUCP maps just because lots of entries
>are not updated to accurate information).

It would be nice if some sort of utility was run periodically on Internet 
hosts which would double-check and/or supplement the UUCP map data with DNS-
derived information. If the map data were more complete and accurate, I 
believe pathalias would be a much more useful tool. Integrating the hosts.txt 
data with the UUCP maps (as we do here) results in dramatic path-
optimizations, but real live DNS data would be superior by an order of 
magnitude...

>
> [interesting table showing connectivity of hosts in the UUCP maps]
>
> [...]
>
>I considered as "internet sites" hosts (name = host.foo.bar) where
>the given FQDN has an A record in the DNS. This is an approximation but
>works pretty well. It would have been better to consider an Internet
>sites those having an MX pointing in their own domain or an A record.

Hmmmm... I don't agree that just because a host's MX points within its own 
domain that it should be considered an "Internet host" for these purposes.
What about the fairly-common case of a large UUCP network sitting behind a 
corporate/organizational gateway? The only _bona fide_ Internet host there
is the gateway, but I think with your criteria you'd end up counting all of
the UUCP hosts behind it too.

------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		  | Kevin Darcy, Unix Systems Administrator
...sharkey!cfctech!kevin 	  | Technical Services (CFC)
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence Ave, Center Line, MI 48015
------------------------------------------------------------------------------
Newsgroups: comp.mail.uucp