1996-05-22 - Re: An alternative to remailer shutdowns

Header Data

From: droelke@rdxsunhost.aud.alcatel.com (Daniel R. Oelke)
To: cypherpunks@toad.com
Message Hash: 975e46e6066b21aa3deb9ae62c143d15bdba9e534b924e562ffb77dd05cd4c21
Message ID: <9605212220.AA05507@spirit.aud.alcatel.com>
Reply To: N/A
UTC Datetime: 1996-05-22 05:24:20 UTC
Raw Date: Wed, 22 May 1996 13:24:20 +0800

Raw message

From: droelke@rdxsunhost.aud.alcatel.com (Daniel R. Oelke)
Date: Wed, 22 May 1996 13:24:20 +0800
To: cypherpunks@toad.com
Subject: Re: An alternative to remailer shutdowns
Message-ID: <9605212220.AA05507@spirit.aud.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain


Ben Holiday <ncognito@gate.net> wrote:
>
> After pondering a bit it seems to me that the "knock knock" remailer
> approach (only send anon-mail if the recipient agrees to receive it) could
> be made feasable pretty easily.
>
> Rather than hold the mail while waiting for a consent to release, you
> could simply encrypt the peice of mail with a symetric algorythm on its
> final hop, and send the encrypted mail to the recipient.
>
> At this point there are 2 options, which I havnt examined closely: The
> first is that you require them to send a request for their "consent-code"
> which can be used to decrypt the mail. Under this arrangment you could
> possibly provide for a user to specify a specific consent code, so that 2
> party's who had previously agreed to communicate could avoid "knocking".
> If you strip the subject, then it would be all but impossible for a person
> to include the consent code in the actual peice of mail.
 
This could be done with no "storage" as well, by a slightly
different method and still require end reciepient acknowledgement.
The end reciepient could be required to reply and include the encrypted
message. The remailer would then decrypt the message and send back the
plaintext.  Only storage would be the key vs. a message id database.
 
> The second is to simply include the
> consent-code along with the encrypted peice of mail and a legal notice
> stating that decryption of the mail constitutes your consent to receive
> the mail, as well as your agreement to hold the remailer-operator harmless
> should the mail be found to be in some way offensive. Further, the
> recipient would agree to be solely liable for the contents of the mail,
> etc etc.. I leave the actual agreement to the net.lawyers to figure out.
 
By reduction - you could just do a rot13 on the message and
append the "legal notice".   If all the information for decoding
a message is present in that message, is a different encoding
mechanism really any different from straight ASCII text?
(i.e. Netscape 9.13 might have auto decoding built it....)
Then, the user doesn't do anything "extra" - does this invalidate
the notice?
 
I might be wrong, but I don't think that this second method would
gain you anything in the 2 situations where operators will get
hassled.  1) Posting of copyrighted material - the lawyers will
at least harass you no matter what kind of legal notice is up front.
2) Mailing of "harassing" information - the person still gets
unwanted email, and has no way to stop it.
 
> [... legal ideas deleted ...]
 
Heaven forbid that I use spammers as an idea base, but
to borrow something from them.... Set up the headers
on an anonymous message such that a Reply would result in
the user automatically being placed on the "deny" list.
 
This means that only 1 message gets through.... but, as
Hal has noted, that might be 1 message too many.
 
Similarily, a message sent to the user could be the
"knock", and then a reply would automatically add the
user to the "allow" list as well as forward the
message.... just an automatination of the "knock" idea.
 
Dan
 
------------------------------------------------------------------
Dan Oelke                                  Alcatel Network Systems
droelke@aud.alcatel.com                             Richardson, TX






Thread