A Trial Balloon to Ban Email?

[Sunder]

The current cost to the spammer is currently nearly zero.  To add hash
generation for each email might slow things down a bit, but throwing more
hardware at it gets around this.  Hardware is cheap, and old out of date
PC's are plentiful.  The bandwidth cost is the same, the CPU cost and time
is a bit higher, but not much.


170,000 email addresses is what one CD offered.  Assume that spammer bob
sends emails to that many from lots of servers, say it takes one or two
hours.  Most spams are small, some are over 20-30K (gif attachments, and
other crap.)

Each time this happens - (from my point of view I get about 50-60
spams/day that I filter) each of those recipients turns around and sends
some traffic attempting to auth the micropayments via the micropayment
bank.  That's a DDoS from the point of view of the bank.  

Even if it can handle the traffic it has to do lots of CPU intensive work
and send the error back to each of those requests, which will result in
rejection of 169,999 requests and 1 acceptance (assuming the spammer is
using a valid coin in the 1st place.)  It becomes expensive to run the
mint.

The 1st time a significant number of users start using this scheme, the
spammers will adapt to get around to it.  Just like they've already
adapted against keyword searches by using text such as e'n'l'ar'g'e'
'y,o,u,r, `pe`n`i`s__n_o_w.

Again, from the spammer's point of view, they don't necessarily care that
you recieved the email.  They sell advertisements for a price.  Say you
have an ad, you go to the spammer, he spams 170,000 emails with it for
$10.  He doesn't give a shit if less than 1% of those will get the spam -
he charges his client the same.

Say, things get harder and he has to adapt, well, he'll just charge his
clients more for the trouble and advertise it as a value add that it's
garanteed that x% will be read (never mind that idiot client hasn't got a
way to prove it one way or another.)


You have to think about it from their point of view to find out what they
could do to get around it.  

Then you have to think about it from the bank or mint's point of view, and
the traffic and CPU operations, it will have to deal with.

Does this solution make it exponentially harder for spammer to deliver the
spam?  Does this incur cost to the recipient?  Does it incur cost to the
mint? and so on.

Looking at this problem from the spam recipient's point of view isn't
enough.

>From my point of view, if my MTA has already spooled the spam, I've
already lost my bandwidth, and thus lost some value.  Doesn't matter that
I never see the spam.  Bandwidth was already wasted receiving bits that
wind up in /dev/null and cpu cycles to make the decision to drop said
bits.



----------------------Kaos-Keraunos-Kybernetos---------------------------
 + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of   /|\
  \|/  :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\
<--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech.  \/|\/
  /|\  :Found to date: 0.  Cost of war: $800,000,000,000 USD.        \|/
 + v + :           The look on Sadam's face - priceless!       
--------_sunder_ at _sunder_._net_------- http://www.sunder.net ------------

On Wed, 14 May 2003, Declan McCullagh wrote:

> It is true that the notions of micropayments as applied to spam (that I'm 
> familiar with, at least) would require that the email recipient check with 
> the bank to detect doublespending. This would introduce an additional delay 
> before delivery from unknown senders, yes, but I fail to see how it would 
> impose an unacceptable cost in bandwidth or CPU usage.
> 
> Spammers could still try the same-micropayment-a-million-times route, just 
> as they could try to spam without micropayments, but if their email is 
> rejected in sufficient quantities, the cost to the spammer would outweigh 
> the benefits. The key is achieving sufficient quantities.