Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncr-sd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!alberta!ubc-vision!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!ncr-sd!greg
From: greg@ncr-sd.UUCP (Greg Noel)
Newsgroups: net.mail
Subject: Re: Mail addressing and routing
Message-ID: <271@ncr-sd.UUCP>
Date: Thu, 29-Aug-85 01:28:59 EDT
Article-I.D.: ncr-sd.271
Posted: Thu Aug 29 01:28:59 1985
Date-Received: Mon, 2-Sep-85 04:29:31 EDT
References: <644@adobe.UUCP> <734@vortex.UUCP> <1156@umcp-cs.UUCP> <263@ncr-sd.UUCP> <1370@umcp-cs.UUCP>
Reply-To: greg@ncr-sd.UUCP (Greg Noel)
Organization: NCR Corporation, Torrey Pines
Lines: 91

I got a surprising amount of mail about this -- usually what I post seems
to not draw any replys at all.  (Maybe I'm not controversial enough!)  In
any event, I thought I'd hit some points that seemed to have caused some
confusion.

As context, I got a note telling me that Mark Horton's "smail" program
(which is what creates those strange return addresses that look like
...!cbosgd!cbosgd.att.uucp!...) does a lot of what Chris and I were
discussing.  I dropped a line to Chris about it; apparently he has gotten
a Beta (Alpha?) test version to play with.  I managed to get a copy of the
documentation and have looked it over, and although there are some things
I would have done differently, there is a lot of careful thinking that has
gone into the program.  When can \I/ get it?

In article <1370@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes:
>[As Greg says, read the parent article, it's too hard to summarize here.]
>
>(Note that with Greg's format I could easily use the proposed "bang
>domain name" scheme, mapping userX@hostY.partialroutedom to %R!%D!%U,
>where %R is the route, %D is hostY.partialroutedom, and %U is userX,
>in this case.  Also note that the scheme used is per-host, another
>very nice feature during experimentation periods at different
>hosts....)

That's what I had in mind.  The ideal would be that the server would
be flexible enough (have enough printffy codes) that any routing scheme
could be used, as needed.  There would potentially be several programs
that provided input to the hosts-to-routes data base (I can envision a
program that directly converted hosts.txt, for example) and it would be
very easy to experiment with differing schemes.

To clear up something that several people seemed confused about, I would
like to have \no/ specific knowledge about output channels in the server;
I would create the complete command that would conceptually be executed
directly by the system() function (although I would probably optimize the
actual command execution the same way that "make" does).  In other words,
it would map a domain name into a mailer command, filling in whatever is
necessary to see to it that the mail gets delivered.

In other word, \all/ of the routing decisions would be made outside of
the mail server.  In particluar, the "don't use the ARPAnet unless there
is no choice" decision would be made by the routing program, \not/ by
the mailer itself.  It is quite possible that several routers could be
developed, each catering to a different community and embodying different
decision criteria.  One program might be used on a home computer that
would know how to route to neighbors and would route everything else to
a smart friend while another program might be useful to the host that
has nothing but direct connections (say, on a LAN).

>As for final delivery to a real user given a (potentially ambiguous)
>real name ..., that should certainly be standardized, but
>it is a separate issue from mapping fully-qualified host names
>... to routes, and probably belongs
>in a separate program (the local host mail deliverer in our case).

The concept of a name-resolver was well-received, although it seemed to
be new to a lot of people.  Some seemed to think that I originated the
idea.  Sorry, 'tain't so.  I believe that several sites within AT&T run
such a name resolver; ihnp4 is one that I know about.  I just wanted the
facility to be more readily available.  (It may even be possible to use
the ihnp4 code -- does anyone know the history of that program?  Or more
information on what it will do?)  CSnet also has a facility for sending
a query to a central database which will try to resolve it into a mail ID
that can be used manually.  Not only that, there is at least one machine
has a name server that runs finger on a name you send it and it mails you
the result.

Anyway, you identify the exact problem area.  Indeed, the local host mail
deliverer should do such a thing.  The point is, which one?  Practically
all mail servers, "smail" included, assume that they know how to deliver
mail to the local system and go right ahead and do it.  If it is going to
be standardized, and I agree that it should be, now is as good a time as
any, and it would probably be easier to do it in a domain mail server,
since the routing decision for "this person unknown" or even "person-name
data base not supported" looks a lot like the routing decision for a
unknown domain -- i.e., route it to a smarter neighbor.

Several people pointed out the issue of ambiguity and imprecise specification
of user names, apparently not realizing that steve.bourne is ambiguious.
I agree, it's a difficult thing to do right.  I would err on the side of
returning the mail and giving the possible resolutions.  Presumably, if
this became common, user-level mail handlers could detect this returned
mail and just allow the user to pick the right one and automaticly resend
the mail.  Obviously, there's a lot to be considered.

Then again, it may not be possible.  One of my respondants suggested that
AT&T is moving away from RFC-based things and that they may not accept a
public-domain version of their mail-name resolver.  Anybody have any
insight on this?
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA