home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.mail.uucp
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!news.utdallas.edu!corpgate!bnrgate!bwdls61!bwdlh118!clewis
- From: clewis@ferret.ocunix.on.ca (Chris Lewis)
- Subject: Re: Internet <--> UUCP gateway
- Message-ID: <1992Aug14.145727.12384@bwdls61.bnr.ca>
- Originator: clewis@bwdlh118
- Sender: usenet@bwdls61.bnr.ca (Use Net)
- Nntp-Posting-Host: bwdlh118
- Organization: Que?
- References: <1992Aug8.014028.16205@cfctech.cfc.com> <1615bbINNbsn@grasp1.univ-lyon1.fr> <1992Aug13.222953.24812@cfctech.cfc.com>
- Date: Fri, 14 Aug 1992 14:57:27 GMT
- Lines: 126
-
- 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.
-