norm@ontenv.UUCP (Norman Soley) (12/20/87)
I noticed a new site posting for "mickey". The name "mickey" is already
used (by the Disney Company). Duplicate site names are common occurances
in news.newsites, but they always get filtered out before they make it
into the maps. A workable method even if the turn-around time is a
little long (and yes I know the mapping project is working on
improving that). However in this case the new "mickey" is connected to
uunet. Shouldn't someone at uunet be checking the maps before they
connect a new site? Any other site could be excused but much of the
net counts on uunet as an authoritative source for routing.
--
Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment
UUCP: utzoo!lsuc!ncrcan!---\ VOICE: +1 416 323 2623
{utzoo,utgpu}!sickkids!ontenv!norm ENVOY: MOESIB.B.BB
{mnetor,utgpu}!ontmoh/david@ms.uky.edu (David Herron -- Resident E-mail Hack) (12/22/87)
In article <271@ontenv.UUCP> norm@ontenv.UUCP (Norman Soley) writes: >I noticed a new site posting for "mickey". > ... Shouldn't someone at uunet be checking the maps before they >connect a new site? Any other site could be excused but much of the >net counts on uunet as an authoritative source for routing. No, no, NO .. don't count on uunet as authoritative routing machine ... Rick has publicly stated that if everyone on the world starts treating uunet as they'd treated seismo, then he'd turn off auto routing features in his configuration. And, I suppose, take other measures that come to mind as needed. I'm one of the map makers (for Kentucky) ... to my knowledge the only tools we have for checking the map are things like grep and uuhosts. We do have some policies about this subject. For instance, a pre-existing entry using a particular name will keep any other entries from being made in the map. If a site lists a link to some place that doesn't have a map entry, we call it a ghost site and that name is "held" to be used by the linked-to-site, along with a small protocol to be used when someone wants to make a map entry with the same name as a ghost site. We're also supposed to urge the ghost site to send in an entry. We, of course, can't do much about how uunet runs itself. But it does seem like a good idea for the uunet people to check things like this when connecting a new site. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- Winter health warning: Remember, don't eat the yellow snow!
rick@seismo.CSS.GOV (Rick Adams) (12/24/87)
I DO check the sites when they first connect up. There was no other mickey in the maps at the time. It's irelevant to claim that they already existed. They weren't in the maps a few months ago. (Don't assume sites post a newsite article immediately after connecting for the first time. Most wait quite a while) --rick
mangler@cit-vax.Caltech.Edu (Don Speck) (12/27/87)
In article <44208@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > I DO check the sites when they first connect up. There was no other > mickey in the maps at the time. You must have been missing some maps. When I helped Walt Disney Animation set up uucp last year, I made sure that they submitted a map entry, pronto. The entry is dated November 1986. I believe the information in it is still correct (even though it's been a long time since I had to bother them), because mickey continues to reliably gulp down its daily megabyte of netnews. When Disney linked up with us, some AT&T machine listed a "mickey" as a (dead) neighbor. The keepers of the map removed it for us. Once in a while, mickey will bounce a message intended for (I think) mickey.berkeley.edu and somehow misrouted to mickey.uucp. Other than that, though, Disney has clear precedence on the name 'mickey' (which is only fitting). Don Speck cit-vax uucp admin {amdahl,scgvaxd}!cit-vax!speck
jeff@necntc.NEC.COM (Jeff Janock) (12/29/87)
In article <271@ontenv.UUCP> norm@ontenv.UUCP (Norman Soley) writes:
=> I noticed a new site posting for "mickey". The name "mickey" is already
=> used (by the Disney Company).
You say 'The name "mickey" is already used (by the Disney Company).'
Does this imply that the name mickey is already in use as a UUCP site
hostname? (you do not state this) If it does, then this site
"mickey" should have a map entry in the UUCP maps - I would check here
before putting any new site into the maps - even if this new name
shows in the maps without a map entry, it is rejected.
[as these ghost sites have some rights :-) ]
If you ngrep the maps (or your final path database) "for "mickey":
mickey harvard!ll-xn!cit-vax!mickey!%s
Hmmm, interesting - mickey shows as connecting of cit-vax
I look a little more and:
------------
#N mickey
#S HP 9000 Model 540; HP-UX 5.11 (V.2)
#O Walt Disney Company
#C Mark Kimball, Tad Gielow
#E mickey!usenet
#T +1 818 956 2500
#P 1420 Flower St., Glendale, CA 91201
#L 34 12 00 N, 118 21 24 W
#R Prior version had mistakes, this should be OK.
#W mickey!lem (Lem Davis); Wed Nov 12 12:00:00 PDT 1986
#U cit-vax
#
mickey cit-vax(EVENING)
------------
this new site name "mickey" that I include here - WILL NOT
appear in the maps posted to comp.mail.maps -
--
#N mickey
#S SUN Microsystem SUN-3/260, OS 3.4
#O Davox Corporation
#C Pen Hsieh
#E mickey!pen,mickey!usenet
#T +1 617 667 4455 x308
#P 4 Federal Street Billerica, Massachusetts, 01821, USA
#L 42 20 N / 71 05 W city
#W mickey!pen (Pen Hsieh); Sun Dec 13 17:38:29 EST 1987
#U uunet
#
mickey uunet(DAILY)
--
and even better - all smartsites will route replies to this (in MA)
sites email to disney (in CA)!
This would make me consider re-naming my machine :-)
I ask everyone who is choosing a new site name to check the maps
prior to coming to a final decisoon. Even in the fastidious case
where you feel you have checked everything - the new site name may
still be flagged for a few other reasons:
1) starts with a nureric character
2) contains an underscore (_) character ie. eagle_snax
in this case, the name eagle-snax is reserved for this site.
3) contains an uppercase cahracter
4) resides on some other reserved name list someplace...
=> Duplicate site names are common occurances in news.newsites,
=> but they always get filtered out before they make it into the maps.
I concur that news.newsites is not checked for duplicates -
The people doing the mapping work have specific methods set up
to accept new entries and updates - this is an evolving process,
so postings that we see in news.newsites are more a prelude to
the fact that another site really wants a map entry placed into
the maps - sometimes an attempt at contacting the new site in question
is made if a map entry is not received via the standard channels
after some period of time... (for potential new england sites,
cannot say for others...)
Now and then, other site admins will send email me and inform of a
possible problem with routing data or potential duplicate names.
So, in conclusion, posting to news.newsites never end up in the maps.
The same information may arrive to be processed, but rest assured, it
will be processed.
=> A workable method even if the turn-around time is a
=> little long (and yes I know the mapping project is working on
=> improving that).
I can turn new entries and updates around in 24 hours - Do we really
want this? I have seen some discussion on this topic and it is my
feeling that "substantial modifications" or when there is a set
amount of work (in the queue to prevent backlog) should determine
how often updates are posted - Remember the people doing the map
processing donate their time to the task... Oh, we cannot forget
that domain entries have lots of rights as they pay for their entries...
=> However in this case the new "mickey" is connected to
=> uunet. Shouldn't someone at uunet be checking the maps before they
=> connect a new site?
UUNET could do (and perhaps does) an initial scan to determine if
there is a duplicate invloved - but when the entry is to be processed
for placement into the maps, it would be flagged right off (in this
case) -
btw, before any new UUCP connections are taken on by !necntc,
this first pass through on their hostname is done - then a strong
request that an 'official map entry' be submitted helpin
to construct one if need be...
This could/should be a good general practicee when taking on new sites.
=> Any other site could be excused but much of the
=> net counts on uunet as an authoritative source for routing.
This statement bothers me a little - uunet never officially offered
auto-routing (to my knowledge) - and when I have attempted such,
received email failure messages in return. Before mickey (in MA)
gets into the maps, the hostname will have been changed - this
implies that uunet will have to make the mod in its UUCP config...
Another comment on UUNET:
this is a service - why should uunet autoroute email? It is a problem
with sites that use USENET news paths for email paths - but I digress...
the sites pay for all data picked up and sent to UUNET. These sites
do not want email routed through their pay for play links!
-jj
--
Yours for accurate map data,
Jeff Janock - UUCP Project New England Map Coordinator
{decvax,harvard,mit-eddie,linus,adelie, etc}!necntc!nemaprobert@uop.edu (Doc Ness) (12/29/87)
I posted this to another group, but since there is a discussion of duplicate names going here, what about tut? There is a finnish computer named tut, and recently I have noticed a north-american machine with the same name.
rsalz@bbn.com (Rich Salz) (12/29/87)
In comp.mail.uucp (<12251@necntc.NEC.COM>), nemap@necntc.nec.com (New England Mapping) writes: > I ask everyone who is choosing a new site name to check the maps > prior to coming to a final decisoon. Even in the fastidious case > where you feel you have checked everything - the new site name may > still be flagged for a few other reasons: This is a bit circular, isn't it? Can't set up news without a feed, can't pick up news without a name, can't guarantee a unique name without the maps, can't get the maps without a feed... And even if the loop is opened (by getting the nice, friendly, overworked admin on my feed to check for me "unh, bilbo is taken? How about frodo? Oh, could you try sam? What about nice -- no, n-i-c-e, named after the place in France, not the relavitve"), there's still a timelag. Jeff, you could turn the maps requests around in thirty minutes, but so what? It's useless until the maps are sent out to the entire world and everyone has run them through uuhosts or whatever they use. Executive summary: the current system is buggy. /r$ -- For comp.sources.unix stuff, mail to sources@uunet.uu.net.
honey@umix.cc.umich.edu (Peter Honeyman) (12/29/87)
another way to check this is pathalias -t mickey files > /dev/null |& error -v peter
karl@tut.cis.ohio-state.edu (Karl Kleinpaste) (12/29/87)
robert@uop.edu writes:
I posted this to another group, but since there is a discussion of
duplicate names going here, what about tut?
There is a finnish computer named tut, and recently I have noticed a
north-american machine with the same name.
That's us, on tut.cis.ohio-state.edu, a Pyramid 98x which is the
central machine of Ohio State Computer Science. Due to the fact that
references to our Tut are always properly domain-qualified, it is not
(or should not be) any problem. Our Tut always refers to himself by
full domain name in all mail-related things, and the only other place
where his name is mentioned is in outbound Path: lines in news
headers, where he shows up as a neighbor of osu-cis and bgsuvax, thus
assuring his uniqueness within the frame of reference.
There was a problem a month or so ago, where some things coming from
Europe were getting bounced around a bit randomly (from Sweden to
UUNET to both OSU and Finland...sigh) but I believe that was taken
care of. And I didn't have anything to do with any fix that had to do
with mis-re-routing UUCP stuff to Finland; what was hurting us was a
bit of bogosity on my part in my sendmail.cf relative to a DEC-20
here.
You say you mentioned this somewhere else; I didn't see it. Where?
--
Karlaburt@isis.UUCP (Andrew Burt) (12/30/87)
In article <3569@tut.cis.ohio-state.edu> karl@tut.cis.ohio-state.edu (Karl Kleinpaste) writes: >robert@uop.edu writes: >> I posted this to another group, but since there is a discussion of >> duplicate names going here, what about tut? >> There is a finnish computer named tut, and recently I have noticed a >> north-american machine with the same name. >That's us, on tut.cis.ohio-state.edu... >...references to our Tut are always properly domain-qualified, it is not >(or should not be) any problem... >...and the only other place >where his name is mentioned is in outbound Path: lines in news >headers, where he shows up as a neighbor of osu-cis and bgsuvax, thus ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >assuring his uniqueness within the frame of reference. ^^^^^^^^^^^^^^^^^^^^^^^ There's also a tut.colorado.edu for what it matters. The emphasized part (^^^^) is not necessarily true, however. If one sends mail to osu-cis!tut!user, and the path to osu-cis takes the message through a machine with a so-called "smart mailer" that tries to reroute mail "better" then the "smart mailer" may decide it knows how to reach tut better and may pick a different tut. Real life example. After the death of seismo, pathalias here decided rutgers was the best way to reach most domainized sites. I later sent mail to (oddly enough) osu-cis!tut!user and received a bounced mail msg from tut in Finland after a few days. Tried again, same result. Turned out rutgers was being "smart". I tried to sway Mel Pleasant toward a "smarter" algorithm such as if original-path has the form ...!site1!site2!user, and a "better" path to site2 can be found than via ...!site1, then *verify* that the site2 found in the maps is the same as the site2 meant in original-path by checking whether the site2 in the maps lists site1 as a neighbor. If not, use original-path. Clearly this adds more weight to the "smart" mailers, making them look up map entries for each possible re-routing attempt (i.e., the smart system is selflessly making net routing better at the expense of its own cpu time). On the other hand, if you set out to do a job (no matter how selflessly motivated), don't do half a job. As I run a large mailing list and deal with many odd addresses, this kind of behavior has really made life tougher. Mailer problems have been keeping me from getting the list regular for months. (And don't say use a newsgroup, we're talking about the Unix Security mailing list -- too touchy for general consumption.) My solution to this problem? I declared rutgers a dead site for pathalias purposes... -- Andrew Burt isis!aburt Fight Denver's pollution: Don't Breathe and Drive.
pleasant@rutgers.rutgers.edu (Mel Pleasant) (12/30/87)
In article <3569@tut.cis.ohio-state.edu> karl@tut.cis.ohio-state.edu (Karl Kleinpaste) writes: > Our Tut always refers to himself by full domain name in all mail-related > things, and the only other place where his name is mentioned is in outbound > Path: lines in news headers, where he shows up as a neighbor of osu-cis and > bgsuvax, thus assuring his uniqueness within the frame of reference. Why use a fully qualified name (domainized) in mail and not in news?!? There are lots of sites which use the Path: header to generate return addresses when replying to news articles. This happens when a news administrator chooses not to define INTERNET in his defs.h file - a valid thing to do when his system does not grok internet addressing! So, you cannot so easily divorce your news system from your mail system by attempting to claim that news is news and mail is mail where neither the two shall meet. At Rutgers, we've developed the following solution to the Path: header problem. If you're up on RFC976, you'll note that this solution fits quite well. All internal internet sites use fully qualified hostnames in both mail and news. Only our networks gateway system presents itself to the world in different ways. For these purposes I'll only speak of two. Internet neighbors see our gateway system as rutgers.edu. To uucp neighbors we appear as just plain rutgers. Since all outbound news passes through rutgers, the Path: header, which should always appear in bangist form, winds up looking like: Path: rutgers!internal-host.rutgers.edu!user This solution works well if you have a gateway system that all outbound news actually passes through. If you do not have such a gateway system, the same effect can be had by a hack. I state this here and now so flames and groans can be directed towards /dev/null. The hack involves altering the GENERICPATH definition in defs.h. Its definition depends heavily on your connections, particularly your news connections to the outside world e.g. those systems not in your domain. Essentially you want to build a Path: header that looks like: Path: a-unique-uucp-name!myname.with.my.domain!user Remember, the local news system is generating this Path: header so, in essence, you're faking the "a-unique-uucp-name" (AUUN) portion. The AUUN must name a system that a) all of the local system's news neighbors can reach via uucp and b) has a mailer that groks internet addresses according to RFCs 822 and 976. If you can identify such a system that also happens not to run the netnews software then you're in really great shape. Not running the netnews software is not a requirement but is highly recommended. Once you've identified an AUUN system, you change GENERICPATH to "a-unique-uucp-name!myname.with.my.domain". If you want to be fancy about the definition or if your attempting to build executables that can run on more than one system, you can define GENERICPATH as "a-unique-uucp-name!%s%s". The netnews software will replace the first %s with the local nodename and the 2nd %s with the domainas defined by MYDOMAIN. Note that if you define GHNAME and the name returned contains a domain, you should undef MYDOMAIN. Also take note: it is the name that appears in the Path: header that the news system uses to determine whether a site has received a particular article or not. So, if your site's name is going to appear as "myname.with.my.domain" in the Path: header, then it must also appear this way as the first token of the entry in the news sys file that represents your system. Using the same reasoning, the AUUN system, if it runs netnews, must receive the article before your local system does!! This disqualifies all outbound news neighbors from acting as your AUUN. So like I said, this is a real hack. But, it will allow you to use fully qualified names everywhere in mail and news. Good luck.... -- Mel Pleasant {backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnet
billw@killer.UUCP (Bill Wisner) (12/30/87)
The north american tut is tut.cis.ohio-state.edu. Being part of a registered
domain, there isn't much of a problem with uplicate names.
--
Bill Wisner / billw@killer.UUCP / ..{cbosgd,codas,ihnp4}!killer!billw
Internet types can try billw@OBERON.LCS.MIT.EDU, for now anywaykarl@tut.cis.ohio-state.edu (Karl Kleinpaste) (12/30/87)
pleasant@rutgers.rutgers.edu writes:
Why use a fully qualified name (domainized) in mail and not in news?!?
First, Mel, chill out.
There are lots of sites which use the Path: header to generate return
addresses when replying to news articles. This happens when a news
administrator chooses not to define INTERNET in his defs.h file - a valid
thing to do when his system does not grok internet addressing!
Fine. When a user at such a site replies to a Usenet message from
tut.cis.ohio-state.edu, the reply will go to a UUCP !-path that looks
something like
To: some!set!of!hosts!cbosgd!osu-cis!tut!osu-username
which is just wonderful, fine, and dandy. That path will find us,
every time.
So, you
cannot so easily divorce your news system from your mail system by
attempting to claim that news is news and mail is mail where
neither the two shall meet.
Where did I ever say that mail is divorced from news? They meet very
often (indeed, my sendmail.cf believes in news in a fairly intimate
way), but this presents no problem. The presence of "!tut!" in the
midst of a !-path is very well qualified around here - our Tut has
only 2 "UUCP" neighbors, and one of those is actually an NNTP
connection. Sites that believe in domain addressing reach us
trivially. Sites that don't believe in domain addressing reach us
with a !-path.
We have allowed news to continue to generate Path: lines containing
just "tut" instead of his full name because he's had his UUCP
configured for a Shere name of "tut" for quite a long time. When we
installed news on Tut (all of maybe 4 months ago), we didn't want to
change that particular aspect of him; this fit well.
It only occurred to me this morning that this could cause problems in
Europe, because if the Finnish Tut (tut.fi, I think, but I wouldn't
swear to it just this instant) also uses a simplistic "tut" name for
Path: lines, then stuff posted on one Tut won't get propagated to the
other Tut; their respective news neighbors will notice that "tut" is
already in there, and decline to forward. That's a problem. But it's
got nothing to do with the ability of Joe Random out there on a
non-domain-addressing host being able to mail a reply to someone at
Ohio State.
Anyhow, I will take a look at your suggestions for getting our Tut to
generate fully qualified domain references to himself in the Path:
line, purely for the sake of ensuring proper article propagation
between whatever Tuts might be out there.
--
Karlvjk@tut.fi (Vesa Kein{nen) (12/30/87)
From article <872@uop.edu>, by robert@uop.edu (Doc Ness): > I posted this to another group, but since there is a discussion of > duplicate names going here, what about tut? > > There is a finnish computer named tut, and recently I have noticed a > north-american machine with the same name. The real tut.uucp (aka. tut.fi) resides in finland at Tampere University Of Technology. It's also Finnish backbone. There are couple sites in states with (local) name 'tut', which get misrouted to finland. Those I know are: tut.cis.ohio-state.edu tut.boulder.colorado.edu I think there are one more behind rutgers.edu. This is what happens (at least I think so): E.g. you try to mail to user@tut.cis.ohio-state.edu. Your mail reaches site, which thinks that it knows all hosts under cis.ohio-state.edu. That site simply strips domain out of address (user@tut.cis.ohio.state.edu --> user@tut). Now this address can mean tut.uucp or tut the localhost and gets routed to finland. Postmasters at cis.ohio-state.edu, boulder.colorado.edu and rutgers.edu have been informed about this problem. Vesa -- Vesa Keinanen # Tampere University of Technology vjk@tut.fi # /Computer Systems Laboratory (vjk@tut.UUCP mcvax!tut!vjk) # PO box 527, SF-33101 Tampere, Finland postmaster@tut.fi # tel: 358 31 162573 *** NEW ***
honey@umix.cc.umich.edu (Peter Honeyman) (12/30/87)
In article <2168@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: >I tried to sway Mel Pleasant toward a "smarter" algorithm such as > if original-path has the form ...!site1!site2!user, > and a "better" path to site2 can be found than via ...!site1, > then *verify* that the site2 found in the maps is the same as the > site2 meant in original-path by checking whether the site2 in > the maps lists site1 as a neighbor. If not, use original-path. folow that line of thinking long enough, and you'll reinvent pathparse. maybe pathparse \is/ the solution ... ? peter
jc@minya.UUCP (John Chambers) (01/02/88)
In article <277@fig.bbn.com>, rsalz@bbn.com (Rich Salz) writes: > In comp.mail.uucp (<12251@necntc.NEC.COM>), nemap@necntc.nec.com (New England Mapping) writes: > > I ask everyone who is choosing a new site name to check the maps > > prior to coming to a final decisoon. > > This is a bit circular, isn't it? Can't set up news without a feed, > can't pick up news without a name, can't guarantee a unique name without > the maps, can't get the maps without a feed... > > And even if the loop is opened (by getting the nice, friendly, overworked > admin on my feed to check for me "unh, bilbo is taken? How about frodo? Yeah, and it'll get a lot worse before it gets better. Now I'm working at a place that is installing all sorts of glorified terminals (Macs, IBM PCs, Sun and Apollo diskless workstations) that each masquerade as a "host" and need names. Hundreds of them. And this is just one company. I can't tell them that all the good ones are taken, and they'll just have to settle for something like "qvx13j"; such bureaucratic monstrosities just elicit a lot of incredulous looks. Also, in lots of companies, such little machines get tied into the global network in a bottom-up fashion. First they are plopped down on a desk; then they get plugged into the LAN; then the users discover that there are email bridges and FTP that will let them talk to people in other departments; then they ask if it's possible to send a file to another building; then they find out that it's actually possible to get mail to other companies; ... By the time the unique-name problem comes up, it's far too late; their chosen name is hard-coded into all their friends' and colleagues' files. You can tell them that they have to rename their machine, but it's of little avail, especially when they start to realize how incredibly hard it is. (I mean, I've been trying for weeks to straighten out the mess caused by a Sun that was configured with a '_' in its name; I've found and changed hundreds of instances to '-', and there are still more out there causing undeliverable mail...;-) It is starting to look like name uniqueness, laudable as the idea may be, just ain't gonna work. Maybe back when there were a mere 10000 nodes in the network, but no longer. The smail system isn't bothered by the fact that I live at an address that is duplicated in other towns (one of which is the next town west of here). In the long run, a successful email system must handle the local parceling out of addresses/names/whatever-you-call-them, too. Otherwise we can't possibly grow to the billion-node system that the postal system already handles (at a mere penny a day :-). And don't look now, but within a decade, email will be that big. Even IBM is now delivering PCs with email software in them. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
kurt@hi.unm.edu (Kurt Zeilenga) (01/02/88)
>> > I ask everyone who is choosing a new site name to check the maps >> > prior to coming to a final decisoon. > >Yeah, and it'll get a lot worse before it gets better. Now I'm working at >a place that is installing all sorts of glorified terminals (Macs, IBM PCs, >Sun and Apollo diskless workstations) that each masquerade as a "host" and >need names. Hundreds of them. And this is just one company. I can't tell >them that all the good ones are taken, and they'll just have to settle for >something like "qvx13j"; such bureaucratic monstrosities just elicit a lot >of incredulous looks. NO, you get yourself a domain name (registered, of course). Then you don't have to worry about conflicts with the outside world because your fully qualified hostname will be unique since the domain name will be unique. > [context deleted] -- Kurt (zeilenga@hc.dspo.gov)
fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (01/02/88)
The problem you cite is solved by domain names. This is what the UUCP Project has been telling the network community since 1984. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
rroot@edm.UUCP (uucp) (01/05/88)
In article <3569@tut.cis.ohio-state.edu>, karl@tut.cis.ohio-state.edu (Karl Kleinpaste) writes: > robert@uop.edu writes: > That's us, on tut.cis.ohio-state.edu, a Pyramid 98x which is the > .... Our Tut always refers to himself by > full domain name in all mail-related things, and the only other place > where his name is mentioned is in outbound Path: lines in news > headers, where he shows up as a neighbor of osu-cis and bgsuvax, thus > assuring his uniqueness within the frame of reference. Since there is already a !tut site in the uucp domain, you should have created a name like !osc-tut for USENET usage -- even if you didn't use it for other stuff. This site (!edm) was going to be called !toy, until it was found out that the site already existed somewhere near New York. Unfortuntely, by the time we realized this, it did some really odd things to the alias program on !alberta at the time (once we changed !edm, !neyessa (a site we feed) was still aliased as toy!neyessa and, therfore got forwarded to the REAL toy, who knew NOTHING of neyessa and bounced all the messages...). It took a week or so to realize where the problem was. -- ------------- Stephen Samuel {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve
jc@minya.UUCP (John Chambers) (01/05/88)
> >Yeah, and it'll get a lot worse before it gets better. Now I'm working at > >a place that is installing all sorts of glorified terminals (Macs, IBM PCs, > >Sun and Apollo diskless workstations) that each masquerade as a "host" and > >need names. Hundreds of them. And this is just one company. ... > NO, you get yourself a domain name (registered, of course). Then you > don't have to worry about conflicts with the outside world because your > fully qualified hostname will be unique since the domain name will be > unique. Sorry, but you haven't been listening to the complaints from the users of the various "tut" machines, some of which are properly hidden behind some domainized gateways. The basic scenario is that someone at Fubar University has their tut.edu down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh; the mailer at ... realizes there's a faster route to tut.edu than via fu.edu and mails it to tut.edu over in Finland. Proper domainizing doesn't help a bit here. The real culprit is the assumption of unique names. This was a reasonable assumption back when we had only a few thousand nodes to worry about. It is doesn't work so well as the number of nodes approaches 6 digits. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
karl@tut.cis.ohio-state.edu (Karl Kleinpaste) (01/05/88)
rroot@edm.UUCP writes:
Since there is already a !tut site in the uucp domain, you should
have created a name like !osc-tut for USENET usage -- even if you
didn't use it for other stuff. This site (!edm) was going to be
called !toy, until it was found out that the site already existed
somewhere near New York. Unfortuntely, by the time we realized
this, it did some really odd things to the alias program on
!alberta at the time
Aliasing has never been a problem in this regard. Our UUCP map entry
does not mention our Tut as just "tut" at all. I just checked it to be
sure; it is always fully-qualified.
I reiterate: Within a Usenet Path: line, our Tut is unique, because he
will show up as a neighbor of osu-cis and/or bgsuvax. That's all.
That's quite unique, assuming that no one tries to be "smart" and
screws it up. So non-domainified replies will reach here correctly.
The From:, Sender:, Message-ID:, and whatever other lines mentioning
his name always use the full domain name, which is guaranteed unique.
Thus, the problem is still only that stuff from our Tut will not get
into Finland because of the presence of !tut! in the Path: line, and
vice versa. I will fix that as soon as other fires die down, so that
he shows up in full-domain form in the Path: line as well.
--
Karlrsalz@bbn.com (Rich Salz) (01/06/88)
>The basic scenario is that someone at Fubar University has their tut.edu >down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh; >the mailer at ... realizes there's a faster route to tut.edu than via >fu.edu and mails it to tut.edu over in Finland. >Proper domainizing doesn't help a bit here. *PROPER* domainizing helps totally here. If tut.edu is a machine in the fu.edu domain, then it should be named tut.fu.edu. You cannot guarantee that it is always safe to put a "believed-unique" name after a fully-qualified domain name. *BUT*, if all the names the outside worlds sees are ALWAYS fully-qualified names inside registered domains, everything works fine. Note that ALWAYS includes things like the Usenet Path: line and the UUCP-mail From_ line. -- For comp.sources.unix stuff, mail to sources@uunet.uu.net.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/06/88)
jc@minya.UUCP writes:
Sorry, but you haven't been listening to the complaints from the users of
the various "tut" machines, some of which are properly hidden behind some
domainized gateways.
No, he's been listening just fine. We've got one of those Tuts, and
it's in a domain hidden properly behind a gateway.
The basic scenario is that someone at Fubar University has their tut.edu
down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh;
the mailer at ... realizes there's a faster route to tut.edu than via
fu.edu and mails it to tut.edu over in Finland.
The whole point is that the names fu.edu and tut.edu are inherently
unique. They're defined to be unique. They can't *not* be unique.
There is only one tut.edu anywhere, and only one fu.edu.
Now, actually, the names in question are things like tut.colorado.edu,
tut.rochester.edu, tut.cis.ohio-state.edu, and tut.fi. Those are
unique names. No one can conflict with our tut.cis.ohio-state.edu,
because they have no means by which to interfere with our management
of the .cis.ohio-state.edu domain. There could even be a
tut.ohio-state.edu along with our tut.cis.ohio-state.edu and there
would be no problem - the domain specs force them to be unique.
Proper domainizing doesn't help a bit here. The real culprit is the
assumption of unique names. This was a reasonable assumption back when
we had only a few thousand nodes to worry about. It is doesn't work
so well as the number of nodes approaches 6 digits.
It works just dandy if you'll bother to include a full domain spec.
The problem is solved, it just has to be implemented. I don't care if
the number of hosts passes 2^32 - a domain spec forces uniqueness in
every case.
The problem arises when somebody decides that his host is "smart" in
some sense, and obliterates either [a] the required !-path context, or
[b] the required domain spec context. With either context in place,
the names are unique. Take away the context, and you have conflict.
This is why tut.cis.ohio-state.edu and tut.fi have had problems. Just
stop taking away the context, and anyone wanting to reach any Tut will
find exactly what they're looking for.
-=-
Karlbrant@linc.cis.upenn.edu (Brant Cheikes) (01/06/88)
In article <446@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> >Yeah, and it'll get a lot worse before it gets better. >... >> NO, you get yourself a domain name (registered, of course). > >Sorry, but you haven't been listening to the complaints from the users of >the various "tut" machines [...] > >The basic scenario is that someone at Fubar University has their tut.edu >down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh; >the mailer at ... realizes there's a faster route to tut.edu than via >fu.edu and mails it to tut.edu over in Finland. I believe you misunderstand the domain system. The proper domain for Fubar U would be something like "fubar.edu". A site "tut" within the Fubar domain is properly addressed as "tut.fubar.edu". You address your mail to ...!tut.fubar.edu!user. The smart mailers forward mail addressed to <subdomain>.fubar.edu!user to fubar.edu's gateway machine, say bletch.fubar.edu, so mail to tut ends up being addressed as ...!bletch.fubar.edu!tut.fubar.edu!user. Since fully-qualified domain names are unique, there should never be a problem such as you describe. --- Brant Cheikes University of Pennsylvania Department of Computer and Information Science ARPA: brant@linc.cis.upenn.edu, UUCP: ...drexel!manta!brant
kurt@hi.unm.edu (Kurt Zeilenga) (01/06/88)
In article <446@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> >Yeah, and it'll get a lot worse before it gets better. Now I'm working at >> >a place that is installing all sorts of glorified terminals (Macs, IBM PCs, >> >Sun and Apollo diskless workstations) that each masquerade as a "host" and >> >need names. Hundreds of them. And this is just one company. >... >> NO, you get yourself a domain name (registered, of course). Then you >> don't have to worry about conflicts with the outside world because your >> fully qualified hostname will be unique since the domain name will be >> unique. > >Sorry, but you haven't been listening to the complaints from the users of >the various "tut" machines, some of which are properly hidden behind some >domainized gateways. > >The basic scenario is that someone at Fubar University has their tut.edu Okay. Fubar U. has a registered domain, fu.edu. And in fubar.edu they have a host, tut.fu.edu. >down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh; Okay, tut.edu != tut.fu.edu. If there is a registered tut.edu, then it should go there. If not, then tut.edu is not a valid host. >the mailer at ... realizes there's a faster route to tut.edu than via >fu.edu and mails it to tut.edu over in Finland. Okay, that should good, where is the problem. The problem is that proper domainizing is not being done. > >Proper domainizing doesn't help a bit here. The real culprit is the Yes. it does. >assumption of unique names. This was a reasonable assumption back when The real problem is that sites do not, 1) register themselfs, and 2) do not use the domain system properly. >we had only a few thousand nodes to worry about. It is doesn't work >so well as the number of nodes approaches 6 digits. And that is why everyone should be going to a tree structure for naming hosts. >-- >John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) -- Kurt (zeilenga@hc.dspo.gov)
woods@hao.ucar.edu (Greg Woods) (01/06/88)
In article <446@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >The basic scenario is that someone at Fubar University has their tut.edu >down the line from fu.edu; I send them mail to ...!fu.edu!tut.edu!jrh; >the mailer at ... realizes there's a faster route to tut.edu than via >fu.edu and mails it to tut.edu over in Finland. > >Proper domainizing doesn't help a bit here. In this case, Fubar University's mailer is seriously brain-damaged, because the tut over in Finland is tut.fi, NOT tut.edu. That is EXACTLY the point behind domain naming; it GUARANTEES unique netwide names as long as the names within each domain are unique. There is also no reason why there can't be a tut.colorado.edu (as there actually is at CU Boulder), a tut.osu.edu and a tut.fi . PROPER domainizing will deliver all messages to the correct address. The only names which must be unique are those that appear WITHOUT domains in uucp paths. I solve this problem by 1) Making sure that our uucp domain gateway machine has a unique name (hao); and 2) Making sure that all news articles and mail messages out of here are stamped with a fully domainized return path. For example, we have a machine "groucho" here. There is also a "groucho" in AT&T. This does not present a problem, because mail messages from OUR groucho have a From: line like "user@groucho.ucar.edu", and news articles go out with the path ...!hao!groucho.ucar.edu!user. There is no way that PROPER domainizing or path routing can fail to deliver this to the correct "groucho". There is no ambiguity when full domains are used. --Greg
jbuck@epimass.EPI.COM (Joe Buck) (01/07/88)
In article <1074@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: [ The old "tut.fi" vs "tut.ohio.edu" (sp?) argument ] >address. The only names which must be unique are those that appear WITHOUT >domains in uucp paths. This is only true because certain anti-social mailers insist on rerouting bang paths. If I have a site "ohio" which is unique, and it talks to tut.ohio.edu and not to tut.fi, then I insist that ...!ohio!tut!user is a unique path that specifies the correct tut. Mailers have no business rewriting valid bang paths. For an invalid bang path, the mailer should route to the leftmost host, not the rightmost host. One exception (this is John Gilmore's idea) is that if there is a domain name further on in the path you can route to it. For example, in foo!bar!bletch.com!user you can route directly to bletch.com since it's guaranteed to be unique. But I don't think you should route even these. Greg's criterion would prevent any UUCP site from existing that isn't registered with the UUCP project, unless by sheer luck they pick a unique name and no one comes along later and registers that name for themselves. Just the same, if it is possible to do what Greg recommends (putting fully qualified names in the bang path), I would recommend that everyone do so, just to protect themselves against overly clever mailers. Site administrators should consider the part of the Hippocratic Oath that says "First, do no harm." If you can talk to the first host in the path, but you think you know a better route, are you sure that that route is going to work in all cases? If the path specified doesn't match what your database says is the optimal path, is it possible that the user is reacting to a news.config message saying "Avoid site fubar, we're down for two weeks"? -- - Joe Buck {uunet,ucbvax,sun,decwrl,<smart-site>}!epimass.epi.com!jbuck Old internet mailers: jbuck%epimass.epi.com@uunet.uu.net Argue for your limitations and you get to keep them. -- Richard Bach
jc@minya.UUCP (John Chambers) (01/08/88)
> The real problem is that sites do not, 1) register themselfs, and 2) > do not use the domain system properly. Nah, the real problem is that, for every machine in the hands of a properly qualified guru, there are about 10000 in the hands of uneducated dummies (like me :-) that don't comprehend the great genius behind domainization and are trying to get their computers to exchange mail with others and are stumbling around just trying to make it work somehow and get little other than arrogance and insults from the experts.... > >we had only a few thousand nodes to worry about. It is doesn't work > >so well as the number of nodes approaches 6 digits. > > And that is why everyone should be going to a tree structure for naming > hosts. Well, actually, we had that a couple of years ago, and we threw it away. You know, you send mail up to a!b!...!seismo, which is the root of the tree, and from there down to ...!y!z!joe, and it got there. (:-) Seriously, if you treat the major clearing houses as roots, their neighbors as "domains", and so on, the uucp system (?) is easily viewed (and is often implemented as) trees with cross-links. It's a lot easier to explain to a novice email user than all those '@' and '%' and '.' and '<..>' messes. And now that the newer releases understand LANs, it works a whole lot better than sendmail ever did. > > >John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) > [Oh, no, it's him again! :-] -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
kurt@hi.unm.edu (Kurt Zeilenga) (01/09/88)
In article <447@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Nah, the real problem is that, for every machine in the hands of a properly >qualified guru, there are about 10000 in the hands of uneducated dummies >(like me :-) that don't comprehend the great genius behind domainization >and are trying to get their computers to exchange mail with others and >are stumbling around just trying to make it work somehow and get little >other than arrogance and insults from the experts.... Well, I can agree with that... I was just trying not to be arrogant or insulting. >> And that is why everyone should be going to a tree structure for naming >> hosts. > >Seriously, if you treat the major clearing houses as roots, their neighbors >as "domains", and so on, the uucp system (?) is easily viewed (and is often >implemented as) trees with cross-links. It's a lot easier to explain to a >novice email user than all those '@' and '%' and '.' and '<..>' messes. And >now that the newer releases understand LANs, it works a whole lot better than >sendmail ever did. I always that it was pretty easy to tell uses that I am at kurt@hi.unm.edu It makes sense, hi is a SUN at UNM, UNM are a educational institute :-), etc. They don't have to remember that siesmo is a root, but then have to be told that, no, siesmo is not the root anymore and uunet is, or is it? -- Kurt (zeilenga@hc.dspo.gov)
soley@ontenv.UUCP (Norman S. Soley) (09/23/88)
Yet another duplicate site name kiddies. In the most recent u.can.on.1 there appeared a site called leibniz ay Bell-Northern Research. However it seems that leibniz is already a "ghost site" in AT&T and appears in the map for the att psuedo-machine. I normally would have just brought this up with the site itself and our local map co-ordinator but it raises another question. All of the AT&T machines are supposed to be part of the .att.com domain but they still list all of their leaf nodes by their "undomained" name. Is this really necessary? The only reason I can see for not cutting the att map entry back to only the necessary information to have it function as a gateway (i.e. listing only those sites that maintain outside connections) is that in an organization the size of AT&T it might be very difficult to assure that all of the 1000 or so leaf nodes are spitting out fully qualified domain names on their news and mail. Any comments? -- Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment UUCP: uunet!attcan!lsuc!ncrcan!ontenv!soley VOICE: +1 416 323 2623 OR: soley@ontenv.UUCP