jad@hpfclo.UUCP (jad) (07/16/85)
/***** hpfclo:net.mail.heade / sun!guy / 10:47 pm Jul 1, 1985 */ > You can do routing by "brute force" by having a huge > database of hosts and routes to them, or you could send all your outgoing > mail to a "big brother" who does the routing for you, or... It was pointed out that micros [and maybe minis] cannot afford to have the huge database; not only that, it WILL be out of date nearly as soon as you compile it (data's just that way 8-| ). The simplest (often the best!) solution in my mind is: if host is known (it's local) send to host directly else if smarter_neighbor exists in host's domain relay to smarter_neighbor else bounce mail back This way big brother gets the mail you don't know how to send. Big brother may have to have a database; he may use the same algorithm; or he may use heuristics (guess, try to get closer). In the case of the domain .ARPA, smarter_neighbor is easy to determine (or should be -- find your nearest ARPAnet host). Other domains which auto-route internally can be handled in the same way. Domains such as .UUCP where the user [today] has to specify a full address on each piece of mail would be more difficut. I do not want to have to be forced to KNOW paths through any networks. As was pointed out, they can change without warning. And UUCP does not guarantee reliable deivery or message back ... mail can vanish into never-never land, which should NOT be allowed. Having everyone send mail to smarter and smarter neighbors, however, will cause congestion there, and may generate poor paths. Here, using geographical domains one could at least be sure you're in the right part of the country. > ... domains were intended as a way to simplify the administration of a > host namespace, not as a way of cataloging all electronic mail networks. RFC-882 domains? In RFC-882 an administrative domain is allowed to specify subdomains ... and has to know its subdomains! And if desired, domains could hide internal structure from the rest of the net, though it might be more efficient not to. An example of what I'd like to see: if I want to get mail here (say, at hpfclo.FC.HP.COM), someone should be able to send to hpfclo.COM from anywhere. If their host does not know hpfclo, it routes to the nearest .COM smarter_neighbor ... who knows that hpfclo.FC.HP is in the .HP subdomain, and sends to the .HP smarter_neighbor, who sends to the .FC smarter_neighbor, who sends to me. Since HP is worldwide, more information could be taken into account ... for instance *.FC.HP should be sent to Colorado (FC is in Fort Collins, CO). THAT kind of information can be put in a database, because it's not going to change [often]. If the HP subdomain does not choose to reveal subdomains or simple heuristics are used (say, send to Corporate in Palo Alto) inefficiency may result (mail from France may bounce to CA, just to be realayed to a Germany division). How much domain information is contained in each host is up to that host's administration. There should be a standard minimal set (top level domains/neighbors) and hosts can add more as desired. The maintainers of this information would be domain administrators; they would be responsible for distributing changes to other administrators at their level. This is getting rather long. Any comments/criticism? an interested party -- jad -- #! rnew