guy@sun.uucp (Guy Harris) (07/22/85)
> 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 What guarantees that a neighbor in your domain is the appropriate neighbor to route the mail to? You may be sending to "Large_American_Corporation.COM", but the best path to "Large_American_Corporation" may be through "University_of_Southern_North_Dakota_At_Hoople.EDU". As I pointed out in the article that you seem to be replying to (although the "References" line refers to some other article, and "notes", in its inimitable fashion, refused to acknowledge the datagram nature of netnews), you need a "hosts to routes" function. If you have the space, you can store all the (host, route) ordered pairs. If not, one way of evaluating the function is: Have the route for a given name be "send it to some neighbor *on the same network* as the host in question." However, this requires a mapping of "hosts to networks". If you don't have the space to store *this* map as a set of ordered pairs, you have to find another way to evaluate this function at a particular point in its domain. One way of doing that is to have the network a host is on be derivable from the host's name by inspection. This seems to be where the "domains are the same as networks" model comes from; you say that "foo.ARPA" is on the ARPANET, and "foo.UUCP" is on the UUCP net, and "foo.BITNET" is on the BITNET, etc.. Unfortunately, there is no "seismo.ARPA" any more; it's now "seismo.CSS.GOV". If "cbosgd" became "cbosgd.ATT.COM", for exmaple, there'd be no way by scanning the host name to determine that it's on the UUCP network. > In the case of the domain .ARPA, smarter_neighbor is easy to > determine (or should be -- find your nearest ARPAnet host). Is "ARPA" going to continue to be a domain? So far, most hosts on the ARPANET are still "foo.ARPA", but will that continue to be true? Once they all move to the "EDU", "COM", and "GOV" domains, how will you tell a host is on the ARPANET just by looking at its name? > Other domains which auto-route internally can be handled in the same > way. Well, technically, the ARPANET *network* (*not* domain) doesn't "auto-route internally"; one ARPANET host can send mail to another one directly because, from the standpoint of TCP and all protocols using TCP, there exists a direct hardwired connection between every host on the ARPANET and every other host on the ARPANET. > I do not want to have to be forced to KNOW paths through any > networks. Nobody does. I don't. Nobody said you should be so forced. However, it is not clear that embedding a route within a name (which is what using network names as domains and geographic entities as subdomains implies) is the correct solution - domains were conceived of as a solution to the problem of providing unique names for hosts without having some single authority responsible for all host names, not to the problem of doing UUCP routing. > And UUCP does not guarantee reliable deivery or message back ... > mail can vanish into never-never land, which should NOT be > allowed. What does this have to do with mail routing? The fact that mail can be dropped by UUCP is due to several problems: 1) not all UUCPs know how to send undeliverable mail back to the original sender - it often goes back to "uucp" on the previous machine 2) UUCP doesn't always deal gracefully with out-of-space conditions on /usr/spool 3) UUCP doesn't always know what to do if the mail delivery program bombs out (which it occasionally does on my machine due to running out of swap space) - it may just send a "exit N, signal N" back to "uucp" on the previous machine 4) etc., etc. (Mail has been bounced on the ARPANET, also, due to problems like the domain server screwing up.) Setting up geographic areas as subnetworks for mail routing and using them as domains to incorporate the route into the name won't have any effect on these problems. Getting everbody to upgrade to smarter versions of UUCP will. > > ... 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 this implies that domains were inteded as a way of cataloging electronic mail networks? Hardly. It merely means that if a large organization in the "EDU", "GOV", or "COM" domains wants to become a subdomain and administer its namespace itself, it can; the top-level domain's name server then passes all host name to host IP address mapping requests for the subdomain in question to that subdomain's name server. It obviously has to know its subdomains to do this. > 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. I assume you meant to say "send to hpfclo.FC.HP.COM". > 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. This does what you want; note, however, that your host was "hpfclo.FC.HP.COM", not "hpfclo.CO.UUCP". The name "hpfclo.FC.HP.COM" nowhere implies that "hpfclo" is a UUCP site. If it were both on ARPANET and UUCP, for example, an ARPANET site would ask the "COM" server for the Internet address of "hpfclo.FC.HP.COM", which would ask the "HP.COM" server, which would ask the "FC.HP.COM" server. It would return the appropriate IP address and the ARPANET site would open an SMTP connection and deliver the mail. This would even happen if the ARPANET site were also on the UUCP network. If a UUCP-only site wanted to mail to "hpfclo.FC.HP.COM", it would either 1) have a big hosts-to-routes database, which would give it the route to "hpfclo.FC.HP.COM", or 2) have some function to map host names into routes. It might have only one UUCP neighbor, in which case the function is trivial. It might have a map that says "my nearby HP sales office knows how to get to all hosts in the 'HP.COM' domain" - note that this doesn't necessarily imply that all such hosts are on the same physical network - and that the nearby USENET backbone site knows how to get to just about every other host in existence. None of this requires that there be any equivalence between domains and networks (the "COM" domain may have ARPANET, BITNET, CSNET, and UUCP sites, as well as sites on any combination of the aforementioned nets) or that domains be set up geographically. Guy Harris
jww@sdcsvax.UUCP (Joel West) (07/27/85)
In <2463@sun.uucp>, Guy Harris writes: > What guarantees that a neighbor in your domain is the appropriate neighbor > to route the mail to? You may be sending to "Large_American_Corporation.COM", > but the best path to "Large_American_Corporation" may be through > "University_of_Southern_North_Dakota_At_Hoople.EDU". True, if you've heard of "Large_American_Corporation.COM". But if you've never heard of LAC, a reasonable convention would be to dump it on "Piddlin_Garage_Operation.COM" and assume that any site knows at least how to find the "smart" router in its own domain. > > And UUCP does not guarantee reliable deivery or message back ... > > mail can vanish into never-never land, which should NOT be > > allowed. > > What does this have to do with mail routing? The fact that mail can be > dropped by UUCP is due to several problems: > > 1) not all UUCPs know how to send undeliverable mail back to the > original sender - it often goes back to "uucp" on the previous > machine To quote the immortal (immoral?) Peter Honeyman, "if not for those cute-as- a-shithouse mailers...." Because there already is enough address munging going on, I will not feel confident about reliable replies (on undeliverable mail) until: 1) Every site can somehow handle a path-less domain address, e.g. joel@sd.gould.com 2) The CAAS mailers give up the ghost. I've tried the latter myself, using a path-aliased smart mailer and sendmail BSD 4.2, but the latter starts retching if you try to leave "TO" and "FROM" lines unmunged, particular when building a UNIX-style "From" line. > 2) UUCP doesn't always deal gracefully with out-of-space conditions > on /usr/spool About the only practical solution is a quota system (with maybe a dedicated file system), and allow UUCP to refuse new files until it's under quota (the reserve disk space.). You could, I suppose, always send your mail with reply receipts. Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
peter@baylor.UUCP (Peter da Silva) (07/28/85)
> (Mail has been bounced on the ARPANET, also, due to problems like the domain > server screwing up.) Setting up geographic areas as subnetworks for mail > routing and using them as domains to incorporate the route into the name > won't have any effect on these problems. Getting everbody to upgrade to > smarter versions of UUCP will. God. If only i COULD upgrade to a smarter version of UUCP. Anyone got a PD uucp out there? -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076