1996-05-25 - Re: Long-Lived Remailers

Header Data

From: “E. ALLEN SMITH” <EALLENSMITH@ocelot.Rutgers.EDU>
To: hendersn@zeta.org.au
Message Hash: 7118aac7f8823d397eca16892e131681cfb3a4bb4f5e3df122a4b378debd4784
Message ID: <01I53G3L1NBU8Y4Z90@mbcl.rutgers.edu>
Reply To: N/A
UTC Datetime: 1996-05-25 04:20:23 UTC
Raw Date: Sat, 25 May 1996 12:20:23 +0800

Raw message

From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Sat, 25 May 1996 12:20:23 +0800
To: hendersn@zeta.org.au
Subject: Re: Long-Lived Remailers
Message-ID: <01I53G3L1NBU8Y4Z90@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"hendersn@zeta.org.au" 23-MAY-1996 11:35:09.98

>I really like this idea. How about instead of a full-scale remailer being
>the final jump of the message, you have a _very_ simple remailer set up
>along the lines of anon.penet.fi. No encryption, just strip off the headers
>and send the message to its final destination. Sorry for being clueless in
>how this works(I'm learning as fast as I can), but wouldn't this kind of
>system be incredibly easy to start up and fold? You could have a host of
>such final emanation points winking in and out of existence while the actual
>encrypting remailers remain relatively safe.

	Well, an anon.penet.fi one has the disadvantage of not encrypting
between the final sendings.... which means that it's relatively easy to trace
back a given message to whatever remailer sent it, via traffic monitoring.
A forwarding remailer that decrypted mail according to a published key would
get around this, especially if it were being run out of a POP or other email
forwarding account (otherwise, the operator of the system could just look and
see what the private key was, and thus be able to trace back).
	-Allen





Thread