sewilco@datapg.MN.ORG (Scot E Wilcoxon) (08/18/88)
News sites with the same name are invisible to each other.
Articles from one site "xyz" are not sent to a second site "xyz" because
the first "xyz" is found in the "Path" line. This is particularly bad
because all sites "xyz" may be hidden within private subdomains and
none can be found in public site lists.
A proposed solution:
If the site which sent the article to this machine does not have the
same name as the one to which the article is being sent, and the
article was posted by a site with the same name as the one to which
the article is being sent, force the article to be sent.
Otherwise test Path as is currently done.
This will force all sites named "xyz" to receive articles from other "xyz"
sites, but the neighbors of an "xyz" which receive an article from that "xyz"
will not send it back to the "xyz" site which just sent it.
The existing Path tests will stop loops, as a loop requires passing through
at least one machine named differently than the posting site. Even if two
machines of the same name are directly connected, and the history test
fails for some reason, a loop will stop at the beginning of the second
cycle when the "machine which sent the article" is detected as being the
one to which the article might be sent.
A pseudocode definition:
Definitions:
POSTING_SITE: The ending site name in Path (...!POSTING_SITE!username).
PREVIOUS_SITE: The site which sent article to current machine, may be
null if article posted here (Path: current!PREVIOUS_SITE!...).
TARGET_SITE: The name of the site which is being sent to.
if (PREVIOUS_SITE != NULL) && (PREVIOUS_SITE != TARGET_SITE)
&& (TARGET_SITE == POSTING_SITE)
force the article to be sent
else
present code for "target site in Path"
--
Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco
Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
Proud owner of a new power supply. The previous one blinked blue-white.
"Have you ever been kissed by lightning?" -- 'So you wanted to meet the wizard'emv@mailrus.cc.umich.edu (Edward Vielmetti) (08/18/88)
In article <1445@datapg.MN.ORG> sewilco@DataPg.MN.ORG (Scot E Wilcoxon) writes: >News sites with the same name are invisible to each other. >Articles from one site "xyz" are not sent to a second site "xyz" because >the first "xyz" is found in the "Path" line. This is particularly bad >because all sites "xyz" may be hidden within private subdomains and >none can be found in public site lists. Then use full domain names in the news path header, not just short names. This is particularly important if you have large #s of internal workstations and you don't want to try to make them unique. Fully qualified names (like datapg.mn.org) are going to be unique for a long time. --Ed
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (08/18/88)
sewilco@datapg.MN.ORG writes:
News sites with the same name are invisible to each other.
Articles from one site "xyz" are not sent to a second site "xyz" because
the first "xyz" is found in the "Path" line. This is particularly bad
because all sites "xyz" may be hidden within private subdomains and
none can be found in public site lists.
Why not just have fully-qualified domain names in the Path: header?
This eradicates the problem entirely. We found it necessary to make
sure we were doing this, because we have one of the (many) "tut"s on
the network, but the "real" "tut" (in terms of UUCP map registration)
is tut.fi, across the pond in Finland. Many months ago we did
appropriate things to defs.h to force the inclusion of full domain
names in all of our hosts' postings. The result is Path: headers
which sometimes get extraordinarily long (look at this article,
NNTP-posted from my Sun 3/50 through our Tut, sigh), but they are
unquestionably fully-qualified and unique.
--Karlsewilco@datapg.MN.ORG (Scot E Wilcoxon) (08/20/88)
In article <20246@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >sewilco@datapg.MN.ORG writes: > News sites with the same name are invisible to each other. > >Why not just have fully-qualified domain names in the Path: header? To keep the Path: header from becoming inconveniently long. This might be defined as either "too large for a buffer" or "longer than the text of the message". -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco Proud owner of a new power supply. The previous one blinked blue-white. "Have you ever been kissed by lightning?" -- 'So you wanted to meet the wizard'
emv@mailrus.cc.umich.edu (Edward Vielmetti) (08/20/88)
In article <1474@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes: >In article <20246@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >>sewilco@datapg.MN.ORG writes: >> News sites with the same name are invisible to each other. >> >>Why not just have fully-qualified domain names in the Path: header? > >To keep the Path: header from becoming inconveniently long. This >might be defined as either "too large for a buffer" or "longer than >the text of the message". True enough. Long path names are a problem. As matt@oddjob proved some time this summer (matt?) there's a point at which the long path line will cause the existing news software to break. I don't think it was # of hops, more like total character length (on the order of 3 lines or 240 characters as I recall.) Even if the existing news software works, the longer the paths in terms of # of hops and also # of characters the harder it is for people with brain-dead news software and mailers (i.e. without INTERNET defined) to reply to news postings easily. That describes most of the AT&T news network, for instance. I doubt that the addition of 7 characters to your name will make a big difference, considering the leaf-ness of your site. But people like Karl who shoot a lot of news around with 22 character site names might make a dent in the limits some time, if the net grows too big. The real problem is that "the net is getting too big", or at the very least it's not unlikely that path lengths will grow, not shrink, in the near future. That is, unless you take action to keep them in check. What you can do to help this situation out in the long run is to be sure that your own articles get propogated as widely and cheaply as possible. One good metric of this is "how many hops does it take my posting to get to uunet?" (I'm guilty in this respect - we stopped feeding uunet when umix, our aging vax, started to have mail back up because of news feeds, thus violating the Prime Directive.) If you know that you're one or two or even three hops away from uunet, you could have a system name like starbarlounge.upie.cc.umich.edu and no one would bat an eye. If you're on the internet, and you have multiple feeds with NNTP, and you've noticed that some of them "aren't worth it" because you never end up sending any articles across that link - that's a perfect opportunity to cut down the size of the network. Reduce the link to an L4 or L5 style connection instead of a full feed, and you'll have only relatively local traffic pass over that connection. That'll reduce load on both machines, not queueing up articles that don't have a good chance of being accepted on the far end. I'm cross posting this to news.config because it's not just a software issue, it's a topology issue. --Ed usenet news admin, U of Michigan. (mailrus - 7 characters, not bad....)
chip@vector.UUCP (Chip Rosenthal) (08/20/88)
In article <20246@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >Why not just have fully-qualified domain names in the Path: header? This breaks crufty, old software which uses "Path" rather than "From" for mailed responses. However, I'm not sure whether this is an argument *for* or *against* such a change. -- Chip Rosenthal chip@vector.UUCP | I've been a wizard since my childhood. Dallas Semiconductor 214-450-0486 | And I've earned some respect for my art.
hokey@plus5.UUCP (Hokey) (08/21/88)
I haven't been following this discusison all that carefully, but has anybody else considered that the problem would disappear if articles were only posted from or relayed between registered sites? This is a simple matter of administration. Unregistered leaf sites can cause articles to be posted from their registered hub using mail. -- Hokey
henry@utzoo.uucp (Henry Spencer) (08/21/88)
In article <527@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: >>Why not just have fully-qualified domain names in the Path: header? > >This breaks crufty, old software which uses "Path" rather than "From" for >mailed responses. Actually, it breaks it only if that site's neighbors do not recognize the fully-qualified form. Unfortunately, there are still a lot of sites that don't. >However, I'm not sure whether this is an argument *for* >or *against* such a change. Against. There are many people who, for one reason or another, not only haven't upgraded their software but *CAN'T*. Cutting them off the net as punishment for their unfortunate circumstances is unacceptable. (No, the availability of public-domain software doesn't solve the problem. Some sites are politically required to run the system "straight out of the box"; others could make changes but don't have anyone competent to do it.) -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.UUCP (Peter da Silva) (08/22/88)
How about a smart application of domainised paths? If you have a domain name, or are registered, check the path. Only put your full name in if nobody has already. So, if you're tut.cis.ohio-state.edu, and the path looks like: Path: zardoz.omaha.nebraska.us!luser Then you just tack your uucp name on, but if it looks like: Path: weerd!flamer!myibmpc!luser Then you tack on the whole thing... That way, paths would have at least one valid, reachable, name. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" sugar.uu.net!ficc!peter.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (08/23/88)
emv@mailrus.cc.umich.edu writes:
True enough. Long path names are a problem.
Not in terms of the software. I just grep'd the Path: header out of
971 articles in comp.unix.wizards and stuffed them through `wc.' The
result is an average Path: length of a fraction over 80 chars/line.
That's including the "Path: " text, so make it 74 chars/line of actual
hostname-and-!'s. Allowing for deeply `leafed' nodes might knock that
average length up to, say, 120.
In the news software, src/header.h defines the max length as char
path[PATHLEN], where src/defs.h contains
#define PATHLEN 512 /* length of longest source string */
and thus we could quadruple or quintuple the length of a Path: header
before breaking software.
If the metric is intead "longer than the text of the article," then
the much larger problem is that every news article carries around 8 or
10 lines worth of stuff to keep track of a 2-line comment. Longer
Path: lines are not significant in the face of all those other
headers.
--Karlwoods@ncar.ucar.edu (Greg Woods) (08/23/88)
In article <1474@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes: >In article <20246@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >>Why not just have fully-qualified domain names in the Path: header? > >To keep the Path: header from becoming inconveniently long. I decided to get the best of both worlds, and have fully-qualified names from our internal hosts, but just make sure our gateway host (ncar) is unique so I don't have to fully qualify it too. Thus, a path like the one in Karl's posting will, if it comes from us, have our domain name in it only once. The second is redundant. Including it once is, however, necessary. It is simply not possible to keep all our names unique. For example, you might see: Path: ...!ncar!groucho.ucar.edu!poster From: poster@groucho.ucar.edu In this case I have to qualify "groucho" because AT&T already has a registered uucp host named "groucho", and this way they are distinguishable. In other cases there are name conflicts with other UUCP hosts and our internal ones, and in some cases there aren't, but I don't have to keep track of that. Only the gateway name has to be unique. So, it is NOT necessary to qualify "ncar" because that name belongs to us in the UUCP maps. So you WON'T see "...!ncar.ucar.edu!groucho.ucar.edu!poster", nor should you have to. --Greg
jef@ace.ee.lbl.gov (Jef Poskanzer) (08/23/88)
In the referenced message, henry@utzoo.uucp (Henry Spencer) wrote: }>>Why not just have fully-qualified domain names in the Path: header? } } There are many people who, for one reason or another, not only }haven't upgraded their software but *CAN'T*. Cutting them off the net as }punishment for their unfortunate circumstances is unacceptable. That may be unacceptable, but requiring all Usenet sites to have uucp-unique names is *impossible*. NNTP sites such as this one have absolutely nothing to do with uucp. Anyway, there are plenty of other reasons (besides domains) that using Path: to route mail replies loses. --- Jef Jef Poskanzer jef@rtsg.ee.lbl.gov ...well!pokey And now, back to the news.
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/23/88)
In article <616@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >In article <1474@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes: >>In article <20246@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >>>Why not just have fully-qualified domain names in the Path: header? >>To keep the Path: header from becoming inconveniently long. > >...Only the gateway name has to be unique. So, it is NOT necessary to >qualify "ncar" because that name belongs to us in the UUCP maps. So >you WON'T see "...!ncar.ucar.edu!groucho.ucar.edu!poster", nor should >you have to. Agreed - that's the way we do it, too. Our UUCP gateway machine is registered in the maps as "osu-cis", and inserts !osu-cis! in Path: lines as they pass through. None of our other internal machines are registered in the maps, so they insert their fully-qualified names. Our NNTP hub, which is different from our UUCP gateway, isn't registered in the maps, so it inserts its full name in Path: lines. Similarly, other departments at Ohio State exchange news with us via NNTP, and most aren't registered, so they'll put their full names. So if you receive news from someone in EE that passed through osu-cis, it will have a Path: that looks like osu-cis!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!bagheera.eng.ohio-state.edu!user before it even makes it out the door. There's really no other way. Static size limits are a bad thing. Path: line lengths are only one example of why. -=- --Bob Content: 80% POLYESTER, 20% DACRON.. The waitress's UNIFORM sheds TARTAR SAUCE like an 8'' by 10'' GLOSSY..
henry@utzoo.uucp (Henry Spencer) (08/23/88)
In article <817@ace.ee.lbl.gov> Jef Poskanzer <jef@rtsg.ee.lbl.gov> writes: >Anyway, there are plenty of other reasons (besides domains) that using Path: >to route mail replies loses. Quite true, but many people have no alternative. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/25/88)
In article <1290@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >How about a smart application of domainised paths? > >If you have a domain name, or are registered, check the path. Only >put your full name in if nobody has already. >... >That way, paths would have at least one valid, reachable, name. But Path: lines aren't to be used for mail replies, only as an audit trail ("Don't put that in your mouth, you don't where it's been!" :-) to describe the path of the article. If the Path: already contains a fully-qualified domain name and I therefore don't add to it, then the connectivity information is lost. There might as well be no Path: line. If you need a valid, reachable address for mail, you're supposed to use the From: line. Similarly, you're not supposed to put anything else in a From: line. We must be taking a lonely stance on this one - we're starting to be used as a counterexample :-). -=- --Bob He probably just wants to take over my CELLS and then EXPLODE inside me like a BARREL of runny CHOPPED LIVER! Or maybe he'd like to PSYCHOLIGICALLY TERRORISE ME until I have no objection to a RIGHT-WING MILITARY TAKEOVER of my apartment!! I guess I should call AL PACINO!
peter@ficc.uu.net (Peter da Silva) (08/25/88)
In article <20673@tut.cis.ohio-state.edu>, bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > But Path: lines aren't to be used for mail replies, only as an audit > trail ("Don't put that in your mouth, you don't where it's been!" :-) Well, if the mailpaths file worked right, there would be no problem. Unfortunately, mailpaths doesn't work. In fact, if you use GENERICPATH and INTERNET together, it tries to send local mail to your internet location (because it doesn't figure out that site.domain and site match). This also causes problems for cancel(). Where does one get 3.0 or C news? Anyway, cheap or segmentised sites have to depend on the path. > We must be taking a lonely stance on this one - we're starting to be > used as a counterexample :-). You were a handy example, suitable for cutting and pasting. -- Kent Paul Dolan/Zippy the Pinhead in '92. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" sugar.uu.net!ficc!peter.
ane@hal.UUCP (Aydin "Bif" Edguer) (08/25/88)
In article <20673@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > In article <1290@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > > If you have a domain name, or are registered, check the path. Only > > put your full name in if nobody has already. > > That way, paths would have at least one valid, reachable, name. > If the Path: already contains a fully-qualified domain name and > I therefore don't add to it, then the connectivity information is lost. > There might as well be no Path: line. Bob, you didn't quite read Peter correctly I think. He said only put your full name if no one has. Otherwise just use your short uucp name. You still appear in the Path: line, no connectivity information has been lost BUT only a short name (up to 7 chars rather than say 22 chars as in tut.cis.ohio-state.edu) has been added to the path. I do not think he was saying add nothing to the path. > But Path: lines aren't to be used for mail replies, only as an audit > trail ("Don't put that in your mouth, you don't where it's been!" :-) > to describe the path of the article. That is the only reason why this would be okay. However, I don't completely agree that Path: lines are not used for mail replies. If you have a smart mailer (smail w/pathalias) or a convenient smarthost (uunet) who has agreed to be your smarthost then Path: is an audit. In the default configuration though, Path: is used for mail replies, and thus MUST BE VALID. If the host ONLY responds to its fully qualified domain name then it SHOULD use it. With that additional qualification, I agree with Peter. > We must be taking a lonely stance on this one - we're starting to be > used as a counterexample :-). Your great connectivity helps to get you noticed. Along with fame comes notoriety :-) Aydin Edguer hal!ane or ane@hal.cwru.edu
peter@ficc.uu.net (Peter da Silva) (08/25/88)
I just rewrote the replyname function in funcs2.c to do a better job of
hacking the mailpaths file. This is only useful for people who have
INTERNET defined, and of course it's missing all the special code that
the Sun people put in to handle .OZ...
It also makes the assumption that the first element of the path is
the site name, but that seems safe.
----/*SNIP SNIP */----
char *
replyname(hptr)
struct hbuf *hptr;
{
register char *name;
register char *ptr;
static char user[PATHLEN], path[PATHLEN];
static char buf[PATHLEN], fmt[PATHLEN];
FILE *mfd;
int found;
/* Figure out where to send mail */
if (hptr->replyto[0])
name = hptr->replyto;
else if (hptr->from[0])
name = hptr->from;
else { /* Should never happen */
name = strchr(hptr->path, '!');
if(!name)
name = hptr->path;
}
/* Remove (User name @ Organisation) */
strcpy(buf, name);
name = buf;
if(ptr = index(name, ' '))
*ptr = 0;
/* break it up into path/site and name */
if(ptr = index(name, '@')) {
strncpy(user, name, ptr-name);
user[ptr-name] = 0;
strcpy(path, ptr+1);
} else if(ptr = rindex(name, '!')) {
strcpy(user, ptr+1);
strncpy(path, name, ptr-name);
path[ptr-name] = 0;
} else /* A local */
return name;
sprintf(buf, "%s/mailpaths", LIB);
mfd = xfopen(buf, "r"); /* Should probably do an fopen,
and just return path if not found.
This would make INTERNET unnecessary */
/* If all else fails, fall back on the path */
name = strchr(hptr->path, '!');
if(!name)
name = hptr->path;
/* Look for my path */
while(fgets(buf, sizeof buf, mfd)) {
if(PREFIX(buf, path)) {
sscanf(buf, "%*s %s", fmt);
sprintf(buf, fmt, user);
name = buf;
break;
} else if(PREFIX(buf, "internet")) { /* Should be last entry */
sscanf(buf, "%*s %s", fmt);
strcat(path, "!");
strcat(path, user);
sprintf(buf, fmt, path);
name = buf;
break;
}
}
return name;
}
--
Peter da Silva `-_-' Ferranti International Controls Corporation.
"Have you hugged U your wolf today?" peter@ficc.uu.netbob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/26/88)
In article <281@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >Bob, you didn't quite read Peter correctly I think. That's entirely possible. >He said only put your full name if no one has. Otherwise just use >your short uucp name. There are several problems with that: feasibility (for UUCP-only sites) and cost (for name resolver-capable sites) to validate that upstream name, and the fact that only one of our machines is registered in the UUCP maps, though that with a short name. > > But Path: lines aren't to be used for mail replies, only as an > > audit trail ("Don't put that in your mouth, you don't where it's > > been!" :-) to describe the path of the article. > >That is the only reason why this would be okay. However, I don't >completely agree that Path: lines are not used for mail replies. If >you have a smart mailer (smail w/pathalias) or a convenient smarthost >(uunet) who has agreed to be your smarthost then Path: is an audit. >In the default configuration though, Path: is used for mail replies, >and thus MUST BE VALID. I can only stand on the comments in section 2.1.6 of RFC 1036 (Horton and Adams, December 1987) on the Path line. To excerpt: This line shows the path the message took to reach the current system. ... The "Path" line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message traveled to reach the local host. ... [though unfortunately] ... Special upward compatibility note: Since the "From", "Sender", and "Reply-To" lines are in Internet format, and since many USENET hosts do not yet have mailers capable of understanding Internet format, it would break the reply capability to completely sever the connection between the "Path" header and the reply function. [but still] It is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. So, use of Path: instead of Reply: is described as a recognized and tolerated thing that people out there tend to do, especially those with older versions of the software. Even those older versions may not do it right to help each other. Path: is used for replies in the default configuration of 2.11 if you leave INTERNET undefined, but there's no reason not to define INTERNET if you have LIBDIR/mailpaths set up correctly. Maintenance of valid mail links in the Path: line is encouraged, but not required. It's even common these days for the link not to exist in a form usable for UUCP mail. For example, your note, as it arrived on our system, has a Path line like tut.cis.ohio-state.edu!cwjcc!hal!ane, but there's no UUCP connection between OSU and Case. It came across NNTP. Oh well, this is going on far too long and not really getting anywhere. It's sounding too much like a religious argument when someone has to resort to excerpting quotations of scriptures :-) -=- --Bob YOW!! What should the entire human race DO?? Consume a fifth of CHIVAS REGAL, ski NUDE down MT. EVEREST, and have a wild SEX WEEKEND!
emv@mailrus.cc.umich.edu (Edward Vielmetti) (08/26/88)
In article <20729@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > >So, use of Path: instead of Reply: is described as a recognized and >tolerated thing that people out there tend to do, especially those >with older versions of the software. Even those older versions may >not do it right to help each other. Path: is used for replies in the >default configuration of 2.11 if you leave INTERNET undefined, but >there's no reason not to define INTERNET if you have LIBDIR/mailpaths >set up correctly. > >Maintenance of valid mail links in the Path: line is encouraged, but >not required. It's even common these days for the link not to exist >in a form usable for UUCP mail. For example, your note, as it arrived >on our system, has a Path line like >tut.cis.ohio-state.edu!cwjcc!hal!ane, but there's no UUCP connection >between OSU and Case. It came across NNTP. Is "older versions of the software" also a reference to the uucp that you're running on tut? If you have t protocol support, it's real easy for the Path: line to be a replyable one. One alternative that no one has mentioned from the RFC is this one, which would break I don't know how much software: tut.cis.ohio-state.edu, cwjcc!hal!ane A quote from Scripture: "Letters, digits, periods and hyphens are considered part of host names; other puncutation, including blanks, are considered separators." As I say, I hate to think how much software relys on a "!" character, but any other separator is legal. --Ed Edward Vielmetti, usenet news admin, U of Michigan. Obligatory anti-Ohio slur: Columbus: South until you smell it, east until you step in it.
henry@utzoo.uucp (Henry Spencer) (08/26/88)
In article <20673@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >But Path: lines aren't to be used for mail replies, only as an audit >trail ... >If you need a valid, reachable address for mail, you're supposed to >use the From: line... That's the theory. The practice is somewhat different. (Don't forget the use of Path: for loop prevention, too.) -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
david@ms.uky.edu (David Herron -- One of the vertebrae) (08/27/88)
Another way to get short path names is to get yourself lots of news
feeds ... it does wonders!
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- Problem: how to get people to call ...; Solution: Completely reconfigure
<---- your mail system then leave for a weeks vacation when 90% done.