Re: An alternative to remailer shutdowns

On Tue, 21 May 1996, Declan B. McCullagh wrote:

> An alternative I am considering would reduce the utility of the remailer
> while still allowing these "consensual" uses to continue.  Presently the
> remailers deal with abuse via "block lists", sets of addresses that mail
> can't be sent to.  Generally these are created when someone complains
> about some mail they have received.  By setting up blocking, at least
> they will not get harrassing anonymous mail once they have complained.
> But in some cases, as in the case that is causing me headaches now, even
> one message is too much.
> 
> My thought is to turn the block list concept on its head, and make it a
> "permit list".  Simply, the remailer will only send mail to people who
> have voluntarily indicated their willingness to receive it.

How would you know that the message you received is actually from them? I
don't see how this would really help.

I like the "knock-knock" approach, though it would of necessity impose
load. If someone has an anonymous message waiting, send them a simple note
with instructions on how to retrieve it.

 From: Anonymous Remailer <hfinney@shell.portal.com>
 To: random person <somebody@there.com>
 
 An anonymous message is waiting for you. If you wish to receive this
 message, simply send an email message with [some unique string, maybe an
 MD5 hash of the actual message] in the body of a message to
 hfinney@shell.portal.com. The simplest way to do this is to reply to this
 message, quoting this text. 

I certainly think that limiting newsgroup posting would be prudent. It's
inexcusable that it's possible to use anonymous remailers to post
*forgeries* (see the smoking flames cross-posted to alt.syntax.tactical). 

-rich

On Mon, 20 May 1996, Rich Graves wrote:

> On Tue, 21 May 1996, Declan B. McCullagh wrote:
> I like the "knock-knock" approach, though it would of necessity impose
> load. If someone has an anonymous message waiting, send them a simple note
> with instructions on how to retrieve it.
	
	That way you could also charge the recipient to retrieve
	a message. 

	How about a farthing to recieve a message, and 
	two farthings to send a message, no charge to 
	mixmaster recipients or originators?

        xan

        jonathon
        grafolog@netcom.com


**********************************************************************
*								     *
*	Opinions expressed don't necessarily reflect my own views.   *
*								     *
*	There is no way that they can be construed to represent      *
*	any organization's views.				     *
*								     *
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*								     *
*       http://members.tripod.com/~graphology/index.html             *
*								     *
***********************************************************************

On Tue, 21 May 1996, jonathon wrote:

> On Mon, 20 May 1996, Rich Graves wrote:
> > On Tue, 21 May 1996, Declan B. McCullagh did NOT write:

[Oops, I was replying to Declan's forward of Hal Finney's message, and got
the attribution wong. The path cypherpunks -> fight-censorship -> me 
is often faster than cypherpunks -> me, probably because unsubscribing
and resubscribing put me way down on the list. Sorry. This was Hal.]

> > I like the "knock-knock" approach, though it would of necessity impose
> > load. If someone has an anonymous message waiting, send them a simple note
> > with instructions on how to retrieve it.
> 	
> 	That way you could also charge the recipient to retrieve
> 	a message. 
> 
> 	How about a farthing to recieve a message, and 
> 	two farthings to send a message, no charge to 
> 	mixmaster recipients or originators?

That sounds like a great opportunity for denial-of-service attacks. No,
thank you.

A flat fee for a special-delivery service profile (gimme $5/month and you
get messages automatically, without the confirmation) would be fine, but I
can't see paying per piece to *receive* anonymous messages.

-rich

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.

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.

As far as I can tell an agreement of this form would be at least as valid
as the software licenses ("NOTICE: Opening this envelope constitutes your
agreement to the terms.. blah blah blah") that are commonly used today.
Also would seem to be a similar concept to "Opening the case of this
device void's your warranty" stickers on appliances.

Under this approach persons would receive mail whether they'd consented or
not (unless they requested to be blocked). But it would be difficult for
anyone to raise any serious legal issues about something they havnt read,
and impossible for them to make noise about what they read, after the
implied consent they gave when decrypting.

Under both approaches it would be wise to have a list of addresses who've
already consented, which would contain all of the known remailers..
whether or not an operator chose to have names besides remailers in the
list would be at his/her discretion.

Ben..

Ben Holiday <ncognito@gate.net> writes:
>  As far as I can tell an agreement of this form would be at
>  least as valid as the software licenses ("NOTICE: Opening this
>  envelope constitutes your agreement to the terms.. blah blah
>  blah") that are commonly used today.

IANAL, but I have one, and he said (a couple of years ago) that these  
shrinkwrap contracts are practically worthless without a signature.  At least  
this was how things were being handled in some districts.  Anyone care to  
comment?

crypto relevance:  Can RSADSI __really__ enforce the silly "thou shalt not  
call certain functions" restrictions in their 'license'?  I doubt it, but I  
would love for someone to prove me wrong.


andrew

On Tue, 21 May 1996, Andrew Loewenstern wrote:

> Ben Holiday <ncognito@gate.net> writes:
> >  As far as I can tell an agreement of this form would be at
> >  least as valid as the software licenses ("NOTICE: Opening this
> >  envelope constitutes your agreement to the terms.. blah blah
> >  blah") that are commonly used today.
> 
> IANAL, but I have one, and he said (a couple of years ago) that these  
> shrinkwrap contracts are practically worthless without a signature.  At least  
> this was how things were being handled in some districts.  Anyone care to  
> comment?

I concur.

> 
> crypto relevance:  Can RSADSI __really__ enforce the silly "thou shalt not  
> call certain functions" restrictions in their 'license'?  I doubt it, but I  
> would love for someone to prove me wrong.

This is closer.  You're asked to accept the terms of the license or return
the product.  It's a stronger issue and more likely to be upheld.

> 
> andrew
> 

---
My preferred and soon to be permanent e-mail address:unicorn@schloss.li
"In fact, had Bancroft not existed,       potestas scientiae in usu est
Franklin might have had to invent him."    in nihilum nil posse reverti
00B9289C28DC0E55  E16D5378B81E1C96 - Finger for Current Key Information
Opp. Counsel: For all your expert testimony needs: jimbell@pacifier.com

On Tue, 21 May 1996, Ben Holiday 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. 

Interesting idea, but anything requiring specific software on the user's
end is a losing proposition IMO. 

remailer-operators@c2.org removed cuz I ain't one.

-rich