Jim: This is the last time I'm going to respond to you on this topic. Everyone else understands my point, and there's a limit to how much effort I'm going to go to correct a single obtuse individual.
---------- Jim Choate[SMTP:ravage@einstein.ssz.com] wrote 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?...
$50 is nothing, of course. Requiring that each message to be encrypted with the final recipient's public key is far from nothing. Sending 10^5 emails without encryption is trivial. Encrypting 10^5 emails is far from trivial. We're raising the cost to the spammer far more than we're adding to the effort of the remailer operator. You speak of gatewaying - who exactly is going to set up a free gateway to encrypt 10^5 messages, each to a different public key? All that does is shift the cost to the gatewayer; it does not eliminate it.
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.
Jim: go back to the genesis of this thread. The discussion was along the lines of "There are too few remailers. Why?" Among of the reasons cited are that remailer operators often get shut down by their ISPs or network poviders because of complaints from end recipients of messages - they get spam, threats, illegal material, etc. It does not matter that the remailer keeps no logs; the end recipients mail server does, and that's enough for the recipient's ISP (or the LEAs) to take action. This situation not only gets remailers shut down; it discourages people from starting them in the first place. My proposal makes using the remailer for spam economically prohibitive, and ensures that the only recipients are crypto-aware types, who are far less likely to misunderstand what's going on than J. Random Luser.
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.
There you go again... Please read the thread. The goal is not to 'stop spammers'. It's to 'Stop actions against remailers, some of which are caused by their misuse as spam conduits'. Preventing spam from exiting the remailers achieves that goal.
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.
That's true. The use of doomed (since they'll be dropped before they leave the network) spam messages as cover traffic is something that occured to me as I wrote the letter. It is a nice side effect of my proposal, as long as spammers continue to send doomed spam into the system.
Where's the key management mechanism to ensure the security of the traffic in the reamiler network?
Same as it always was.
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'.
No Jim, I'm not talking about decreasing the load due to spam. I'm talking about making life easier for remailer operators. In the long run, it'll reduce spam as well, since spammers will learn not to include remailers which send only encrypted mail in their remailer chains.
The solution to bad speech is more speech, not regulation. And don't kid yourself that setting up such a mechanism isn't regulatory.
A remailer operator can operate his remailer in any way he or she wants, and so long as they publish their policies and adhere to them, there is no basis for anyone to criticize them (this is a thing called 'freedom').
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?
Jim: I think I'm beginning to appreciate the depth of your lack of comprehension. Remailers do not encrypt anything. All the encryption steps are done by the originator of the message - successively encrypting the message with public key of the recipient (an optional step in current remailers), and then by the public key of each remailer in the chain working back to the originator. Each remailer decrypts the message with it's private key, All it knows is to send the inner contents on to the next remailer in the chain, or to the final recipient. This is how remailer chaining works today. The only change I propose is that, if after applying it's own public key to decrypt a message, the remailer notices that the decrypted material does not match one of the well known formats for encrypted messages (ie, it is likely plaintext), that it drop the message. I won't discuss the recognition algorithm here, since I have already done so and others have even published sample code. It can be done.
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.
ROTFLMAO
James Choate
Peter Trei
participants (1)
-
Trei, Peter