mark (10/10/82)
I am posting the following transcript of a private discussion on mail
with Eric Allman with his permission, in order to help shed some light
on the intent of the ARPANET domain convention.
Mark
Date: 30-Sep-82 17:27:36-PDT (Thu)
From: ucbvax!UCBARPA:eric (Eric Allman)
Subject: delivermail, sendmail, domains, etc.
To: decvax!watmath!bstempleton
Cc: cbosgd!mark, postel@isif
The domain spec in messages must be either "simple" or "complete"
as specified in RFC 822, where "simple" is defined as having only
the final host id, and "complete" is defined as having the entire
path (back to the root) specified. For example, "mark@cbosgd"
might be a "simple" spec, whereas "mark@cbosgd.btl.uucp" might be
a "complete" spec; "mark@cbosgd.btl" is called "illegal." Furthermore,
"simple" domain specs are acceptable only for messages staying
within one domain, so the header:
From: mark@cbosgd.btl.uucp
To: joe@ihnss, postel@isif.arpa
is illegal, since the message crosses a domain boundary.
The basic concept of domains is nothing short of sheer genius; it
remains only to communicate the fundamental beauty of it. What
will do at Berkeley is fundamentally as follows: Look at the last
element of the domain spec. One of three situations exist:
(a) You know everything about this domain: extend your
search to be one more element to the left and restart
the algorithm.
(b) You know what the relay host is to this domain, but have
no other information about it. Send this message to
that host.
(c) You know nothing about this domain. Send the message
to a "smarter" relay host.
This emphatically does not require that you know everything about
the entire world, or even your local domain. Step (c) is a powerful
one -- for example, it is not even necessary that every ethernet
host at berkeley know about every other ethernet host -- only who
the central relay host (i.e., the "smarter" host) is, so that
unresolvable mail can be sent there. Knowledge of other hosts
becomes little more than an optimization; the algorithm can be
restated something like:
(1) Strip any local information off this message. This leaves
you with the next piece to forward to.
(2) [optional] See if you know how to get to this host; if so,
send directly.
(3) If non-local (i.e., an "@" still exists), send to the central
relay host, our immortal guru, the center of the universe, etc.
(4) Deliver locally.
This means that the central host (in our case, ucbvax) must have a lot
of information about a lot of hosts -- but not all. For example,
anything of the form *.arpa just gets forwarded to the C70. In fact,
anything of the form *@unknown gets forwarded to the C70, in the hopes
that "unknown" is an arpanet host.
This algorithm is somewhat pessimistic for the global UUCP land, since
I doubt anyone would be willing to dedicate a VAX to this sort of thing,
but the algorithm is still basically correct, although the responsibility
is somewhat more distributed.
Sendmail will rewrite headers as you require. Availability should
be by the end of the year.
eric
>From mark@cbosgd.UUCP Sat Oct 2 12:00:05 1982
To: eric@UCBARPA.Berkeley.ARPA
Subject: Re: delivermail, sendmail, domains, etc.
Eric - thanks very much for the note. It cleared up several things I
hadn't previously understood.
I personally am in favor of UUCP adopting a syntax compatible with the
ARPA domain concept so that UUCP can be just another domain. But there
are people who want different conventions, where the top levels are
not networks, but rather something geographical (e.g. state, area code,
or even country or continent.) This is incompatible with the ARPA method
because there would be lots of top level domains (especially if the
top level was area code). I assume this issue came up in the ARPA
discussions, and that there was a good reason for having the top level
be few in number and most likely a physical network. UUCP can (hopefully)
be convinced by the same argument. My major goal is to avoid having
two incompatible systems cropping up, with the resulting need for
gateway translation.
Mark
Date: 9-Oct-82 16:22:15-PDT (Sat)
From: ucbvax!UCBARPA:eric (Eric Allman)
Subject: Re: delivermail, sendmail, domains, etc.
To: cbosgd!mark
For example, the entire issue of physical naming is really counter-
productive. As a great example, look at Grapevine. Xerox is
geographically highly distributed, even among single groups. A
registry is a logical concept, rather than a geographical or electrical
one. So although I support the concept that tying to a net such as
"berknet" or "uucp" is inappropriate, I feel that sticking to a
geographical location such as "Columbus" or "Palo Alto" is equally
inappropriate.
Registries, domains, or whatever you want to call them should be
logical. If I am in the "CAD" group, I could be in one of three
geographical locations, but that is irrelevant. What is relevant
is that I am in the CAD group. If I am also in the OA group, I should
have the ability to do this also. So for examples sake, let's say
I work for XYZ corp. Then the addresses "eric@OA.XYZ" and
"eric@CAD.XYZ" should both be reasonable addresses. If I happen
to be sending from within XYZ corp, then "eric@OA" is a reasonable
mailbox. Notice that these do not necessarily specify the same
mailbox, even from moment to moment -- for example, if I work half
the year in San Francisco and half the year in Houston, the bindings
of these can change. Of course, this is quite sophisticated, but
not beyond the bounds of the technology (Xerox does it, for instance).
eric