taylor@hplabsc.UUCP (02/27/87)
in news.sysadmin, David Lesher at ncoast.UUCP comments: > I regularly see posting [like] "I would have mailed but my mailer choked.." > Now the same thing often happens to me...it is very wasteful of net.money > would it not be worthwhile to devote some fraction of net.genuis/net.GOD > (s) resources to inventing better, more dependable, mailers? I will state something that might be viewed (inevitably) as controversial: the mail systems we have are fine. There is nothing wrong with them (hang on before you slam down that "F" key!) but rather what we're seeing is the problems of: 1. having a system that expects dynamic routing in a static routing universe (e.g. pathalias) 2. having this system phased out (e.g. the use of 'domains') 3. not having the new system implemented yet much of anywhere 4. some serious delusions about how reliable the software is going to be. What this means, I surmise, is that the main reason we're seeing people unable to reply to postings and/or get email addresses is that we've reached a point where people don't really want to mess with the pathalias style of addressing (the static routing system) and where we can't rely on 'core mail backbone' sites (like the ex-ihnp4) to reroute stuff based on real paths (the fake-dynamic routing that smail allows). At the same time, since there is a perceived need for domains as a way to break up our massive ".UUCP" domain into smaller, more manageable chunks, we're seeing hostnames that are from out of the twilight zone as far as any pathalias system is concerned ANYway. "hplabs.HP.COM" is a fine example of this... For reasons I shan't enter here, ignoring domain information on an electronic address (e.g. "hplabs.HP.COM" --> "hplabs") is a very bad idea... What we're supposed to end up with is a system that says "oohhh... you're sending mail to <hostname>.HP.COM (or <hostname>.<localdomain>.HP.COM) so I'll just send it to machine X". As we further and further subdivide the UUCP domain into pieces (.EDU, .STANFORD.EDU, CS.STANFORD.EDU, etc) we should theoretically see simpler and simpler delivery systems. In reality, however, I suspect that it'll be quite a bit further along before we 'shake out' the system and get some real reliability. There are some inherent problems with static routing information masquerading as dynamic routing information that are poised to attack... BUT as far as what we're talking about here, the best solution I can make is for people to have mail systems that grab not only the From: address in the posting, but the Path: address too, and read the Path: backwards until it finds a 'backbone' that it knows (you can have a file containing the 10 or 15 main ones, if you want) and then figures out the optimal (static, alas) route to that backbone. For example, your posting has the headers: Path: hplabsc!hplabs!hp-sdd!ncr-sd!ncrcae!ece-csc!mcnc!seismo!lll-lcc!ptsfa!ihnp 4!cbatt!cwruecmp!hal!ncoast!wb8foz From: wb8foz@ncoast.UUCP (David Lesher) First we should check the From: address and (as would really happen) figure out that we have no idea how to get email to ncoast.UUCP. So as an alternative plan, instead of dropping it there, we'd read the Path: line and start from the right, building up a longer and longer route until we find a host that we know we can get to: hal!ncoast!wb8foz cwruecmp!hal!ncoast!wb8foz cbatt!cwruecmp!hal!ncoast!wb8foz We know how to get to 'cbatt' (from hplabs it's simply via 'cbosgd') so we now have the address: cbosgd!cbatt!cwruecmp!hal!ncoast!wb8foz which is pretty reasonable. The advantage to this scheme is that it is indeed dynamic - it only finds routes that are actually those that have been taken in the past few days (assume current articles). The list of backbone sites could be as small as 20 or 30 and we'd be ok...(check the list in the Path: line above - there are 5 'backbones' in the route: hplabs, mcnc, seismo, ihnp4, and cbatt). Gee... neat idea. Maybe I should implement it or something. Anyone have any comments? -- Dave Taylor --
perry@vu-vlsi.UUCP (02/27/87)
In article <1354@hplabsc.UUCP> taylor@hplabs.HP.COM (Dave Taylor) writes: >.. >BUT as far as what we're talking about here, the best solution I can >make is for people to have mail systems that grab not only the >From: address in the posting, but the Path: address too, and read the >Path: backwards until it finds a 'backbone' that it knows (you can >have a file containing the 10 or 15 main ones, if you want) and then >figures out the optimal (static, alas) route to that backbone. >.. smail sort of does this in its REROUTE mode, but of course, it uses the whole pathalias map database, not just a file of 10 or 15 backbone routes. Most smail sites won't have REROUTE as the default for smail though, but I recently came up with a neat idea (or kludge, call it what you will...) to force rerouting when replying via mail to an article from rn. rn constructs the To: line from the Path: so for something like: To: hplabsc!hplabs!hp-sdd!...!cbatt!cwruecmp!hal!ncoast!wb8foz I would prepend a definitely unknown host name, like: To: xxxxxxxxx!hplabsc!hplabs!hp-sdd!...!cbatt!cwruecmp!hal!ncoast!wb8foz and smail, failing to route to host 'xxxxxxxxx' would start at the end, with ncoast, and work backwards until it found a route. The only small hassle with this is that the person receiving the mail sees the original To: line and probably wonders where site 'xxxxxxxxx' is! ...Rick ..{cbmvax,pyrnj,bpa}!vu-vlsi!perry perry@vuvaxcom.bitnet
dmc@videovax.UUCP (02/28/87)
In <1354@hplabsc.UUCP> Dave Taylor `don't need no steen'k'ng pathalias file'. And yes, there was a :-). The idea of shortening up some of the horrendous news `reply to' paths, when no other information is available, seems reasonable. But if I am being wicked and specifying a delivery path that avoids, say ihnp4, I don't want hplabs putting it back. And if I am being good and using domains, I should get decent path choosing. It seems his major beef is with the frequency of pathalias database updating. The example he chose was `ncoast.UUCP'. So I did a `pathto ncoast', and out of the pathalias database popped `...!cbosgd!cwruecmp!ncoast'. Which is two hosts shorter than the result obtained from shortening the news reply path. It seems Mr. Taylor's efforts would be better placed by implementing automatic updating of his pathalias database. -- Don Craig dmc@videovax.Tek.COM Tektronix Television Systems ... tektronix!videovax!dmc
loverso@sunybcs.UUCP (02/28/87)
In article <1354@hplabsc.UUCP> taylor@hplabs.HP.COM (Dave Taylor) writes: > BUT as far as what we're talking about here, the best solution I can > make is for people to have mail systems that grab not only the > From: address in the posting, but the Path: address too, and read the > Path: backwards until it finds a 'backbone' that it knows (you can > have a file containing the 10 or 15 main ones, if you want) and then > figures out the optimal (static, alas) route to that backbone. This would work except for the fact that the "Path:" header of a news article only describes news links. Assuming such links are bidirectional or that they carry mail is to lose big.
taylor@hplabsc.UUCP (03/01/87)
Donald M. Craig talks about a couple of things that I wasn't talking about in my posting: >But if I am being wicked and specifying a delivery path that avoids, say >ihnp4, I don't want hplabs putting it back. That's fine. I am not talking at all about dynamic re-routing. I'm talking about the situation that arises currently where people simply cannot reply to USENET postings because they have no idea how to get to the specified host. >The example he chose was `ncoast.UUCP'. So I did a `pathto ncoast', and >out of the pathalias database popped `...!cbosgd!cwruecmp!ncoast'. >Which is two hosts shorter than the result obtained from shortening >the news reply path. Okay. That's fine. Now go and tell me how many lines are in your pathalias database. I obtained the rewrite (which I freely admit isn't ideal by any means) by using a 'pathalias' file of *23* lines. In fact, I extracted ~350 arbitrary paths from our usenet archive and ran them through the program - 62% of them were shortened, an average of 3.94 hops. One route had *20* hops removed by noting that the machine two from the source was 'seismo'. Again, this is with a list of only 23 host routes... (which, of course, is tons easier to maintain too) > It seems Mr. Taylor's efforts would be better > placed by implementing automatic updating of his pathalias database. But this ignores the fundamental problems of the pathalias database solution to mail routing - 1. it is inherently a static system since people just do *not* update their individual host information on an hourly basis, 2. it is inherently static since there is a latency time between administrators saying "we have this connection" and the news being posted to 'the world', propagating around, and being fed to a program on my host, and 3. we are seeing a blossoming of hosts and are rapidly approaching the point where the pathalias stuff doesn't even make sense as a solution (hence one of the motivations behind moving to domains anyway) and are fooling ourselves if we think we can maintain 10,000+ *up-to-date* addresses... The scheme I'm proposing is a bandaid, for one thing, but is designed to use the inherently dynamic article Path: information. As I have said above, it certainly tends to improve the paths over simply using the Path: line for those hosts that aren't willing to spend the time and/or money to maintain the massive pathalias database. Furthermore, I think that we could arrive at a fine middle-of-the-road solution whereby there would be, say, a local pathalias file of no more than 100 hosts which would allow users to reply to USENET postings with an excellent chance that not only is the return address valid, but is also near to ideal. It's at least something to think about... I'll continue my experiments... *maniacal laugh* -- Dave Taylor
henry@utzoo.UUCP (Henry Spencer) (03/02/87)
> What we're supposed to end up with is a system that says "oohhh... > you're sending mail to <hostname>.HP.COM (or <hostname>.<localdomain>.HP.COM) > so I'll just send it to machine X". ... This of course assumes that machine X is willing to handle all the mail for HP.COM, not a safe assumption if the (sub)domain in question spans more than one organization. It is really unfortunate that people are unable to make a clearer distinction between naming and routing. Ideally one should ask machine X how to get to the desired place, and then follow its directions (combined, perhaps, with other sources of knowledge), which wouldn't necessarily involve relaying through X. Alas, in our current network that takes longer and involves more hassle than just handing the message to X and asking him to deliver it. Domains are a fine idea for hiding the structure within an individual organization (although they are overkill since there was never any good reason why a multi-machine organization couldn't pretend to be a single machine for mailing purposes). If upper levels in the hierarchical setup come to be identified with specific machines, though, the day will come when those machines are overloaded because of all the "well, I don't know how to get to these guys, I'll just throw it up the tree and let those know-it-alls handle it" mail going through them. This was the reason why we made a policy decision that we would not do automatic routing of incoming mail. We lack the resources and inclination to cope with the increased traffic that would result from supplying a free routing service to the world. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
wcs@ho95e.UUCP (03/05/87)
In article <7723@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
: > What we're supposed to end up with is a system that says "oohhh...
: > you're sending mail to <hostname>.HP.COM (or <hostname>.<localdomain>.HP.COM)
: > so I'll just send it to machine X". ...
:
: This of course assumes that machine X is willing to handle all the mail for
: HP.COM, not a safe assumption if the (sub)domain in question spans more than
: one organization. It is really unfortunate that people are unable to make a
: clearer distinction between naming and routing. Ideally one should ask
: machine X how to get to the desired place, and then follow its directions
: (combined, perhaps, with other sources of knowledge), which wouldn't
: necessarily involve relaying through X. Alas, in our current network that
: takes longer and involves more hassle than just handing the message to X
: and asking him to deliver it.
How do you ask a name-server "X.FOOSUB.COM" for a path to
machine "Y.FOOSUB.COM", using UUCP? I assume there may be ways
for an ARPA Internet to get that information, but my
machines run normal HDB UUCP. Even if I could send mail to
X.FOOSUB.COM!nameserver, what could it tell me? I doubt the
entire FOO subdomain would like the nameserver mailing out
phone number and uucp passwords, but the only other machines
I'm guaranteed to know are X.FOOSUB.COM and ihnp4. An Ethernet
address won't help me much; my machines do modems, Datakit, and
RS232.
Thanks;
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcsguy%gorodish@Sun.COM (Guy Harris) (03/05/87)
> How do you ask a name-server "X.FOOSUB.COM" for a path to > machine "Y.FOOSUB.COM", using UUCP? You don't. You would use something like the UUCP maps, "pathalias", and a mail delivery mechanism that knows about the maps generated by "pathalias". The map would contain entries like y.foosub.com foo!bar!bletch!mumble!y_foosub!%s This would tell the mail delivery mechanism that mail to "user@y.foosub.com" should be sent out via "uux" to "foo!bar!bletch!mumble!y_foosub!user". I think there is also a scheme for routing mail to all hosts within a given domain through a particular machine.
jhc@mtune.UUCP (03/06/87)
In article <1343@ho95e.ATT.COM> wcs@ho95e.UUCP (Bill Stewart) writes: >In article <7723@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > What we're supposed to end up with is a system that says "oohhh... > > you're sending mail to <hostname>.HP.COM ... I'll send it to machine X". > This of course assumes that machine X is willing to handle all the mail ... > How do you ask a name-server "X.FOOSUB.COM" for a path to > machine "Y.FOOSUB.COM", using UUCP? That's not what Henry is saying. He's saying forward all mail to a smart-host for it to handle. If you are really public-spirited then you too can put up smail, make a complete map monthly out of the mod.map postings, and turn yourself into a smart-host. Sure, there's some work involved in doing this, but you get a big payback: your users and yourself stand a fighting chance of getting their mail through to the correct machine. And service to the users is what it's all about. -- Jonathan Clark [NAC,attmail]!mtune!jhc My walk has become rather more silly lately.
piet@mcvax.UUCP (03/12/87)
>what we're seeing is the problems of: > > 1. having a system that expects dynamic routing in a static > routing universe (e.g. pathalias) At least in Europe the routing databases are updated *daily*, to that's already far from static. Fully dynamic routing, i.e. on the fly, may be even better, but I do know of cases where it did cause infinite loops. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl or mcvax!piet)