On Fri, 12 Jan 1996 16:22:03 -0800, Alan Olsen wrote:

At 10:25 PM 1/12/96 GMT, John Lull wrote:

...

On Fri, 12 Jan 1996 10:55:12 -0800, you wrote:

...

Cypherpunks: is there any way to respond to, or prevent, this sort of attack short of actually shutting down the remailer?

Yes, very simply.

The remailer could calculate a hash for the body of each encrypted message received (the same portion which will be decrypted by PGP), tabulate the last few thousand hashes, and simply discard any messages with a duplicate hash. The target of the attack would receive only the first copy of the message.

I am afraid it is not that simple. Remember that the mailbombing consists of many, many horny little geeks responding to a single message. They are replying to the same message (and probibly adding a few "me too!" lines), not mailing the same one over and over again.

The specific attack referred to had an entire encrypted message, not just a reply block. Obviously this solution does not work if only a reply block is encrypted.

Another idea would be to keep a md5 (or other) hash list of the reply block used and have a disabled list for such spam attacks. (Unfortunatly this requires code, thus time.)

Even worse, it requires manual intervention for each attack unless you are willing to add reply blocks to the list based simply on the volume of messages using that reply block. That could prevent the remailer network being overwhelmed, but is not likely to be seen as adequate by the target, who would likely still see the first several dozen messages before the specified threshold was reached. There is another related solution for the attack using just a reply block, however. The final remailer could collect messages either using a given reply block, or addressed to a given address, if more that a few were received in a relatively short period of time. It could then forward the first half-dozen or so, along with a note that another X thousand messages were waiting, and asking if the intended recipient wanted them forwarded or trashed. Unfortunately this would not prevent the remailer network from being overwhelmed. Perhaps some combination of these solutions would be required -- rationing based on the reply block at each remailer, and collection & recipient notification at the final remailer.