economics of spam (Re: A Trial Balloon to Ban Email?)

[Adam Back]

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 at metzdowd.com