From: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark Newsgroups: net.followup Title: Re: UUCP Internet Addresses Article-I.D.: cbosgd.2639 Posted: Mon Sep 20 11:24:45 1982 Received: Tue Sep 21 07:30:40 1982 References: populi.342 Bill Wells makes an interesting proposal. I'm glad to see people are addressing the issues of heirarchies for UUCP. I'm beginning to wonder if we need a newsgroup to talk about mail issues? There are two ARPANET mailing lists (header-people and msggroup, and I still don't understand the difference) for this but only two USENET people are involved in these discussions, and they are ARPANET oriented. Anyone interested in net.mail? The idea of making UUCP into a heirarchy is appealing. But there are some enormous technical problems to be worked out. Note also that Steve Belovin (unc!smb) is keeping a quasi-official UUCP map, and while it will probably never be 100% correct (due to lack of any control of UUCP net, lack of a broadcast mechanism, and lack of a central registry) desire to receive mail should provide some incentive. Rick Adams effort will also no doubt be extremely helpful, although cooperation between the people involved will make for one superior map. The decision to go initially with the user@host.uucp syntax was made for simplicity. Most uucp sites that deal with other sites currentl think of sites, not heirarchies. Many don't even believe in network boundaries: MMDF wants all mail to go to user@host where host is not subdivided - a table lookup is done (either locally or by a forwarder) to decide what host and what network to send to. This simplicity goal is probably good to make conversion easier, but there are certainly long term problems. (Netnews assumes host names are unique - if Bill has seen duplicate UUCP host names I'd be interested to hear about them, since I've never seen a duplicate and many programs assume there are no duplicates.) First note that the problem of keeping a large database on a micro does not wash. A tiny micro can punt the issue entirely by sending all non-local outgoing mail to one particular site (which it probably does anyway) and letting that site worry about how to route it. Second, note that there is no requirement or advantage to forcing fixed length abbreviations. Countries can be USA, Canada, and Mexico, time zones can be PST, EST, etc (although I am opposed to using time zones as part of the heirarchy). Since we already have official two letter state/province abbreviations which most people know, it is fair to use them. (We should, however, probably avoid names like Czechoslovokia, instead adopting an official abbreviation like Czech, and hopefully allowing nicknames.) Now for the technical problems. First off, we need software to support it. I urge Bill Wells to talk to Eric Allman (arpavax:eric) to see if sendmail can do this. (It probably can, but it's not obvious to me how.) If not, perhaps sendmail can be augmented. We also need a trivial program (such as that by ucf-cs!tim) that can be dropped into any existing mail system, so that people won't be out in the cold if they have their own homegrown mail system, or if they have some official requirements like "we run UNIX as it comes from group xyz with no mods" it will be possible to argue that the changes are trivial and therefore safe. Second, if USENET has shown anything, it has shown that there are all kinds of anomalies about where cross country links go. While it's appealing to have a geographic heirarchy, In reality what happens is that some sites are only on UUCP by the grace of a friend of theirs across the country who is willing to pay the phone bills. One look at the geographic USENET map from my talk last January shows what appears to be a big mess. (Examples: utah-cs started out talking to harpo, uwvax in Wisconsin started out talking only to ucbvax, philabs in NY state talking to sdcsvax in San Diego, etc. Most of these sites are better connected now, but there are always new sites - currently there is kentvax in Kent State, Ohio, whose only connection is to ucbvax.) Sometimes there is a leased line (e.g. ima, in Mass, to ico, in Colo.); sometimes there is a special link, like the ARPANET link between cca in Boston to sri-unix in San Francisco.; sometimes a site just happens to have a high phone budget (e.g. decvax, which is the main link for pur-ee in Indiana and microsoft in Seattle) or a WATS line. Security is an issue too - there are three groups of USENET sites near Denver: Bell Labs has Denver sites that aren't even allowed to talk to other Bell Labs sites, much less outside sites; Interactive's ico site is there, and hao is also there. These sites don't talk for security reasons, as I understand it. The following technical problem can arise. Suppose mail distribution is heirarchical by, say, state (which would be my preference). I send mail to daveb@ico.co.usa.uucp. It gets sent to colorado, say hao, which then figures out a route to get it to ico: menlo70!ucbvax!decvax!cca!ima!ico!daveb is the shortest path! So hao sends it to menlo70, which says "this should go to Colorado, so I'll send it to the Colorado distribution center, which is hao". (For those of you familiar with packet switched networks, this problem will remind you of the situation where a link goes down and tables aren't up to date, resulting in a loop.) Also, if we're going to get this fancy, we should consider what to do about a down host. If I'm in Canada, chances are all my mail goes through decvax. If decvax goes down for 2 weeks, I'm isolated. It would be nice to have mail try to send through site x, and if that fails, try an alternative site. (Given the implementation of uucp, this is a very difficult problem.) I believe these problems can be solved. A site can invoke arbitrarily hairy decisions about how to route a message (the address heirarchy is only a precise specification of a location, not a route) if they are allowed (forced?) to write code. I don't know if these decisions can be implemented in a sendmail configuration file; I hope so. We can start by specifying a precise routing algorithm that all sites can implement. If an algorithm exists, it may make sense to adopt a hierarchical standard. Bill - care to make an initial stab at it? Mark Horton