Brainstorm?

Blocking mail floods is easier than blocking spam.

	1. Create a sort of blocking system that blocks everyone equally.
		(Think tarpit but not as extreme)
	2. Have an exceptions table where the user can add others that can
		mail him more often.

How does spam work? It basically floods to a number of recipients. Because of
the social engineering nature of the spam (that is, it is not just a flood,
but one that advertises something), the threshold for where flooding becomes
advantageous is lower than for pure DoS floods.

Therefore, one could imagine a challenge-response system that limits
transmission to X time units per mail. Hash cash is similar to such a system
but it is all done locally (using the laws of physics as limits) with varying
X. The problem with hash cash is, as mentioned, that X varies depending on
outside factors; for instance, if you have a powerful CPU [1] or specially
engineered chip you can circumvent it.

Given the idea above on an exceptions table for mailing lists, one no longer
needs to worry about legitimate mailing lists being denied service. Its
protocol could work as follows:
	When subscribing, the subscriber generates a random seeded proof of 
	being in the exception table.
	On each transmission, the list first checks that the subscriber has
	its transmission address in its database (by verifying the proof with
	the mail server).
	If it has not, the message is not sent.

The challenge-response system can be as simple as a DH- or EC-EKE with delays
between each exchange. 

[ Add a random token to the table so that a spammer cannot simply guess at
  "likely friends" and then punch through by setting himself as an exception;
  however, this would require a user to refresh his keys if a spammer installs
  a virus or something on his box; probably not worth it though ]

[1] But see "Time-lock puzzles and timed-release Crypto", R. Rivest et al, 
	1996. Is "repeated squaring" a good solution? Possibly not, as
	it requires changing the number of squarings every time CPU power
	increases.

-

Key management:
	Important:
		
		The spammer should not be able to get an index of the
			exempt addresses from the client alone (MUST) or
			either client or server alone (preferrable)

		The spammer should not be able to steal the key of the
			e-mail user, meaning that the authentication
			should be indirect

			Otherwise, when the spammer steals, as will likely
			happen when some sort of email program bugs (*cough*
			VBS/Outlook *cough*), the rightful owner will have
			to issue a new key with all that entails. We assume
			server operators are insufficiently foolish to
			compromise the keys.