Re: Remailer reply addresses

[gtoal@an-teallach.com (Graham Toal)]

Ah!  I'm glad conversation on this thread has picked up - I was afraid
no-one was interested.

:Graham's suggestion about automatic remailer reply chains reminded me of
:a simpler system which I would like to see.

:Suppose one site, somewhere, would create new mail addresses upon request,
:and map them to encrypted remailer chain blocks.  (These are nested remailer
:requests, where the outer layer is encrypted for the first remailer and tells
:it where to send the message, the next layer is encrypted for the 2nd remailer
:and tells it where to send, and so on.  No remailer sees anything more than
:where it is sending the message and where it received it from.)  A new account
:is created which maps, say, to a file which has one of these "anonymous return
:addresses" in it.  Any mail incoming for that address simply gets sent to the
:remailer in the file, with the ARA stuck in front of it.

That's pretty much what I was thinking of, except you don't need the
pseudonym server.  I find this stuff easier to talk about with examples
than in general, so here's what I'm thinking about:

I mail to first remailer (R1).  The remailer inserts my reply address into
the mail, encrypted, and either mails it to the recipient if I gave one,
or to the next remailer if I specified a remailer chain - or to another
remailer at random on it's own whim if it feels like doing so.

Let's assume it's going to another remailer then.  This next remailer (R2)
takes the header block with my reply address in it, and prepends what *it*
sees as the reply address, ie remailer R1.  It then encodes this into an
identically-structured reply block, and inserts *that* in the mail instead
of the original reply block, before passing it on.

This can be repeated as often as desired - the mail will always have
only two parts where-ever it turns up - an encrypted reply-block and the
text.  Let's say it ends up on the n'th remailer, Rn.

When the real recipient gets the mail and replies to it, the reply goes
to remailer Rn, and Rn can decode the header block.  The decoded header block
contains an address, and extra text which happens to be a fully-formatted
header block itself.  This extracted, smaller, header block is put back into
the mail instead of the one which was just decoded, and the mail is sent
back to the address that was extracted.

eventually it goes through umpteen remailers, and R2 passes it back
to R1.  R1 decodes the header block, finds *only* the address - no
nested header block, and passes the mail back to the user at that
address.

So the whole thing is really a trivial protocol - just

  <start of header block marker, for remailer to locate it>
  email address
  djhfkjsdhfdshf (opaque text from previous encryptions) kjfhkdhfkdhfkd
  dfkdfkjdfkhdf  (possibly on multiple lines) jhldkjodkfdjfljdlfkjldjdl
  <end of header block marker>

Sure, this could be extended to put all sorts of neat features in
the encrypted area, but I rather like the simplicity of just keeping
it to a plain username@site on a single line.


:With this software I could do something which cannot be done today.  I could
:send mail to which someone could hit "r" to reply, and receive that reply,
:without any one person knowing my pseudonym.  This is not that much to ask
:for!  I'd say it is the bare minimum for the use of pseudonyms on the net,
:yet we don't have it, after all this time.  And look how close we are to
:being able to do it.

Absolutely!  That's what I want too.

:With this basic system in place, some of Graham's ideas about time-limited
:or use-limited pseudonyms could be applied as well.  Other extensions people
:have suggested would have the pseudonym server hold messages in inboxes until
:people trigger a dump to a freshly created anonymous address.  A lot of things
:are possible.

I agree entirely except I don't see the need for a pseudonym server - just
the normal remailer reply address should be enough (so that people who
can't create aliases can run this stuff on remailers out their personal
accounts) which is why I think the blinded reply addresses should be in
the *body* of the mails.  (Smart mail software would scan the text for
these and handle stuff like indentation etc.  It doesn't seem too difficult
- I already use procmail for something like this where I scan for PGP
blocks in mail and decrypt them on receipt where possible)

:But we should walk before we run.  Right now I don't feel that we are even
:crawling yet.

hh@soda seems to have shown us how to walk :-)

G