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
participants (5)
-
Andrew Loewenstern -
Ben Holiday -
Black Unicorn -
jonathon -
Rich Graves