Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!tut.cis.ohio-state.edu!cis.ohio-state.edu!karl_kleinpaste From: karl_kleinpaste@cis.ohio-state.edu Newsgroups: comp.mail.uucp Subject: Re: Imminent death of UUCP Zone predicted Message-ID: Date: 12 Jul 90 21:07:47 GMT References: <269B82AE.415E@intercon.com> <_2M4591@xds13.ferranti.com> Sender: news@tut.cis.ohio-state.edu Organization: Ohio State Computer Science Lines: 93 peter@ficc.ferranti.com writes: Do you have any UUCP neighbors? Are they in the maps? If so, every site running "pathalias" is going to want to tunnel UUCP paths through the internet to you. UUCP-only sites don't have the ability to make use of MX records. T'ain't necessarily so. Any of my UUCP neighbors is free to run, e.g., smail 2.5 as a backend with a one-line /usr/lib/uucp/paths file: smart-host osu-cis!%s which is to say that everything they send goes through me. I do MX RRs appropriately. By extension, they are using MX RRs. If they have other connections (most of them have at least a couple, naturally), they can add those as well so they don't bother going through osu-cis when it's just some other entity around town. Thus, someone at such a UUCP neighbor can address peter@ficc.ferranti.com which their local smail will deliver via uux - osu-cis!rmail (ficc.ferranti.com!peter) and It Just Works. Which, by the way, can produce stunningly poor results... for example, going by the DNS mail to ferranti.com will be sent via uunet. So I get mail sent from Rice University, not 20 miles (and 2 hops) away, sent via Virginia, which I guess is about 2000 miles away. Any reasonable mail administration is going to deal with local peculiarities. If what you say is true, it would seem that Rice hasn't done so, but they would be well advised to take a look at local improvements they could make for the sake of nearby people such as yourself. E.g., I speak UUCP direct to Pyramid much as Rice should speak UUCP direct to Ferranti. My local peculiarities are codified thus... sendmail.cf: [[ Define a few classes: ]] ## CONFIG HERE ## The following classes are sets of entities within top-level domains ## to which we speak UUCP directly. These are not hosts within your ## domain, but whole domains external to yourself. ## Legend: C == com; O == org; E == edu; N == net. CCacadch compuserve copi equi imp johngalt morningstar netsys pinnacle protec pyramid resource stargate COhdl sub CNgeo sub [[ S0 delivery based on those classes. ]] R$+<@$*$=C.com> $#smail$@$2$3.com$:$1 Generic commercial R$+<@$*$=O.org> $#smail$@$2$3.org$:$1 Generic org R$+<@$*$=N.net> $#smail$@$2$3.net$:$1 Generic network /usr/lib/uucp/paths sample entries: acadch.com acadch!%s compuserve.com compuserve!%s copi.com copibob!%s equi.com equicom!%s hdl.org cmhhdl!%s imp.com acadch!imp.com!%s johngalt.com jgalt!%s morningstar.com mstar!%s netsys.com netsys!%s pinnacle.com pinnacl!%s protec.com protec!%s pyramid.com pyramid!%s resource.com resource!%s stargate.com stargate!%s sub.net watzman!%s sub.org watzman!%s When I write mail to csg@pyramid.com, it delivers via UUCP -- I have made myself into what amounts to an MX host for pyramid.com, though no nameserver knows it. All I really need at this point is a patch to sendmail which would allow me to create multi-token class elements so that I can create a single class to be dealt with for smail delivery, e.g.: CMacadch.com compuserve.com copi.com equi.com imp.com johngalt.com morningstar.com netsys.com pinnacle.com protec.com pyramid.com resource.com stargate.com hdl.org sub.org geo.net sub.net Then all my $#smail resolutions (there are actually more than the example 3 I showed; I am MX for several sites in .us, and each gets [mumble] its own $#smail rule) would reduce to a single one. Of course, given the length of that class definition, I'd probably want to resort to defining it in a file and reading it in via FM instead of CM. I understand that Sun's sendmail allows multi-token class elements, but I wouldn't know personally, as I run almost-raw 5.61. --karl