On Fri, 13 Oct 2000, Trei, Peter wrote:
A spammer (or your spammer's proxy) is not going to individually encrypt messages to thousands or millions of end-recipients, each with their own public key - the time factor makes this uneconomical, and the hassle factor of finding all the recipient public keys makes it impractical. Thus, only remailers which send out plaintext are useful to spammers as exit remailers.
They do it now, sans encryption. The mass distribution is what makes it economical. If the encryption can be gateway'ed then it's useless and doesn't raise the cost significantly. A more useful mechanism would be to distribute the keys and appropriate client software to spammers. What's a flat $50?...
It is only exit remailers (ie, the remailer which sends to the final recipient) which get hassled for sending spam.
And it has NOTHING to do with the encryption. The lack of log's is what prevents back tracing.
The goal is to make remailer operators life easier by preventing them from being used to spam random lusers, who may initiate complaints against the remailer operator.
No, the goal is to stop spammers. In addition, there are aspects of remailer operation that make the complaints about spam pretty irrelevant.
It is not to prevent spam passing through a remailer somewhere in mid-cloud. While such encrypted spam will increase the volume of traffic, for most remailers that is a Good Thing - more material to confuse the traffic analysis. As long as it gets dropped before leaving the remailer network, no harm is done.
Nobody said anything about the interim processing until now. How is this relevant to the 'free speech' aspect of requiring the use of particular forms of encryption end-to-end. Where's the key management mechanism to ensure the security of the traffic in the reamiler network?
Steve understands this, as does every one else but you.
What's the problem?
It's your problem, there are aspects of this proposal that are simply silly, and several others that haven't been adequately explained or examined. You talk about decreasing the load due to spam, and don't even recognize that you've replaced it with a whole other process. One that potentialy could be more complicated, error prone, and expensive in time and resource impact than the original 'problem'. The solution to bad speech is more speech, not regulation. And don't kid yourself that setting up such a mechanism isn't regulatory.
Any remailer operator can decide not to pass along plaintext. So long as the message sender is aware of this property, nothing more needs to be distributed. There are no increased sysadmin issues.
What algorithm are you proposing to identify plain-text? There are key managment issues, what is your proposal for this problem? There is the increased complication of admining the box (think of resources to support both the remailer operation as well as the encryption - consider that scale carefuly). I'm in Zimbabwe and the remailer is in the US, how do I manage the keys to enter the network in such a way that it is secure?
No, there is not, beyond the fact that the message originator must know the final recipient's public key.
You need the key to get into the remailer, otherwise how does it tell the message is encrypted? You seriosly propose sticking some static PGP header for example will stop anyone, spammers know how to use word processors too you know.
Jim, do you really understand how remailer chaining works?
Yep. Apparently better than you do. Have a nice day you pretentious butthead. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------