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