1996-05-18 - Re: SEVERE undercapacity, we need more remailer servers FAST

Header Data

From: jim bell <jimbell@pacifier.com>
To: snow <cypherpunks@toad.com
Message Hash: a87850be961eb48284275c8cd2ba67e4cdfb791571aa9133fa5d74344a85cb8e
Message ID: <199605181752.KAA10188@newmail.pacifier.com>
Reply To: N/A
UTC Datetime: 1996-05-18 23:30:52 UTC
Raw Date: Sun, 19 May 1996 07:30:52 +0800

Raw message

From: jim bell <jimbell@pacifier.com>
Date: Sun, 19 May 1996 07:30:52 +0800
To: snow <cypherpunks@toad.com
Subject: Re:  SEVERE undercapacity, we need more remailer servers FAST
Message-ID: <199605181752.KAA10188@newmail.pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain


At 06:44 PM 5/17/96 -0500, snow wrote:

>	How about this as an idea:
>
>	Get a few (3 to 5) accounts in a high density market (i.e. lots of
>ISP's locally) set up a unix machine on a cheap machine. Have the anon
>messages get sent to the pop accounts. Once an hour (or less depending on
>budget) have the unix box poll the different pop accounts mix the messages
>and resend them the next hour. 
>	This could be further obfuscated by batching the messages up and
>posting a whole chunk of messages to a different similar remailer else
>where, or by just plopping an encrypted tar'd file on a ftp site where
>another remailer grabs them and splits and remails them.

It seems to me that if we consider that there are two separate functions remailers provide:

1.  Anonymization.

2.  Jurisdiction swapping

Then perhaps one way to improve the robustness of remailers against 
copyright-type legal attacks is to provide remailers with temporary (1-2 
week) remail-only sites.  All material would be processed by the front end, 
then delivered in bulk to the other site.   This sounds similar to the idea 
you described.

That way, the remailer's "front end" can stay around for years, developing 
reputation.  Any attack on copyright would simply be an attack on the back 
end, which wouldn't last anyway.



Jim Bell
jimbell@pacifier.com





Thread