Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!lee From: lee@unmvax.unm.edu (Lee Ward) Newsgroups: news.config Subject: Re: Unregistered-but-referenced sites (was Re: deleted UUCP sites) Message-ID: <599@unmvax.unm.edu> Date: 4 Jan 90 00:12:23 GMT References: <4195@convex.UUCP> <30273@mcdchg.chg.mcd.mot.com> <43496@improper.coherent.com> <1990Jan3.164811.5457@ddsw1.MCS.COM> Reply-To: lee@unmvax.cs.unm.edu (Lee Ward) Distribution: news Organization: University of New Mexico at Albuquerque Lines: 151 In article <1990Jan3.164811.5457@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >In article <43496@improper.coherent.com> dplatt@coherent.com (Dave Platt) writes: >>In article <30273@mcdchg.chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes: . . . >> >>So... consider what happens if some new site comes on line, and chooses >>a name for itself... say, "ilmss". That name isn't reserved, it's up >>for grabs, and they take it. They publish a map-file, reserving this >>name for themselves. > >The new "ilmss", however, can't tell that their choice of name is ALREADY >TAKEN, since you would have mcdchg delete the declaration from their map >entry! > Too bad. ilmss didn't go to the trouble of reserving the name. It is pretty easy and not costly to do. Why would they NOT want to do it? If they are lazy it's their tuff luck if someone else DOES want to reserve the name. >>All of a sudden, there are two "ilmss" sites on the net... the official >>one, and your neighbor who chose not to bother keeping dibs on the name. >>Pathalias can't tell the difference between them. > >That's correct. > >>Everybody loses... you, your neighbor, the folks at the officially- >>registered "ilmss", and the folks trying to reach "ilmss". It's a bad >>scene. It's possible for large amounts of mail to end up being routed >>to the wrong continent, in severe cases of double-name-binding. > >Yep, absolutely right again. > >>So... it's absolutely your right to keep "ilmss" listed in the >>map file that you maintain locally. It's not your right, I feel, to >>insist that your private connection to an unregistered host be >>propagated into the pathalias data all across the network. To do so is >>to demand that the "ilmss" name be reserved for use by a site that >>isn't willing to play by the rules. > >Is it? Wait a second. What about the other side of the coin, to whit: > > Site "ilmss" doesn't register EXCEPT with mcdchg -- and mcdchg keeps > that link "private". Now, mail gets to mcdchg for "ilmss" without > a complete source-route (ie: it's received as "user@ilmss"). Let's > say someone else has taken the name and REGISTERED it. Now where > does the mail go? > > You get a star if you say "to the machine just off mcdchg". Which > is the wrong routing. Worse yet, there is no way to know that this > is about to or has happened, since you can't tell that "ilmss" is > declared anywhere until AFTER you start losing mail! > > IF mcdchg declares the link, then anyone wanting to use the name > "ilmss" can check the routing tables and quickly see that the name > is already taken somewhere else. If mcdchg does NOT declare the > link, there is no way to prevent the problem from occuring! > >>There are polite and effective ways to support sites which choose not to >>post individual map entries. Any neighbor who has a registered >>domain-name can act as a forwarder... in effect, "hiding" the >>unregistered site as a subdomain of the registered name. This way, the >>unregistered site's machine-name doesn't "pollute" the global namespace >>for the .uucp subdomain, and doesn't confuse pathalias. > >If a site which wants to register -- either by being entered into one >person's routing table (but not posting a map entry), or by sending a map >entry checks FIRST to see if the name is in use, this problem could >vanish. You see, if I do a "smail -bt test@ilmss", I will see that I can >get there from here. So I won't use that name, and will refuse to accept a >connection from there UNLESS the requester can verify that he is the one >who talks to "mcdchg" already (which means that it is the same site!) > >Problem solved. I'm afraid not. Read on... > >>So... to sum it up, I think that your area map-coordinator did an >>appropriate thing by removing the names of unregistered sites from the >>copy of your map entry that was added to your area's distributed map-file. > >Your suggestion makes it impossible for me to verify that a name is >available. If people have "private" connections to sites which aren't in >the maps, mail WILL fall into a black hole sooner than later. Internet >(or re-routing) sites are the worst, of course, since if they take on a >"undeclared" connection you can virtually guarantee that mail will >soon disappear or get misrouted. > >In short, I agree with Ron -- people should be able to declare connections >to sites which aren't in the maps, and if they do it SHOULD be honored -- >it should reserve the name which is declared (preventing that site name >from being registered later by anyone else.) This way a little common sense >before you accept a site (and show a connection there) can avoid the >misrouting problem entirely. > >Sure, people will still have misrouting problems. But at least you aren't >designing it into the process in such a way that it is inevitable! > Sorry, it's still inevitable UNLESS you guarantee that the "private" connect is an end node only. Addresses that are not source routed SHOULD not go to the site you want to give out stars for :-) The way our mailer is set up here is that: If we see name@host we try to resolve it through the internet. The UUCP hosts that ARE registered will resolve now. We send to their forwarder which WILL source route. If it doesn't resolve, we'll try it as a UUCP site, first as a local link and then through the maps. If we weren't on internet we would bypass the local lookup to force it to a registered site if one exists. The only way to the private site would then be with bang paths. If we see unmvax!private-link, whether registered or not we try to resolve by looking in our L.sys. If not there then try the UUCP maps. We encourage people to use the at-sign syntax so as not to force a particular network. Avoiding the bangs will let us use internet forwarders when possible. If someone wants to route through unmvax to a private link that is unregistered (there are some). They use: private!name@unmvax Even if private is registered their mail goes to the right place UNLESS we don't have the link. This goes whether it is a duplicated name or not. It is also how people with unregistered machines SHOULD be addressed. After all the address does mean the machine private off of unmvax. It sure is nice to tell my friend on the phone that I'm lee@unmvax on any UUCP machine supporting the syntax instead of {gatech,ucbvax,rice,anlams}!unmvax!lee. Gee, try one, I dunno. But then I paid for the priviledge with my time getting (and maintaining) my entry into the maps. If my neighbors don't and the map coordinator deletes them, they aren't unreachable just painful to reach. It seems to me that if a site doesn't want to go to the trouble of registering their name, that name is still up for grabs. Who cares if it shows up as a private link to some site. Just delete that one and register it to someone else. Let the guy who didn't register it deal with the problem. For that reason, blow it out of the map so the coordinator doesn't have to go to the trouble later. -- --Lee (Ward)