Re: remailer spam throttle
From a legal perspective, Greg is right. However, from a practical
perspective, the important impediments to running remailers are (1) mail recipients hate you and send lots of complaints and (1a) usenet readers hate you and send lots of complaints (if you still support news posting.) Andy's model of a remailer in which the remailer sends the recipient a delivery notice with a disclaimer/waiver/etc. and the recipient returns it to pick up the message raises the level of politeness and lowers the amount of surprise compared to current remailers, so it's a potentially big win. If I start up a remailer again some year, other than a middleman, it'll definitely need this kind of feature. Building the positive public reputation of remailers and remailer operators is a critical part of keeping the remailer system running, at least as much as convenient, widely-deployed software. For posting to Usenet, the "we have an anonymous posting, anybody want it" approach doesn't sound highly practical, though it could be done, but I'd probably limit postings to moderated newsgroups (where a human will be filtering out the blatant spam and abuse) and flame-tolerant newsgroups like alt.anonymous.messages and alt.flames. I find this highly frustrating, since one of the big wins about remailers is posting to talk.politics.* and alt.religion.scientology and other groups where posting your opinion with your name on it may be unsafe. There's also the problem of publishing acceptable newsgroup lists, since failing messages silently is unfriendly to users, but there's a traffic analysis problem (Bad Guys can watch who fetches remailer use policies and build up their dossiers.) Most of the problem with (2) Third Parties _can_ be helped a bit by disclaimers, by plausible deniability, by not having logs to subpoena, and by having remailers that you're willing to shut down with profuse apologies to head off lawsuits. It isn't a perfect job if someone really wants to go for blood by making you defend repeated lawsuits (especially if they're really targeting you, e.g. posting their Secret Documents through your remailer themselves to entrap you.) But it'll let most remailer users defend against most reasonable complaints. I do also agree with Greg that getting the sender of a message to indemnify you isn't worth the recycled electrons used for the log file you aren't keeping. That's especially the case if you're forwarding messages received from other remailers, unless you can get other remailer operators to indemnify you, in return for which you'd probably have to indemnify them. No thanks. At 01:58 AM 3/25/97 -0800, Greg Broiles wrote:
I think there are two broad models of complaints/problems with remailers: 1. The recipient is angry because they received a message they didn't like. (because it's an advertisement, or it's rude, or [....] 2. A third party is angry because the sender sent some information to the recipient which the third party thinks should not have been sent. (copyright, >trademark, defamation, tortious interference [...]
Your "contract" model (which looks like you really mean it to be a waiver of warranty/damages and/or an indemnification agreement) addresses (1) to the point of overkill, but it doesn't reach (2), because there's no contract with the third party, who is the party who's likely to be filing suit. (Indemnification by the sender might work, if you worded the contract correctly - but then you've got to abandon anonymity, and the value of indemnification from person you don't know whose assets/finances are unknown is pretty low.)
Further, some fraction of the messages causing concern are message sent or available to minors .. whose contracts (modulo some exceptions) are voidable at their option. :(
..[disclaimers].. [doesn't help 2 for same reason]
# Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)
On Thu, 27 Mar 1997, Bill Stewart wrote:
Andy's model of a remailer in which the remailer sends the recipient a delivery notice with a disclaimer/waiver/etc. and the recipient returns it to pick up the message raises the level of politeness and lowers the amount of surprise compared to current remailers, so it's a potentially big win. If I start up a remailer again some year, other than a middleman, it'll definitely need this kind of feature. Building the positive public reputation of remailers and remailer operators is a critical part of keeping the remailer system running, at least as much as convenient, widely-deployed software.
Well, I hope to have something for you soon. I've been too busy over the last few months to work on it, but that may be changing. I'll make an appropriate announcement when it's ready.
For posting to Usenet, the "we have an anonymous posting, anybody want it" approach doesn't sound highly practical, though it could be done,
I mentioned this in another post, but USENET posts would simply have the disclaimer and not a delivery notice.
There's also the problem of publishing acceptable newsgroup lists, since failing messages silently is unfriendly to users, but there's a traffic analysis problem (Bad Guys can watch who fetches remailer use policies and build up their dossiers.)
I've made stats/keys/help for dustbin available via WWW at http(s)?://porky.athensnet.com/~dustman/dustbin. The truly paranoid can use https://www.anonymizer.com. I have considered the possibility of auto-encrypting to recipients: Encrypt using the recipient's public key if it is on the remailer's keyring or on the key server (which I can quickly check via http). Two problems: What if the user generates a new key? Some mechanism needs to exist for the user to inform the remailer, since it already has a key on its keyring and won't check the server. And: Malicious users can put phoney keys on the keyserver so the real user gets encrypted stuff that they can't decrypt. Solution: Keys need to be verified by magic cookie exchange before they are used. Users mail their public keys to the remailer, perhaps even through a remailer chain. The software gets their e-mail address from the key ID, sends them an encrypted magic cookie, the user decrypts with their secret key, mails it back to the remailer (signed and encrypted). For a very low-risk remailer (more risky than middleman, perhaps), you could require all recipients to supply PGP public keys before delivering messages, an interesting twist on "PGP only" :). This would be great for nym chains, not so great for other things, though the remailer could resort to middleman operation in the case of recipients who haven't supplied keys. Dustbin does something related already: If the recipient is a known remailer, it doesn't chain; otherwise it selects a remailer to chain through. (Note: I don't consider a USENET group a "recipient".) -- Andy Dustman / Computational Center for Molecular Structure and Design / UGA You can have my PGP public key by sending mail with subject "send file key". You can have my PGP secret key when you pry it out of my cold, dead neurons. http://charon.chem.uga.edu/~andy mailto:andy@CCMSD.chem.uga.edu <}+++<
participants (2)
-
Andy Dustman -
Bill Stewart