From: mjr@netcom.com (Matthew Rapaport)
Date: Sat, 9 Jan 93 09:20:46 PST
To: cypherpunks@toad.com
Subject: Cascading Aliases
Message-ID: <9301091720.AA17521@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


****** Hal <74076.1041@CompuServe.COM> *****
>My understanding was that everyone who tried to talk to him would get
>two aliases assigned automatically.

Yes I suppose, but I can ignore them. Let's see if I got this right. In
the following scenario, I will represent alias servers and their aliases
in the following way: A-123 where 'A' is the server, and '123' is the
alias.

I receive a message from Z-999. I have no idea how many servers this has
gone through. I *originate* a message back to this person, but I sent it
first through *my* preferred alias chain, so the message goes from me
through A-123 -> B-456 -> Z-999 and then somewhere else (perhaps) before
reaching its final destination.

Now the Z server has never seen a message from B-456, so it
automatically generates a NEW alias (Z-111) for that ID. Now machine Z
bounces that new alias back along the chain B-456 -> A-123 and thence to
me, informing me that an alias has been established on machine Z for my
ID on machine B. It also uses that alias to send the message along to
the next machine on the chain (if there is one) which also creates a new
alias (never having seen a message from Z-111), and bounces it back,
etc. I see that this is where I get to detect the alias path my
recipient is using, but there is an easy solution (see below).

So one or more new aliases will be generated (you are correct) in
response to my original mail, BUT, I can ignore those aliases (once I
receive them in the reflected mail) and never need think about them
again because the link between B-456 and Z-111 is now established.
Further translation will take place automatically with no further bounce
backs in any future correspondence between the two parties *if* they
both use their own chosen mail paths consistently.

If in my next mail, however, I REPLY to Z-999 (i.e. I don't generate
original mail), then another alias will be generated on the Z machine
for mjr@netcom.com and I will also be informed of that, etc. Once again,
however, I don't have to care about that. From the recipients viewpoint,
however, mail has now been received from two different aliases that
represent the same person (one for my original mail, and one for my
REPLIES)

There are two possible solutions while still generating automatic
aliases:

1) Don't alias someone who hasn't specifically requested it (e.g. with a
ping or something). This is probably not a good idea. I like the fact
that these Aservers take a "most conservative approach" automatically
assuming that someone wants to be aliased if they are
originating/replying to an aliased ID.

2) Stop the alias-information-bounce-back unless someone specifically
requests it (e.g. with a ping). This might do the trick. I don't have to
KNOW what my alias number is even on the machine that does the first
outbound and last inbound conversion. All the conversions along the
chain are automatic, so why should I care what my alias numbers are?

matthew rapaport     Philosopher/Programmer At Large      KD6KVH
           mjr@netcom.com     70371.255@compuserve.com