Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ndm20 Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!ndm20!tp From: tp@ndm20 Newsgroups: net.mail Subject: Re: Orphaned Response Message-ID: <3700007@ndm20> Date: Mon, 16-Sep-85 14:07:00 EDT Article-I.D.: ndm20.3700007 Posted: Mon Sep 16 14:07:00 1985 Date-Received: Sun, 29-Sep-85 04:52:23 EDT References: <1602@peora.UUCP> Lines: 105 Nf-ID: #R:peora.UUCP:-160200:ndm20:3700007:000:5954 Nf-From: ndm20!tp Sep 16 13:07:00 1985 (A consensus has been reached? Could someone mail me a summary of the consensus. I must have missed it.) (No smiley face, that is a serious request.) The map data will have to change completely before any of this stuff will work. All the names will have to have their domains attached. I would suggest still making the full map available, as good routes have nothing to do with domains. Besides, if you channel all the mail for, say, northern california through one site, you may have a lot of trouble finding a volunteer to be that site. Domain names should have nothing to do with routes. All they really solve is the name-space collision problem. Trying to use them for routing will be a disaster, as all the mail will bottle-neck at certain systems, who will probably not be happy about it. The other benefit of domains is that if the mail can't be delivered along the path it was sent, you can try sending it along the domain tree, as those sites should have up to date routing information. Since I started I might as well present my (lowly peon) suggestion (on mechanics only, not policy). I suggest that all mail should have RFC-822 headers with *just* the address (as opposed to any gateway routing garbage) in the To: line. As the RFC tells us, this is the envelope, not part of the message, as someone has suggested. The mailer would take this and look up the route with pathalias and send it along. Note that the address and the route are unrelated, as they are supposed to be. If a gateway is required, or the database does not have the name in it, it should be sent to the gateway or name-server with out a destination address on the transport line (i.e. the gateway system would get an rmail command from its neighbor without an address. This would be something of the form rmail host1!host2!host3! somewhere down the line). This system, being a name-server or gateway, must of course have an equally sophisticated mailer. It would then look at the RFC-822 To: line, and take whatever steps neccessary to deliver the mail. In the case of a gate-way, it would send it out on the appropriate net. In the case of a name-server, it would generate a proper route and mail it. No return routes need to be maintained in either case because any system that re-routes a message can presumably generate a return route through the pathalias database. Remember this is assuming domain addressing, so that host names are unique. This is compatible with existing software. Standard UUCP address still work. Using a gateway manually (i.e. without up-to-date software) actually becomes easier: Just put an RFC-822 compliant To: line in your message and mail it to a gateway. No precedence to worry about, no syntax to learn. Systems with dumb mailers can just get in the habit of mailing it to a smart neighbor for delivery. (Under this scheme, any site with the appropriate mailer and pathalias database can be considered a name server, thus distributing the load more evenly net-wide). Of course the map data needs to change, as I said. Also pathalias needs to know about domains. This can probably handled more by changing the map data than the program. I think the program will already do it, by entering each domain as a subnetwork, and making the hosts with smart mailers gateways. Since a subnetwork is a psuedo host, you can nest them easily. I am no expert on pathalias, so I could be wrong about this. I would leave it to the mailer to access the database with successively more general names, rather than making pathalias do it. For example, when handed user@x.y.z, the mailer should ask for a route to x.y.z. If such a host exists in the database, the mailer should generate a full route (i.e. host1!...!hostn!x.y.z!user). If such a host is not in the database, the mailer should ask for a route to y.z and then z. If a route for y.z is known, the mailer would generate host1!...!hostn!y.z! indicating to that machine that it needs to generate a route for the message. If no route to any higher domain can be found, the mailer should bump the message to the nameserver for his domain. By this passing of the buck the mail will get through as long as the top level domains all know about each other. For example, if I mail from tp@a.b.c to user@x.y.z, and my machine knows nothing of x.y.z, y.z, or z, I should send it to b.c. If that machine can't deliver it, it should be sent to c. If that machine can't deliver it, it can't be delivered. This scheme gets the mail to gateways automatically. (There is really no difference between a name-server and a gateway insofar as the software should be concerned. They are both systems that can forward mail that can not be directly delivered.) I have used the names of domains as host names intentionally. My intent is that when sending to y.z, for instance, the mailer would consult pathalias for a route to that pseudo-system (sub-network), and the mail would actually go to one of the gateways for that domain (i.e. someone with a smart mailer who can act as a name-server for the domain.) This results in the mail getting to the domain and a name-server request happens automatically, which is exactly the desired result in such a situation. This is a general mechanism and not tied to any particular arrangement of domains or any political decisions on how it should be done or who is in charge. Those are political decisions, and while I do have opinions on them, they are not represented in the above discussion. Thanks, Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA