clp@Altos.COM (Chuck L. Peterson) (06/08/89)
When sending mail from here to places on the Internet such as user@machine.berkeley.edu, pathalias gives me this path: uunet!mtxinu!ucbvax!machine.berkeley.edu!user Clearly, the optimal route is: uunet!machine.berkeley.edu!user The funadamental flaw in the smail system I have (2.5), is that it assumes the only way to domains such as berkeley.edu is via uucp to the domain's main machine; "ucbvax.UUCP" in this case. I'm pretty sure this isn't just a problem with the ucbvax map entry since most Internet sites with map entries work this way. (They can't all be wrong, right?) Sure, uunet can do some bogus optimization by realizing this, but I think we've decided this is not a good idea. Or is this all just a problem with the way my stuff is set up... Chuck L. Peterson clp@altos.com
davidsen@sungod.crd.ge.com (William Davidsen) (06/08/89)
In article <1207@altos86.UUCP> clp@Altos.COM (Chuck L. Peterson) writes: | The funadamental flaw in the smail system I have (2.5), is that | it assumes the only way to domains such as berkeley.edu is via | uucp to the domain's main machine; "ucbvax.UUCP" in this case. Maybe. Have you specified the cost correctly? As I recall there is code in pathalias which avoids doing a connect between a machine with internet style addressing and one with bang addressing. You might find and disable this. I assume that if you have internet connections you are using the -l flag to route them back to sendmail. We are using smail2.5 and are getting mostly the routes we expect. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jbuck@epimass.EPI.COM (Joe Buck) (06/09/89)
In article <1207@altos86.UUCP> clp@Altos.COM (Chuck L. Peterson) writes: >When sending mail from here to places on the Internet such as >user@machine.berkeley.edu, pathalias gives me this path: > uunet!mtxinu!ucbvax!machine.berkeley.edu!user > >Clearly, the optimal route is: > uunet!machine.berkeley.edu!user > >The funadamental flaw in the smail system I have (2.5), is that >it assumes the only way to domains such as berkeley.edu is via >uucp to the domain's main machine; "ucbvax.UUCP" in this case. This is not a flaw in the smail system; it's a flaw in the UUCP map data. Specifically, since .berkeley.edu is an Internet domain, it should not be listed in the UUCP map, and neither should any host foo.berkeley.edu. This would make the map smaller, and furthermore, smail will then generate the optimal route you describe, provided that you have the line .edu uunet!%s in your /usr/lib/uucp/paths. Let's delete all domains that are on the Internet from the UUCP map. The map will get smaller and we'll actually generate better routes. -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
davidsen@sungod.crd.ge.com (William Davidsen) (06/13/89)
In article <3288@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: | This is not a flaw in the smail system; it's a flaw in the UUCP map | data. Specifically, since .berkeley.edu is an Internet domain, | it should not be listed in the UUCP map, and neither should any | host foo.berkeley.edu. This would make the map smaller, and | furthermore, smail will then generate the optimal route you describe, | provided that you have the line | | .edu uunet!%s | | in your /usr/lib/uucp/paths. | | Let's delete all domains that are on the Internet from the UUCP map. | The map will get smaller and we'll actually generate better routes. Let's not get carried away here, sending from a machine on the west coast all the way to uunet and then back via internet to Berkeley is not usually the best way to do things. There should be a better way to get to ucbvax than uunet, starting in CA. What we need is to change pathalias to reduct the cost of a transition between nets, and thus generate better maps. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jbuck@epimass.EPI.COM (Joe Buck) (06/13/89)
In article <742@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Let's not get carried away here, sending from a machine on the west >coast all the way to uunet and then back via internet to Berkeley is not >usually the best way to do things. There should be a better way to get >to ucbvax than uunet, starting in CA. The person I was replying to said he wanted things to go through uunet, suggesting that it was near him. Here are the official gateways for the domains .arpa, .com, .gov, .mil, .edu, .org, .net, and .us from UUCP-land: apple, cornell, decwrl, harvard, rutgers, talcott, ucbvax, uunet If my suggestion (about removing .foo.edu and host.foo.edu and so forth from the map for Internet sites) were taken, and it's cheaper for you to get to Berkeley than to uunet, your map data might have .edu ucbvax!%s instead of .edu uunet!%s > What we need is to change pathalias to reduct the cost of a transition >between nets, and thus generate better maps. As designed, pathalias doesn't know, when generating routes, that there is any relation between .com, .foo.com, and .bar.foo.com. If it is changed, we would need an indication of whether a subdomain is connected to the main domain gateway by a fast network or a slow one. Given the existing pathalias program and the cost of sending comp.mail.maps around, I'd rather encourage proposals to decrease its size than to increase it. -- -- Joe Buck jbuck@epimass.epi.com, uunet!epimass.epi.com!jbuck
Makey@LOGICON.ARPA (Jeff Makey) (06/14/89)
In article <742@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > What we need is to change pathalias to reduct the cost of a transition >between nets, and thus generate better maps. No change to pathalias is needed. Sites who are willing to serve as Internet<-->UUCP gateways can simply show a suitably low-cost two-way connection to a phantom host called, say, "internet". A good cost for the connection would be (ARPA/2). Thus, gateways could add the following to their map entries: gateway internet(ARPA/2) internet gateway(ARPA/2) Conveniently, there is currently no host named "internet" in the UUCP map. These gateway hosts would have to fix their mailers to deal with the inevitable paths of the form ...!gateway1!internet!gateway2!..., but a simple sendmail rule will do the trick. And sites would only do this on a voluntary basis. Is this a good idea? Are there any better ones? :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
david@ms.uky.edu (David Herron -- One of the vertebrae) (06/19/89)
In article <3307@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >In article <742@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >> Let's not get carried away here, sending from a machine on the west >>coast all the way to uunet and then back via internet to Berkeley is not >>usually the best way to do things. There should be a better way to get >>to ucbvax than uunet, starting in CA. So make a UUCP link with one of the west coast machines who does gatewaying ... But I'm really replying to Joe ... ... >If my suggestion (about removing .foo.edu and host.foo.edu and so forth >from the map for Internet sites) were taken, and it's cheaper for you >to get to Berkeley than to uunet, your map data might have > >.edu ucbvax!%s > >instead of > >.edu uunet!%s That extra information is there for a purpose. It's so that specific parts of domain name space can declare gateways for themselves which might possibly be "more efficient". It reduces load on the Official .edu type gateways. Etc, etc, etc. >> What we need is to change pathalias to reduct the cost of a transition >>between nets, and thus generate better maps. > >As designed, pathalias doesn't know, when generating routes, that there >is any relation between .com, .foo.com, and .bar.foo.com. I do see that a small change might be made to improve things. Consider a case where you have a .edu gateway and .podunk.edu gateway. To reach the .edu one "costs", say, 100 and the .podunk.edu one "costs" 10,000. In that cast it's probably better to go by way of the .edu gateway. I'm not proposing that someone teach pathalias about domains. This could be handled by a script of some sort, like run pathalias in the mode which generates costs as well as routes save the output in "paths1" look through paths1 doing if it doesn't have a ".", continue /* we know it's some domain name */ look through the list of already known gateways and if we find one whose name is a "superset" of this one, then delete this route from paths1 (superset means ".edu" is-superset-of ".podunk.edu") But what do you do with .uucp hosts. How does one decide if you want to run such a script? Or should everybody? The danger I see is that, if everyone ran this script that some routing loop might happen. Oh, I see, the gateway site will have to delete themselves from the list of sites doing gatewaying before they do *their* pathalias run. (Erik, is the script I described up there the one you say you wrote last fall?) -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New word for the day: Obnoxity -- an act of obnoxiousness
davidsen@sungod.crd.ge.com (William Davidsen) (06/20/89)
In article <3183@sun.soe.clarkson.edu> ahd@sun.soe!clutx.clarkson.edu writes: | I would not call it a flaw. Rather, it avoids use of the internet | because the internet HAS NOT AGREED to be a backbone for UUCP traffic. The change was put in pathalias in January 1985, in V6. I don't have the posting anymore (yes I do throw something away) but my recollection is that the change was not added for any high and lofty moral reason, but because a hybred address usually broke mailers to the point that the mail might not go through at all. The code in question is in mapit.c in the 'costof' module. I have generated maps with this code disabled, but I only loked at the output and did not try using it. Mailers are a lot better than they were five years ago, and these might well work. Obviously the poster who said that it's a bug in pathalias not a feature has never looked at the code or the documentation. Not using mixed addresses was promoted as one of the reasons to upgrade to V6. You may not like what it does, bvut it works as designed. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
bill@twwells.com (T. William Wells) (06/20/89)
In article <11938@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: : I'm not proposing that someone teach pathalias about domains. This could : be handled by a script of some sort, like : : run pathalias in the mode which generates costs as well as routes : save the output in "paths1" : look through paths1 doing : if it doesn't have a ".", continue : /* we know it's some domain name */ : look through the list of already known gateways and : if we find one whose name is a "superset" of : this one, then delete this route from paths1 : (superset means ".edu" is-superset-of ".podunk.edu") I run the following program on my system as a postprocessor on sorted pathalias output. If you have b.a and .a in the pathalias output, b.a goes away. Due to the particular connectivity for my site, I do not need to consider the cost of b.a vs. .a, but for a general system, one should. The program isn't wonderfully efficient, but the time it takes is negligible nonetheless. This program is freshly written and has not been cleaned up other than to remove lint. There are, as you can see, no comments. Caveat Usor! ------------------------------cut here---------------------------------------- #include <stdio.h> #include <string.h> /* Copyright 1989 by T. William Wells, bill@twwells.com. All Rights Reserved. You can do anything you want with this code, except alter or remove the copyright notice. */ extern char *malloc(); extern void free(); typedef struct GATE { struct GATE *g_next; char *g_site; char *g_path; } GATE; char Buffer[1024]; char *Path; int Sitelen; GATE *Gatelist; void addgate(); void printgate(); int main() { while (gets(Buffer)) { Path = strchr(Buffer, '\t'); Sitelen = Path - Buffer; *Path++ = 0; if (!hasgate()) { if (Buffer[0] != '.') { break; } addgate(); } } printgate(); if (feof(stdin)) { exit(0); } puts(Buffer); while (gets(Buffer)) { Path = strchr(Buffer, '\t'); Sitelen = Path - Buffer; *Path++ = 0; if (!hasgate()) { printf("%s\t%s\n", Buffer, Path); } } exit(0); /*NOTREACHED*/ } char * myalloc(size) int size; { char *ptr; if (!(ptr = malloc((unsigned)size))) { fprintf(stderr, "Out of memory.\n"); exit(1); } return (ptr); } char * stralloc(str) char *str; { char *ptr; ptr = myalloc(strlen(str) + 1); strcpy(ptr, str); return (ptr); } int hasgate() { register GATE *gp; register char *ptr; ptr = Buffer + Sitelen; while (1) { while (ptr > Buffer && *--ptr != '.') ; if (ptr == Buffer) { return (0); } for (gp = Gatelist; gp; gp = gp->g_next) { if (strcmp(ptr, gp->g_site) == 0) { return (1); } } } } void addgate() { register GATE *gp; register GATE *gp1; int n; gp1 = 0; for (gp = Gatelist; gp; ) { n = strlen(gp->g_site); if (n < Sitelen || strcmp(gp->g_site + n - Sitelen, Buffer) != 0) { gp1 = gp; gp = gp->g_next; continue; } if (gp1) { gp1->g_next = gp->g_next; } else { Gatelist = gp->g_next; } free(gp->g_site); free(gp->g_path); free((char *)gp); if (gp1) { gp = gp1->g_next; } else { gp = Gatelist; } } gp = (GATE *)myalloc(sizeof(GATE)); if (gp1) { gp1->g_next = gp; } else { Gatelist = gp; } gp->g_next = 0; gp->g_site = stralloc(Buffer); gp->g_path = stralloc(Path); } void printgate() { GATE *gp; for (gp = Gatelist; gp; gp = gp->g_next) { printf("%s\t%s\n", gp->g_site, gp->g_path); } } ------------------------------cut here---------------------------------------- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com
ulmo@ssyx.ucsc.edu (Brad Allen) (07/22/89)
[what UUCP Map & pathalias gives:] > uunet!mtxinu!ucbvax!machine.berkeley.edu!user > Clearly, the optimal route is: > uunet!machine.berkeley.edu!user It is a flaw in the UUCP Mapping project. If it weren't, then I would know why it wasn't because the UUCP Mapping project would have told me why not (as a user) and how to do it right. As it is, it is fairly flawed. The way I have found to fix this is something like this, and though it is a fairly exhaustive task in the beginning, it does have the desired result: [Most of this is extremely incomplete, and although I'm sure it would help my corner of the world a bit for pathalias, it deserves many more nets and hosts listed.] ### pathalias input INTERNET={ ARPANET, NSFNET, MILNET, CSNET }(130) ARPANET={ someuucphost.arpa }(150) NSFNET={ BARRNET }(110) BARRNET={ UCSC-NET, Berkeley-NET, SU, Apple-NET, SRI-NET }(105) SRI-NET={ UNIX.SRI.COM } (LOCAL) Apple-NET={ Apple.com }(LOCAL) Berkeley-NET={ ucbvax.berkeley.edu, ucbarpa.berkeley.edu, jade.berkeley.edu, agate.berkeley.edu }(100) UCSC-NET={ ucscc.ucsc.edu, ssyx.ucsc.edu }(LOCAL) # No host should be listed in the UUCP Maps here which does not understand UUCP # bang notation and accept it -- i.e. the leaf nodes listed in this network tree # are basically UUCP & Internet hosts. (I could explain this better, but # I don't feel like it now for the zillionth time.) # All IP hosts listed in UUCP Maps would be incorporated into this. # This data should be processed with -i on the pathalias line, as all pathalias # data should. # I did something like this I think and it worked very nicely: INTERNET .AR(120), .ARPA(120), .AT(120), .AU(120), .BE(120), .BR(120), .CA(120), .CH(120), .CL(120), .COM(120), .DE(120), .DK(120), .EDU(120), .ES(120), .FI(120), .FR(120), .GOV(120), .GR(120), .IE(120), .IL(120), .IN(120), .INT(120), .IS(120), .IT(120), .JP(120), .KR(120), .MIL(120), .MX(120), .MY(120), .NET(120), .NL(120), .NO(120), .NZ(120), .ORG(120), .PT(120), .SE(120), .SG(120), .TH(120), .UK(120), .US(120), .YU(120), # Well, I forget whether the (120) was good or not. I could look into this # further. Pathalias also understands other mechanisms dealing with # ".domain", which ought to be explored a little ... Notes: This is only an example. It is not necessarily fit for installation. I have done somewhat more exhaustive work on this before, about five times, and each time I lost the data (host goes down, crashed disk, editor mishap, mean administrator, etc.) Someone should probably sit down and give this some thought and organize this into the main UUCP Map distribution. (I volunteer if people think this is needed and no one else does it.) I think it would be appropriate if the current UUCP Maps listed a d.Internet or something which basically defined all this stuff. While a bit of cross-updating between two networks would ensue, it would not entail too great an effort since the only hosts listed would be gateways hosts, where you would usually have to do redundant updating someplace anyway. Things >would< be easier if all UUCP hosts had happy free Internet neighbors within a fast free modem phone call away, and had domains with MX's pointing to the Internet host, etc. etc. etc. But right now there are still messy areas. As it is, I see lots and lots and lots of multiple Internet hops, trans-continental and international crossings as result of UUCP maps, which would mostly disappear except where appropriate with this addition.
lamy@ai.utoronto.ca (Jean-Francois Lamy) (07/22/89)
In article <27059@lll-winken.LLNL.GOV> ulmo@ssyx.ucsc.edu (Brad Allen) writes: > I see lots and lots and lots of multiple Internet hops, >trans-continental and international crossings as result of UUCP maps, >which would mostly disappear except where appropriate with this addition. Assuming that the internet is mostly homogeneous is premature; sometimes there is considerable fudging of map entries so that traffic travels only through internet sites that can compensate for each other's quirks. For example, we keep two UUCP over TCP mail connections to Internet sites because that way we can avoid fighting over religion about ! address rewriting. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
ahd@sun.soe.clarkson.edu.UUCP (07/22/89)
From article <27059@lll-winken.LLNL.GOV>, by ulmo@ssyx.ucsc.edu (Brad Allen): > [what UUCP Map & pathalias gives:] >> uunet!mtxinu!ucbvax!machine.berkeley.edu!user >> Clearly, the optimal route is: >> uunet!machine.berkeley.edu!user > > It is a flaw in the UUCP Mapping project. If it weren't, then I would know why > it wasn't because the UUCP Mapping project would have told me why not > (as a user) and how to do it right. As it is, it is fairly flawed. Disclaimer... the following is personal opinion... and I don't have the supporting docs at hand. I would not call it a flaw. Rather, it avoids use of the internet because the internet HAS NOT AGREED to be a backbone for UUCP traffic. While the above use of the internet would be legal (berkeley being on the net), using the internet as a mail carrier between other networks is explicitly frowned upon by the those who rule. Since UUCP sites don't pay for those nice T1 links making up the Internet backbones, their view is not unreasonable. In practice, a message often starts on UUCP and ends up on Bitnet via NSFNET and CSNET, but wholesale (official routing) via the internet would get the net.police out in droves. Drew Derbyshire Clarkson University Class of 1989 (7 years late) Internet: ahd@clutx.clarkson.edu U.S. Mail: 578 Broadway, Apt 6 Voice: 914-339-7425 Kingston, NY 12401
mike@unmvax.unm.edu (Michael I. Bushnell) (08/02/89)
In article <3183@sun.soe.clarkson.edu> ahd@sun.soe!clutx.clarkson.edu writes: >From article <27059@lll-winken.LLNL.GOV>, by ulmo@ssyx.ucsc.edu (Brad Allen): >I would not call it a flaw. Rather, it avoids use of the internet >because the internet HAS NOT AGREED to be a backbone for UUCP traffic. >While the above use of the internet would be legal (berkeley being on >the net), using the internet as a mail carrier between other networks >is explicitly frowned upon by the those who rule. Not anymore -- see below... >Since UUCP sites don't pay for those nice T1 links making up the >Internet backbones, their view is not unreasonable. Actually, very few *internet* sites pay for such links either...most have grants...and that's only for the local link. The backbone links are not paid for directly by anyone... >In practice, a message often starts on UUCP and ends up on Bitnet via >NSFNET and CSNET, but wholesale (official routing) via the internet >would get the net.police out in droves. This is actually no longer true. It used to be that NIS -> IS -> IS -> NIS (NIS == Non internet site, IS == Internet site) with the central link over the internet was frowned upon. Not so any longer. The internet is now made up, substantially, of three categories of networks: MILNET, ARPANET, and NSFNET. All those regional networks are in the NSFNET category. The NSFNET policy is specifically to allow such traffic, since the NSFNET was created to increase general datacommunications, and it should do that even for those that are unable to connect. Connection, actually, is relatively cheap (all you have to pay for is your router and your leased line and a nominal fee). ARPANET is being phased out, so its policies really aren't relevant. MILNET *does* desire to restrict non-milnet traffic, but this is taken care of at a lower level: the level of IP packet routing. Unless one of the IS sites above is a milnet site and the NIS it is talking to is not directly associated with MILNET/DDN, the rules are being broken. However, the rules are being broken by that MILNET site, and not anyone else. When MILNET begins distributing the network costs among sites, presumably this will offer real incentive for such sites to follow the guidelines. The upshot is that almost all internet traffic now travels on networks supported by NSF, which has stated that use by non-internet sites is perfectly acceptable. -- Michael I. Bushnell \ This above all; to thine own self be true LIBERTE, EGALITE, FRATERNITE \ And it must follow, as the night the day, mike@unmvax.cs.unm.edu /\ Thou canst not be false to any man. Telephone: +1 505 292 0001 / \ Farewell: my blessing season this in thee!
davidsen@sungod.crd.ge.com (William Davidsen) (08/02/89)
In article <261@unmvax.unm.edu> mike@unmvax.cs.unm.edu (Michael I. Bushnell) writes: | Actually, very few *internet* sites pay for such links either...most | have grants...and that's only for the local link. The backbone links | are not paid for directly by anyone... Excuse me? Virtually all of the .com and .org sites pay for service. Take a look at the NYSERNET maps, see GE, Kodak, IBM. That's $30k/year or more per company (and in some cases there is added billing for additional sites of one company). The last time I looked the BITNET leased line was still paid for by us, too. This is not to mention internal nets we maintain which might carry traffic for some routing. | The upshot is that almost all internet traffic now travels on networks | supported by NSF, which has stated that use by non-internet sites is | perfectly acceptable. I'd like to see some figures for that, virtually all of the companies seem to be getting on these little regional networks, and even the universities are not all getting a free ride. Most of the schools in upstate NY are on NYSERnet, and while they get a discount, I haven't heard that they are getting NSF to pay the freight. NSF policy is not binding on paying customers. In practice it is usually permissible and customary for a paying site to carry mail, because the mail volume is so low compared to the ftp and telnet. Don't convince yourself that this is written in stone by NSF policy, though, it's a public service large companies perform, often because the bitbashers do it without telling anyone. Note that AT&T took great pain to disallow "through mail" on its sites, for all connections including uucp. I think you had better clarify which sites are bound by the NSF policy, assuming that it is still in effect (I believe it is). bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me