jad@hpfcla.UUCP (jad) (08/03/85)
I am confident that there are sensible solutions to the problems we have been discussing here for the past few weeks. Domains do seem like a good idea (which we can't live without) and absolute chaos (like absolute path specification in all outgoing mail) is has been called wave of the past and should be disposed of soon. But there's another problem here -- even if someone does come up with some great wonderful way to solve all the world's problems, or at least those concerned with mail routing, how do we get the world to move to it? Is there a way to update everyone's mailer code? Of course not... that would be too easy. Does anyone out there have a solution to this monster? Do we even want everyone (at least everyone on the same network?) running the same code?? Perhaps the UUCP domain [may I say domain here?] needs some kind of central authority. First, is this at all feasable? We won't ever see all the machines owned and operated by the same entity, so there has to be some kind of coordination!! Domains do offer this coordination, if done properly... the question is how do we get everyone to agree to move? Or better yet, CAN IT BE DONE??? -- jad --
dat@hpcnoa.UUCP (dat) (08/04/85)
John, (jad = John A. Dilley) (inside information :-) ) It seems to me that what you are proposing is a 'standardized' (NBS-type) uucp system including an internet path standard. This could be done...but given the anarchy of the UNIX community, I think that the better solution is to 'lead rather than force': If a worthwhile standard for mail addresses was generated and it was GOOD, then let a few choice sites get it up and running...then the others will gradually come into the fold as they find it is a better program than what they currently run. For a historical example of this, consider the gradual rise to fame of 'sendmail'... Another nickel: I am against assigning unique machine names because this implies that machines will have a central database of all the other available nodes in the system and will be able to 'figure out' how to get from 'a' to 'b' in the (hopefully) least expensive way. From experience trying to maintain a SMALL database of just the machines available in HP, I don't think that this approach is feasable. It is more often than not that the database doesn't have the address of a machine (like hpfclo) or can't suggest a reasonable way to get there! The alternative approach that I like is to take advantage of the information that IS unique for each machine - the geographical location! For example, consider if the machine I was posting on was called 'hpcnof@FortCollinsColorado' rather than just 'hpcnof'... this would eliminate all duplicate names without forcing a 'unique' naming scheme on everyone (and I for one do NOT relish the thought of sending mail to joe@XdcE34w or some other forcibly unique identifier!) Failing geographical area, how about 'zipcode' coupled with an international code for country?? That is, 'hpcnof@80525/USA' or something. Any thoughts? --- Dave Taylor HP Colorado Networks ..ihnp4 \ ..decvax!hplabs \ !hpfcla!d_taylor ..ucbvax!hplabs / ..hpbbn /
jad@hpfcla.UUCP (jad) (08/06/85)
> /***** hpfclo:net.mail / hpcnof!dat / 12:57 am Aug 4, 1985*/ > > The alternative approach that I like is to take advantage of > the information that IS unique for each machine - the geographical > location! For example, consider if the machine I was posting on > was called 'hpcnof@FortCollinsColorado' rather than just 'hpcnof'... > this would eliminate all duplicate names without forcing a 'unique' > naming scheme on everyone ... > > Any thoughts? First off, I agree that it may be quite impossible to "force" conversion. Leading it may work a lot better -- if you have something which works better than what is currently out there, and are willing to give it away cheap (and it works and does not take too much time to bring up, and etc.), then it will get used. I am confident of this. Next, re: 'hpcnof@FortCollinsColorado' ... what's wrong with hpcnof.CNO.FC.HP.COM? Or even hpcnof.HP.COM? The hpcnof would not have to be unique within the entire network (agreed -- global uniqueness over the ENTIRE WORLD is a pretty awful thought, esp. in the chaotic world of UUCP); it would only have to be unique within its "local" domain (.CNO. or .HP. above). Now what about that silly 7 letter host name limit that some brain damaged software out there forces???? (for those without inside info) -- jad -- John A. Dilley, FSD Fort Collins, CO ARPA: terrapin@Purdue.EDU UUCP: {ihnp4}! hpfcla!jad PHONE: (303)226-3800 x4166
lwall@sdcrdcf.UUCP (Larry Wall) (08/06/85)
(This is also a reply to the fourth article from Robert Elz on routing.) In article <47300002@hpfclo.UUCP> jad@hpfcla.UUCP (jad) writes: > Perhaps the UUCP domain [may I say domain here?] needs some kind > of central authority. First, is this at all feasable? We won't > ever see all the machines owned and operated by the same entity, > so there has to be some kind of coordination!! Domains do offer > this coordination, if done properly... the question is how do we > get everyone to agree to move? Or better yet, CAN IT BE DONE??? Obviously we can't force everyone to change their software without starting a civil war. The real question is, can we change just some of the systems and reap any benefit from doing so? Robert Elz has pointed out that there are three possible schemes: 1) attributes 2) domains 3) explicit routing He rejects 3 on the basis that it doesn't work well. Which is perfectly true, as we have been finding out by experience. Nevertheless, since 3 is what we currently do, those sites which do not upgrade their software will continue to do 3. Robert Elz mentioned a couple of kinds of site, which I would like to define as follows: smart knows about addresses; knows about routes dumb knows about addresses; doesn't know about routes To this we must add: enlightened knows about addresses (either smart or dumb) really-dumb doesn't know about addresses; doesn't know about routes pseudo-smart doesn't know about addresses; thinks it knows about routes We assume that all machines, including really-dumb ones, can forward messages to their neighbors. (Note that the prototypical uucp machine is really-dumb (no insult intended).) We also assume that everyone knows that not everyone can afford a smart machine, and the dumb machines are to be treated as civilized citizens. Now, suppose for a moment that we have a network of only smart and dumb machines (no really-dumb or psuedo-smart ones). The dumb machines have no problem--they just forward unrecognized addresses to smarter machines. The smart machines have the problem of what to do with a route once they've determined it. How do they get the message to actually follow the route they've determined? There has to be some way for the smarter machine to tell the dumber machine "Hey, I know where you ought to send this, so don't try to be either smart or dumb, just do thus-and-so." (I leave it as an open question whether a machine ought to be allowed decide it's smarter than the previous smart machine and modify the route given to it.) Even with this idealized setup, we need to differentiate the address from from the route. The idea is that the address is immutable, while the routing information may be incomplete, or not even exist yet. It is the job of smarter hosts to suggest a better (not necessarily best) route. Hopefully, whenever a route gets used up, you're someplace that can extend the route in the proper direction, based on the immutable address. (I.e., you're at a smarter machine, or the destination.) Now, back to the real world. Adding in really-dumb machines basically changes nothing, under three conditions: 1) You can specify the route to them such that they can forward to their neighbor. 2) You can pass the remaining part of the suggested route through them to the next site. 3) You can pass the (immutable) address through as well. I believe that most vanilla uucp sites can do all of this, as long as we keep the distinction between address and route. The big difficulty, as I see it, is that lots of people have been trying to smush both ideas into one header line, and it won't work. True, RFC whatever says that you can put both a route and an address into one header line via the baroque @host1,@host2... syntax. But you can't--and get this--you can't use that format to communicate the suggested route to a really-dumb machine that only knows bang notation. In order for smart and really-dumb machines to coexist, the smart machine must know more than the suggested route--it must also know how to communicate that route to (and through) the really-dumb machine. It must also know how to communicate the route with dumb and smart machines. A good question is whether there is a common way to specify routes to both enlightened machines, and really-dumb machines. It would certainly help if they could use the same form of routing, but my gut feeling is that the answer is "no go". If so, then smart systems will have to keep a database on how to fool their neighbors into doing the right thing, AND on how to get them to pass the correct information to the site after them, and the site after that, etc. There is one more wrench in the works: the pseudo-smart machine. This is a machine that does route optimization in an obsolete fashion. It may be that there is NO way to hand such a machine a suggested route, and know that it's going to do it correctly. I doubt there's a complete technological solution to this, but it may be possible to get most such machines to do the right thing by giving them an abbreviated route, something they can't easily foul up, and having a way to pass the real route through (transparently to the pseudo-smart machine) to an enlightened machine on the other side. Larry Wall {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
peter@baylor.UUCP (Peter da Silva) (08/12/85)
The only way a global change can be made in UUCP routing is if some kind soul
sits down & writes a mailer that's at least a powerful as sendmail (so people
will have incentive to use it) that supports this syntax & posts it in
net.sources with the admonition to "pass it on to non-news sites" at least
once a month for a year. The alternative, making gateways support ! routing
properly, is not nearly as hard (though still not trivial).
And if I send something to foo!bar!zot.arpa!baz, should the reverse route be
baz!zot.arpa!bar!foo? Or baz!zot!bar.arpa!foo?
--
Peter da Silva (the mad Australian)
UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
MCI: PDASILVA; CIS: 70216,1076honey@down.FUN (Peter Honeyman) (08/19/85)
dave's description of sendmail's prominence misses the mark. sendmail sucks. just ask anyone. but there it is on the 4.2 distribution tape, so that's what people run. i won't comment on his proposal for geographical domains except to reiterate that communication links don't respect borders. peter the australian gets right to the point: don't talk about it, hack on it. the world will beat a path to your door, even if you trap the trapper with the mouse. also, i remind dave that domains address the host name uniqueness problem; given uucp's weltanschauung, explicit routing is still de jure. so mod.map.uucp data remains a great help, even a necessity, for a large number of hosts. by slighting uucp, john is well intentioned if misguided. the "7 letter limit" is not a limit, it's a uniqueness requirement imposed on a given host's neighbors. honey danber uucp ups this to 14 characters, but the theme is the same: in unix, the file system defines the name space. peter
sob@neuro1.UUCP (Stan Barber) (08/20/85)
Peter mentions a 7 letter limit...
I was working on uucp from the SYSV R0 tape this weekend, and it would
only send the first 6 letters of a 9 character hostname to a 4.2 system.
The 4.2 thought it was 7 chars long and would not forward the mail.
Changing uucpname.c to make it be 7 characters made everyone happy....
Is this typical of SYSV?
--
Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed
Olan ARPA:sob@rice.arpa here are ONLY mine &
Barber CIS:71565,623 BBS:(713)660-9262 noone else's.chris@columbia.UUCP (Chris Maio) (08/21/85)
In article <576@down.FUN> honey@down.FUN (Peter Honeyman) writes: > sendmail sucks. just ask anyone. compared to the other mail delivery systems i've seen, sendmail is great. just ask anyone who doesn't have pathalias. or anyone with a heterogeneous network environment. or anyone who wants to change the behavior of their mailer without buying a source license. is there anything you don't like about sendmail that can't be fixed by editing its configuration file? chris
honey@down.FUN (Peter Honeyman) (08/24/85)
yes: the inscrutability of the configuration file. peter
jer@peora.UUCP (J. Eric Roskos) (08/24/85)
> Is there anything you don't like about sendmail that can't be fixed > by editing its configuration file? Good question... can you make it remember where a message came in from, and use a different set of rewriting rules based on where it came from? -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Zbba Cvr!"
peter@graffiti.UUCP (Peter da Silva) (09/03/85)
> There is one more wrench in the works: the pseudo-smart machine. This > is a machine that does route optimization in an obsolete fashion. It may > be that there is NO way to hand such a machine a suggested route, and > know that it's going to do it correctly. I doubt there's a complete > technological solution to this, but it may be possible to get most such > machines to do the right thing by giving them an abbreviated route, > something they can't easily foul up, and having a way to pass the real > route through (transparently to the pseudo-smart machine) to an enlightened > machine on the other side. If we could get rid of the pseudo-smart machines then routing would probably work. At least any time a rout has failed from here it's been because a pseudo-smart machine has gottent its hand on it. Also, under your scheme, how do you send a message from dumb machines?