Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!ittatc!dcdwest!sdcsvax!brian
From: brian@sdcsvax.UUCP (Brian Kantor)
Newsgroups: net.mail
Subject: Re: colons, atsigns, & domains in uucp path keys
Message-ID: <1714@sdcsvax.UUCP>
Date: Fri, 25-Apr-86 14:02:42 EDT
Article-I.D.: sdcsvax.1714
Posted: Fri Apr 25 14:02:42 1986
Date-Received: Sun, 27-Apr-86 07:19:39 EDT
References: <404@geowhiz.UUCP> <13328@ucbvax.BERKELEY.EDU> <899@decuac.UUCP> <20592@styx.UUCP>
Reply-To: brian@sdcsvax.UUCP (Brian Kantor)
Organization: UCSD wombat breeding society
Lines: 74

Gatewaying between networks is a bag of worms - especially when the
networks have completely different semantics for mail addresses - not
just syntax differences, but the addresses MEAN DIFFERENT THINGS!

For example:  a  simple internet address (e.g., brian@sdcsvax.ucsd.edu)
is just that: the destination (or at least the intermediate
destination) of a mail message.  No route is necessarily implied.  But
a uucp address (e.g., ucbvax!sdcsvax!brian) is also a ROUTE to the
destination.

When we at UCSD move a message from uucp to the internet, we do so by
rewriting the from address into the local-part of the address and
adding us as the domain part.  So a return address of 'bang!crash!jam'
will appear in the From: line of the message on the internet as
'bang!crash!jam@sdcsvax.ucsd.edu'.  The semantics are preserved if all
the internet hosts obey RFC822, which essentially says to evaluate and
satisfy the domain part (right of the @) before doing anything with the
local part (left of the @).

In the other direction, from the internet to uucp, we translate the
internet domain address to a banged form, and prepend our host name in
the normal uucp manner.  So mail heading out to a uucp host from an
internet host will have a nice uucp-readable return address, but one
that preserves the semantics of the internet address.  Most uucp
mailers will not care, but a few with 'smart routers' can look ahead
down the address and optimize - especially if they themselves are on
the internet.

So we'll put an address out on uucp that looks like this:  if the
original message came from the internet with a From: line of
wombat@seismo.css.gov, we'll send out the message via uucp with a
return address line of "From seismo.css.gov!wombat remote from sdcsvax"
and "From: sdcsvax!seismo.css.gov!wombat".  And we understand those
addresses when we get them back from uucp hosts.

Additionally, to support a kludge, we take addresses of the form
"...sdcsvax!user@host" and drop the "...sdcsvax!" part, to yield
"user@host".  This fixes up stuff from uucp hosts that goes to the
internet.

Ah, but what about our hidden local hosts (a hundred or so of them)?
Well, on the internet, we hide them in the local part of the address -
as "user%hiddenhost@sdcsvax.ucsd.edu".  On uucp, its not possible to
hide it, but we have to make sure that the outgoing name doesn't
conflict, so we use our full domain name for the host; this gives a
uucp return address like "sdcsvax!hiddenhost.ucsd.edu!user".  Since no
uucp map nor table is going to have an entry for "hiddenhost.ucsd.edu"
unless WE advertise it, this works well.  We could even have a local
host called "ihnp4", although that would be really stupid to do.  It
would be ok, though, as the return address on mail from our local
stupidly-named host would then be "sdcsvax!ihnp4.ucsd.edu!stupid",
which is legitimate.  We won't do that particular one, but how many
host names on campus MIGHT conflict nationwide if we didn't use this
scheme?

This scheme isn't perfect.  It fails miserably on malformed addresses,
on RFC822 explicit-route addresses, and the like.  We don't see many of
those, so I've not taken the time to do it "right".  Yet.

So the moral of the story is - we're trying to accomodate wholly
different types of addresses in gatewaying mail.  There are ways to do
it that cause a minimum of disruption on the outside.  It isn't simple.

I'm open to suggestions on ways to do this better.  And just wait until
we get connected to MFENET and Bitnet!  Gadzooks!

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA
			+1 619 452-6865

	decvax\ 	brian@sdcsvax.ucsd.edu
	ihnp4  >---  sdcsvax  --- brian
	ucbvax/		Kantor@Nosc