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