(This is a continuation of challenge-response. However, it is automated and
 avoids the loops traditionally plaguing C-R.)

General idea:
	1. The sending client connects to the receiver's mail server and 
	   specifies his from address.
	2. Unless the from address is in the receiver's whitelist, the
	   receiver's mail server checks if the sender has any message
	   authentications set as not finished. If so, it aborts here.
	3. Unless the from address is in the receiver's whitelist, the
	   mail server notifies the sender of an user-specified time limit
	   and delays this time. At any time before this is elapsed, the
	   client can break the connection, which counts as a termination
	   of the authentication process without any transmission.
	   	(For mailing lists)
	4. The receiver's mail server does an MX lookup on the domain part of
	   the from address and sends two tokens A and B to the sender's mail 
	   server.
	5. The receiver's mail server sends B to the sending client.
	6. The sending client connects to his mail server and authenticates.
	   He then supplies B and gets A in return. (possible delay here)
	   B and A are at this point deleted from the sending mail server.
	7. The sending client connects to the receiver's mail server and
	   gives A, as well as his from address. If they match, he is allowed
	   to send a mail.

Restrictions:
	The same IP cannot send to any address having the same receiver mail
	server until the prior transmission's authentication phase is
	completed.
	(Mailing lists exempt? Whitelists? But then spammers can guess at the
	 whitelists -- no, because they still have to perform the
	 authentication part.)

Problems:
	- Spammers getting their own MX domains. (Should be countered by the 
		delay)
	- Mailing lists become tied up. (Should be fixed by whitelisting; but
		how do we dynamically whitelist all who join/part the list?
		Authentication neccessitates this unless we can create relays)
	- Parallel flooding. (Should be somewhat countered by the intra-ISP
		"IP lockdown")

This will eventually force spammers to move to a DDoS approach. This is easy
to see as impossible to stop on a "spam as flooding" level, because it is 
indistinguishable from one host sending a message times N hosts.

(What about one-to-many parallel queued flooding? One host contacts many ISPs
and do this stuff in parallel for each of them)

Pondering:
	We could possibly let off the MX restriction by adding these:
		- Only N parallel connections allowed from one IP.
		- Each host can only send one mail per authentication.
		  (Serializes intra-host spam.)