#83 key.redirect not handled correctly

[Wesley Tanaka]

GalePublicKey.getRedirectTarget()

(3) In this positive key reply, look for the
key.redirect field. If it
exists, its value must be merged with the key name and
the original
location to produce a new location. First, count the
number of components
in the local part of the key name, excluding any
trailing '*'. Remove that
many components from the beginning of the local part of
the original
location. Also remove the domain from the original
location. You will be
left with zero or more components from the end of the
local part of the
original location. Append this string to the local
part of the location
stored in the key.redirect fragment. The location thus
produced is the
merged location. Go to step (1) and repeat the process
with the merged
location. Use the merged location rather than the
original location for
all further purposes when dealing with this message
(such as category
generation, UI presentation, etc).

[Wesley Tanaka]

Logged In: YES
user_id=11717

[@ofb.net/user/pub/comp/gale/] from Dan Egnor (egnor@ofb.net)
The key.member fragment(s) list the names of other keys
which are considered
members of the key in question. Membership is transitive.
When a message is
sent to a location which matches a key, it is encrypted for
all keys in the
membership set of that key. The empty string means "all
people", i.e. do not
encrypt.

[Wesley Tanaka]

Logged In: YES
user_id=11717

[@ofb.net/user/pub/comp/gale/] from Tessa Lau (tlau@ofb.net)
Merge: for example, bar.foo@ofb.net could contain a
key.redirect to
ugcs@ugcs.caltech.edu. If someone puffs to
bar.foo.baz@ofb.net, the merged
location is ugcs.baz@ofb.net.
Also see the logs for pub.gale.dangermouse.protocol on
6/12/2001. (yay logs)
[@ofb.net/user/pub/comp/gale/] from Tessa Lau (tlau@ofb.net)
Oops, I mean the merged location is ugcs.baz@ugcs.caltech.edu.