From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Subject: Re: Internet <--> UUCP gateway
Originator: clewis@bwdlh118
Organization: Que?
Date: Fri, 14 Aug 1992 14:57:27 GMT

In article <1992Aug13.222953.24812@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes:
|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!!!

I'd state it a little stronger - the UUCP maps *seldom* reflect optimal
paths over the internet.

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

I was under the impression that the top level domains *shouldn't* be
aliased in the maps, except in d.Top.

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

Actually many sites have no formal internet relay at all.

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

The heuristics can be reasonably fairly smart, without having to spend
too much time hand tuning.

Case in point: my machine ferret.ocunix.on.ca.

[smail 2.5, UUCP only]

I've set my system up to run only with the Canadian maps instead of the
full maps for two reasons:

	1) it's a little hard on my machine to run pathalias on that much
	   data, especially since the likelyhood of actually wanting to
	   reach any of the 10000+ hosts that far away are lower.
	   Especially since my smart-host is more likely to be able
	   to "route smart" than me.
	2) the risks of being toasted by goofy map entries is much higher.

This is being done automatically by my unpackmaps 4.0 - it has a list of
which maps I wish to discard.

Obviously, I use my smart-host as a forwarder to hosts not listed in the paths
file.  In my case, since I'm a uunet.ca subscriber, they are my smart-host.

Secondly, unpackmaps 4.0 has a new feature that allows you to strip domain
names and translate them into shorter paths.  You supply a route to an
internet site ("domain-forwarder"), and unpackmaps will replace all paths to
sites that are *longer* than the supplied domain-forwarder route with a simple
punt to the domain forwarder.  Again, I've chosen uunet.ca as my domain
forwarder.

[While it would have been better to short-circuit domain routes that "cost"
more than the domain-forwarder's, you can't do this without hacking pathalias.]

Other people who are using unpackmaps with mixed UUCP and SMTP connections
apply filters to strip out domainized names completely.

While uunet.ca is obviously going to take pains to keep it's database up to
date, chosing any "reasonable" well-run internet site works just as well.

In fact, if you're running with a local subset of the maps, it's frequently
a good idea to choose your smart-host as outside of your map area
(because if you don't know it, you might as well pump it out to somebody
outside your area to find), while keeping your domain-forwarder local.

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

It's my experience that "punt and pray" works more reliably than full
maps.  Because the maps seldom list the real internet links, and uunet.ca's
mailer is a little less likely to be broken than mine ;-)

Using the full pathalias database for everything leaves you at the mercy
of some nimnut who hasn't updated their map in years, or advertises
nonexistant links.  I have a lot more trouble with the latter than with my
forwarder not being able to figure it out.

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

If you run with your state (provincial) or regional maps, this extra hop
for smart-hosting is irrelevant - it's gotta go a long way anyways.

|Many relays will barf on unqualified addresses, 

Mark 'em dead.  You have to choose your relay intelligently - ie: one that knows
how to handle them.

|too, or, even worse, will remedially tack on their OWN domain, resulting in 
|mutant addresses ("cfctech.PoDunk.Edu", anyone?).

Mark 'em dead.  I have over a dozen *broken* "major hub" sites marked dead in
my local overrides.  They mangle addresses even when the incoming From: line
is *already* domainized.

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

You do your damndest to not be below one of these sites.

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

I agree too.