Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rlgvax!vrdxhq!BMS-AT!stuart
From: stuart@BMS-AT.UUCP (Stuart D. Gathman)
Newsgroups: net.mail
Subject: Re: Domains: Multiple names OK? (Really, are domains good)
Message-ID: <205@BMS-AT.UUCP>
Date: Tue, 16-Sep-86 23:43:50 EDT
Article-I.D.: BMS-AT.205
Posted: Tue Sep 16 23:43:50 1986
Date-Received: Fri, 19-Sep-86 23:46:19 EDT
References: <566@mecc.UUCP> <2502@cbosgd.UUCP> <3920@ut-ngp.UUCP> <3437@umcp-cs.UUCP>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 72
Summary: a simple solution

In article <3437@umcp-cs.UUCP>, israel@umcp-cs.UUCP (Bruce Israel) writes:

> My point is that you don't require extra complexity from users unless
> it's necessary.  If there is only one SEISMO, then mail person@SEISMO
> should translate out to person@SEISMO.CSS.GOV.  If there are more,
> then mail to that address should return an ambiguous address message,
> so that the user could more completely specify the address.

If you are using smail, there is a simple solution:  add a 'seismo' line
to the /usr/lib/uucp/paths file with your editor.  Assuming the
domain address is already there, both references to seismo will now work.

As far as I can see, the domain structure does not take away any existing
features of bang routing.  You are still free to type:
	'foo!bar!foobar!barfoo!foofoo!barbar!seismo!barf!user'
if you wish.  

The pathalias database in conjunction with smail provides
a convenient way to enter 'user@barf' instead.  Unfortunately, the
network maps are passing 6 Megs in size.  That is a lot to broadcast
monthly, and some machines can't handle a database that size.  On
my AT, pathalias can grow to about 900K before getting canned by
Xenix.  This will handle thousands of paths, but will not handle
the entire network. :-(

(The overhead for broadcasting maps grows
exponentially with the number of machines in the network!)

The domain structure provides a way to enter 'user@barf.org.COM' and
keep only the path to 'gateway.COM' in your pathalias database to handle
all 'user@*.COM' addresses.  In
fact, I think you could get by with only 1 path entry in /usr/lib/uucp/paths
for '.UUCP'.  That machine would handle all your mail.  It in turn could
(conceivably) have only three entries for '.EDU', '.GOV', and '.COM'.
If everybody did this, that one machine would be swamped.  So, you keep 4 paths
in your paths file.  Now all your mail get routed through the gateways
for '.UUCP', '.EDU', '.COM', '.GOV'.  (The UUCP gateway can handle the
machines that are not registered if it has a map of them all.)  The
more paths you keep in your database, the more machines share the work 
of routing your mail.  In many cases (e.g. seismo) you might already
have the full routing information available.

The point is that domains allow the pathalias database to be distributed
around the network.  This reduces map maintenance overhead tremendously,
as well as reducing the size of database to keep on your machine.

Here is an example for 'user@SEISMO.CSS.GOV': (.UUCP implied)

	first, find SEISMO.CSS.GOV.  If found we have a complete route.
	otherwise, find .CSS.GOV.  If found, forward message to there.
	otherwise, find .GOV.  If found, forward message to there.
	otherwise, find .UUCP.  If found, forward message to there.
	otherwise, we are stuck and can't deliver the mail.

If the user types 'user@seismo' instead:

	first, find seismo.  If found we have a complete route.
	otherwise, find .UUCP.  If found, forward so they can look up
		'seismo' for us.
	otherwise, we are stuck.

Of course, 'foo!bar!..!..!seismo!user' will still work.  If, however,
a machine on the way is running smail, it might try to find a shortcut
to seismo from its paths file and change the routing.  (This option
is configured when installing smail.)  This can be annoying if
the short cut doesn't work.

P.S.  I am just reading up on this myself and am explaining it partly
to help my own understanding.  Please correct me (and I'm sure
somebody will) if any thing I said is incorrect.
-- 
Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>