From: pstemari@erinet.com (Paul J. Ste. Marie)
To: cypherpunks@toad.com
Message Hash: 1999a4d8d238a828416fa92264fd22819be5f04f9c90a62b61bbf88bc14aa500
Message ID: <9501220404.AA12395@eri.erinet.com>
Reply To: N/A
UTC Datetime: 1995-01-22 04:12:49 UTC
Raw Date: Sat, 21 Jan 95 20:12:49 PST
From: pstemari@erinet.com (Paul J. Ste. Marie)
Date: Sat, 21 Jan 95 20:12:49 PST
To: cypherpunks@toad.com
Subject: Remailer exit points
Message-ID: <9501220404.AA12395@eri.erinet.com>
MIME-Version: 1.0
Content-Type: text/plain
Y'know, after some thought, some of the concepts I made regarding data
havens with anonymous locations might well apply to making exit-point
remailers that are relatively immune from outside pressure. Given a network
of entry-point remailers with well-known public keys, you could advertise an
exit-point remailer by only giving out encrypted address blocks for use with
various well-known entry-point remailers and a public key. The exit-point
remailer could then substitute some random From: address and path entries to
spoof the exit-point remailer's location. The remailer's actual location
would only be known by the entry point remailers, and since their
involvement is stripped by the exit-point remailers, no one would know who
they are to complain to them.
The spoofed exit-point remailer location could be handled by disposable MX
entries, of the sort discussed here earlier, if it is deemed desireable to
make the From: address valid. The remailer operator could get the actual
complaints, to deal with as he would.
--Paul J. Ste. Marie
pstemari@well.sf.ca.us, pstemari@erinet.com
Return to January 1995
Return to “pstemari@erinet.com (Paul J. Ste. Marie)”
1995-01-22 (Sat, 21 Jan 95 20:12:49 PST) - Remailer exit points - pstemari@erinet.com (Paul J. Ste. Marie)