Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.mail Subject: Re: Mail routing -- problems showing up Message-ID: <1422@peora.UUCP> Date: Sat, 10-Aug-85 00:08:44 EDT Article-I.D.: peora.1422 Posted: Sat Aug 10 00:08:44 1985 Date-Received: Tue, 6-Aug-85 20:07:34 EDT References: <1383@peora.UUCP> <9546@ucbvax.ARPA> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 94 [The referenced article questions my suggestion that the current trend in domain routing would make the UUCP network vulnerable to a commercialized takeover. It concludes by asking where I got the idea that he wanted UUCP to be like CSnet.] The major distinction between CSnet and the "other networks that don't require source routing" which another poster mentioned involves the topology of the UUCP network. UUCP is inherently decentralized. There are no centralized machines responsible for carrying out message delivery; in comparison to my example of CSnet's phonenet, which does have 2 or so machines which poll the other machines in the phonenet to pick up and deliver mail. Now, the proposed nameserver strategy requires such centralized machines. People have proposed designating name-administering authorities. Besides the overhead of paying people to run those authorities, in order to make nameserver queries you either have to send a message out to the nameserver and get a route back (which you then use to mail the message), or mail the message to the nameserver, who sends it on to the next nameserver. I suspect the latter would be the actual implementation, due to efficiency and coordination considerations. Now, the problems with the currently proposed domaining schemes for UUCP are twofold. First, the currently proposed scheme is geographic. This requires one of two things: either each machine in a given geographic subdomain has a database of all other machines and paths to them in that same subdomain, plus paths to some selected set of machines in other subdomains that serve as nameservers for them (this would be a distributed implementation); or there has to be one or two (or so) machines in each geographic subdomain that are the nameservers (the centralized implementation). But the centralized approach thereby makes these nameserver machines be the principal delivery machines for the network, exactly like CSnet. Furthermore, it provides considerable leverage for gaining control of the network as a whole, by acquiring (or initially providing) the geographic nameserver machines. The second problem with the proposed scheme is that it says that if a geographic subdomaining is not provided, then there is still a minimum number of machines allowed to comprise a subdomain. This tends to force a large set of independent machines to consolidate to make their own subdomains; I suspect this would tend to occur geographically anyway, but in any case it leaves all the independent machines in a fairly awkward situation, since they have to "sign up" with somebody. Now, I agree with Peter Honeyman's discussion thus far. I think a great deal of the discussion in here is essentially moot, centered around inexact definitions of the proposed approaches to UUCP naming and routing. On the other hand, I can see that it is advantageous to provide something analogous to nameservers for sites which don't have adequate disk space to contain a complete map. I can further see that it would be advantageous for some companies that are sufficiently large to provide their own name- servers. (In fact, I already have this implemented in our mailer for the ATT.UUCP domain, since AT&T is doing funny things with its forwarding of mail lately, I guess to discourage people from routing through them for mail not destined for an AT&T site: I send anything with the domain ATT.UUCP to a "smart mailer" at AT&T, without generating any further routing.) However, I don't think this requires anything radical. In fact, if one were to undo a lot of the mess people have made already and start over with things the way they were before sendmail and smart mailers, I think we would end up with a better network. As I've observed the ongoing arguments here, I have realized one major thing. A lot of the current problems have to do with the fact that people's user interfaces to the mailers serve as a sort of "gateway", even if the mailer itself is not a gateway (or "bridge," in Mark Horton's terminology.) The problem is that a lot of the current mailers will let you send mail via UUCP, or the ARPAnet, or some other network, all from the same user interface, and it's kind of a problem to figure out how to do it. I think approaching this problem first would help things out a lot. One of my basic beliefs regarding the implementation of a successful UUCP mail network is that networks in general should be kept separate except at well defined gateways, and the user interfaces are NOT well-defined gateways. That is why you have problems with a site being named both UCBVAX.BERKELEY.EDU and UCBVAX.CSNET, for example. They are addresses for separate networks; but at the user interface, they come together, and you have this problem. Discussing this problem, and how to solve it, would take another long message, and this one is already approaching the proposed limit of 100 lines; so in a separate message, I will post some comments on solving problems other than the user interface ones, and leave the user interface for some other time. -- 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 "Vg frrzf yvxr hc gb zr."