One of the many schemes that have been proposed to fight junk e-mail is HashCash.
The basic idea is that a HashCash token is a string which a particular property that make is hard to create, but easy to check if that property is present.
The way you use it is to require that anyone who sends you Email, and who isn't on your whitelist, must include a new HashCash token in the mail item. This proves that they have done a measurable amount of work for the privilege of sending you mail.
The value of this is that spammers, who tend to need to send tens of thousands of emails just to get a few responses, would not be able to afford to generate these tokens and so wouldn't be able to get their mail through to you. On the other hand, individually who want to send you one mail (and hopefully then get onto your whitelist) would have no problem with the cost of generating a hashcash token for you.
One problem with the scheme as proposed is that you need to keep a list of all hashcash tokens that you have received so that a spammer cannot generate just one and use it over and over again.
My idea is to overcome that problem by making hashcash tokens safely reusable.
The original HashCash token has the format
0:TTT:destination@address:SSSS
TTT is a timestamp, and SSSS is a string chosen so that the SHA1 hash of the whole string has a sufficient number of leading zeros bits (e.g. 20). It is the task of finding a suitable SSSS that makes a HashCash token hard to compute.
I would propose introducing a new format:
1:TTT:one@address:other@address:SSSS
The key difference is that there are two addresses, one a sender address and the other a recipient address.
When checking a token, the recipient would extract the two address and see if one was an address of the recipient. If one was, they would check to see if the other was a believable address of the sender. This way a token really authorises a two-way communication. If you send someone an email, they don't need to generate a token to reply, they just use the token you sent.
For this to work reliably the sender must be known with some authenticity. In general this is hard. However SPF might hold the answer. It helps provide a measure of authenticity at least to the domain part of the return address.
Though SPF provides some authenticity, the Sender Rewriting Scheme that is associated with SPF can make it harder to extract the local part of the senders address from the mail envelope. Some sort of partial matching would possibly be needed. The detail would need to be carefully thought through.
This scheme would not be strong enough to completely reject all mail that does not have any HashCash as many people won't send it, or won't be able to send from an SPF-compliant mailer.
Each recipient would need their own policy on how to deal with different email. One might be to let all mail that either had verified HashCash or was verifiably from a sender on their whitelist straight though, and to file all other mail for inspection every day or so.
If this became a burden, they could automatically bounce any mail that went into their greybox with a message indicating how to generate the required HashCash.
For people who cannot send from an SPF-compilant mailer, they could be advised to generate a stronger HashCash token. The recipient might accept a strong (say, 23 zero bit) token with a very recent timestamp (less than 20hours ago) from anyone.
There are still problems with this scheme, particularly with repect to mail from non-SPF compliant addresses. It is hard to reliably send automatic replies to would-be correspondants without the risk of them going to inocent parties.
It would normally be safe to send them to SRS0 addresses though. So if everyone were either SPF or SRS complient, that would make it work. Well, maybe one day...
