Re: CNN.com on Remailers
On 18 December 2001, Meyer Wolfsheim [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2001, David Honig wrote: Can't spam be repelled by not forwarding email not encrypted to the remailer's key? Who is to say that spammers won't use remailer clients that automatically encrypt to the remailers' keys? Using remailer clients should be *easy*. Saying this is too hard for the average spammer to figure out isn't acceptable. In fact, spammers currently *do* send mail encrypted to the remailers' keys. It's a pain in the ass trying to filter the damn stuff out. Ben Xain [EMAIL PROTECTED]
RE: CNN.com on Remailers
On 19 December 2001, Peter Trei wrote: Ben Xain[SMTP:[EMAIL PROTECTED]] In fact, spammers currently *do* send mail encrypted to the remailers' keys. It's a pain in the ass trying to filter the damn stuff out. First I've heard that. Frankly, I'm suprised. One solution, which I've long advocated, is for the remailer to drop mail which has an unencrypted body after it's applied it's decryption key. Provided this is an announced policy, substantially increases the protection of the mail and the remop. It does mean that only people capable of using encryption can receive mail via the remailer, but that's probably a *good* thing. I don't think that's necessarily a good idea. It would eliminate or reduce the anonymous remailer's usefulness for posting to newsgroups and mailing lists. Add to that the concept of some anonymous remailer users being informants or corporate whistle-blowers, who will often be contacting law enforcement or media officials and won't have access to public keys for encryption. Instead, it would be a good idea for remailers to find some other means of filtering spam. There are some great tools out there that might be useful for this, such as nilsimsa. Ben Xain [EMAIL PROTECTED]
Re: Pay per use remailers and remailer reliability tracking.
On 19 Dec 01 Len Sassaman wrote: (This isn't exact either. Failure, in this case, is pinpointed at the link between two remailers, rather than at a given remailer. If a user queried the bank and discovered that, out of a 5 remailer chain, remailers A, B, and C redeemed the tokens but D did not, this either means C is cheating, C is broken on sending, or D is broken on receiving. Further tests would be necessary to determine the exact nature of the failure.) Hmmm I have an idea about this. What if remailer C doesn't get to cash in on his tokens unless delivery to remailer D can be confirmed? Or maybe there is some other way to cut down on cheating. Ben Xain [EMAIL PROTECTED]
