Bear discussed using hashcash-alike tokens as a challenge response from the filtering MTA back to the sender giving the sender a chance to compute a hashcash token. This approach has the problem you identify -- namely that email is store and forward; email can and often does go through multiple MTAs on it's path to delivery, and the MTA doing the filtering may be multiple hops from the sender. Indeed sometimes the filterer is the end-user who is also intermittently connected. It's more convenient and fits better in the store-and-forward setting if all email already includes the token at time of sending. If it turns out to be needed, then there is no interactive challenge-response needed. Then the question is whether computing the token at sending time would be incovenient for the normal sender. This depends on what parameters you choose. A few seconds probably wouldn't be noticed, especially as with deep MUA integration the token can be computed on each recipient address as soon as it is selected for receipt. Depending on MUA usage therefore the token could be computed while the sender is composing the message. In addition it is expected that there would be a mechanism whereby regular correspondents would white list each other. (Probably automatically via their mail clients). Whether you think a few seconds is sufficient depends on your views of the economics of spamming. Ie how close to losing break-even the spammers are, and whether a few seconds of CPU per message is enough to significantly increase the cost. This article for example discusses the economics of spam: http://www.eprivacygroup.com/article/articlestatic/58/1/6 they give an example of a spam campaign with a 0.0023% response rate, and a yeild of $19 per response. They estimate the cost of sending the spam was less than 0.01c per message. I've seen significantly lower estimates for the sending costs. To deter a given spam campaign we just have to increase the cost to the point of making it unprofitable given the response rate and profit per responder. The other side of this equation is what a second of CPU costs in monetary terms to a spammer. (To an end user it is essentially free because his CPU is mostly idle anyway; the limiting factor for the user is his preference for fast mail delivery (and in the dialup case an unwillingness to sit waiting for tokens to be calcluated before his mail can be sent). Adam On Mon, May 12, 2003 at 08:53:25AM -0500, Matt Crawford wrote:
This doesn't fit Joe Lunchbox's current model in which he dumps his outgoing mail onto his provider's server and turns off his machine. His provider either has to deliver synchronously and bounce the computational payment burden back to Joe, pay it for him, or bounce the message. In the latter case, the receiver who demanded cycles needs to recognize the problem it set and accept the answer on a later date.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com