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    <}+++<