I've reordered several sections of the discussion. At 07:18 PM 10/13/00 -0500, Jim Choate wrote:

On Fri, 13 Oct 2000, Trei, Peter wrote:

...

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.

Back tracing is only necessary if They weren't eavesdropping in the first place. Remember that the goal of remailers is to prevent serious attackers from tracing traffic, not just to prevent complainers from succeeding. If you allow unencrypted incoming traffic, you lose. If you allow unencrypted outgoing traffic, you also lose, unless the destination is a public Usenet forwarder or something. The only unencrypted email you should be delivering to normal recipients is something like "Hi! An anonymous person who you know wants to send you a secret message. Get PGP at www.pgp.com and publish your keys" Eric Hughes and Raph Levien did some work a few years ago indicating that message sizes may be enough to analyze traffic flows in a Type I remailer network anyway - you need to go with Mixmaster or maybe even Pipenets for security. Of course, no Bad Guy would *ever* think of eavesdropping the PGP.com or MIT keyservers to do traffic analysis on key requests.

...

A spammer (or your spammer's proxy) is not going to individually encrypt messages to thousands or ... 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?...

If the spammer can get a gateway to do the work of fetching keys and encrypting messages for millions of spam targets, the gateway is probably toast for a few weeks anyway. Remember that the spammer has all the time they want for pre-computation - they're only vulnerable once they start sending out mass quantities of messages. (On the other hand, what spammers do lack is clues and creativity.) It used to be possible to extract keys from the PGP keyservers, which meant that a low-tech spammer could nab 5-20000 email addresses and a high-tech spammer could also nab that many crypto keys. I've heard people say there are over a million keys in the current LDAP servers; I haven't explored whether it's easy to bulk extract them (e.g. query on "email address includes '@'".) If you wanted to build a custom crypto-spamware for this volume, you've got a few advantages over vanilla PGP. The bulk of the mail message is the same for everybody, so there's no need to encrypt the body multiple times - just encrypt it once and use the same symmetric key for each, and only do the public-key part separately for each target. If there are message parts that do change, e.g. the encrypted part contains the "Request-Remailing-To: target37@wherever.com" and the remailer doesn't enforce encrypted-outgoing-only, you can still make it work by exploiting CBC's self-synchronization. Set up the message so the variable line is padded to a whole number of cypher blocks (e.g. N*8 byte) ending with two of whichever Carriage Return/Linefeed you need, then two more blocks of disposable junk, then more real text (again, probably starting with CR/LF), and the CBC will misdecrypt the disposable blocks but sync up again afterwords. Ugly, but shouldn't be particularly destructive, if you can survive the occasional unprintables. This lets you only do hard work for the public-key encryption and the symmetric-key parts that surround it, without having to do symmetric-key encryption on the whole message every time. It's much tougher to pull this off for something that needs to create good cyphertext as its output, so it's much tougher to trick remailers with encrypted-outgoing-only. You at least have to duplicate encryption for more PGP header, but you might be able to get past it into the message body safely. If you're doing a long spam, it may still be worthwhile, though if all you're sending is two blinking multicolored lines of Get your RED-HOT SPAM HERE http://www.spam-monger.com/ you probably weren't creative enough to have done this much work :-)

...

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.

There are two problems - spammers and harassers. The prevalent cypherpunks remailer attitudes toward spammers seems to be keeping them from overwhelming your resources and making sure complaints about spam go to /dev/null or the apology autoresponder instead of your real mailbox, but more serious harassers can get you shut down faster. A harassment apology autoresponder helps a bit, but encrypted-only-outgoing radically reduces the threat, and keeps most of the spammers abusing other people. If you're running your own Tier 1 ISP, and you host Spamford, you can become the next Dead AGIS, but it takes a *lot* of complaint. If you're running your own small ISP, you're relatively safe, but enough complaints can get your Tier 1 upstreams to drop you. But if you're just a customer, your ISP may have some tolerance level but a determined abuser can still get you shut down.

...

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.

Middleman remailers don't get complaints except about resource utilization - Peter had addressed the issue that exit remailers need some protection from spam complaints, but for middle remailers you just don't need to worry. (You still need encrypted outgoing for security, but if your output only goes to remailers that enforce encrypted incoming you don't need to implement anything yourself, though it doesn't hurt you.)

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?

PGP web of trust works fine, just a bit slower from there. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639