Re: PR Problem?

DeLesley SpamBox wrote:
> 
> I'm not convinced that even a naive sender pays wouldn't be helpful.
> Let's say I use a cheap stamp that takes an average of 1 second to
> generate on a mid-level PC.  This shouldn't be too onerous on most
> hardware, with the possible exception of PDAs.

http://camram.org/zombiecalc

make assumptions about the number of zombies, how much leakage you will 
permit and you can get the stamp size.  It's quite entertaining.


> If the average zombie is putting out more than 1 spam per second, then
> adding a stamp makes the spam output go down.  If a spammer has to
> invest in a few more quad-core servers to make stamps, then costs go
> up.  Maybe the spammers aren't out of business yet, but at least they
> are making less profit, and putting out less spam.  All the criticisms
> I've read treat the problem as an all-or-nothing affair: if HashCash
> can't guarantee that all spammers go out of business, then it's not
> worth implementing.

you are falling into the classic trap of assuming that the cost of 
hardware mean something.  This is the fallacy behind the Ben Laurie 
paper.  It's important to remember that the cost per stamp drops with 
every stamp generated with a given piece of hardware.  The first step is 
very expensive if that's all you generate about if you are cranking out 
stamps to the tune of 1440 stamp minutes per day, the cost per stamp 
drops really fast.

You do have the right angle though in that stamps reduce spammer 
profitability and at some threshold, they won't make enough money to 
stay in business.  The number of zombies will decrease and be more 
easily targeted.

> 
> But this is a foolish way to think about it.  Naive proof-of-work is
> dead simple to implement.
> Compared to other proposals, the cost of implementation is almost
> zero.  So there doesn't have to be a lot of benefit before the
> cost/benefit analysis makes sense.

actually does.  The cost of implementing hash cash is trivial.  It's 
been done.  But the cost of transition is very high and you need 
backwards compatibility so that those who are still running with 
sendmail 5.x or Eudora 2.0 can play along or at least not be penalized.

So if we're going to transition people, we want to make sure it's a 
high-quality transition with lots of value through increased reliability 
of good e-mail delivery and low overhead of maintaining their filters.

> Moreover, proof-of-work integrates well with existing spam filters.
> Stamped mail shouldn't be allowed to bypass the filter altogether,
> because then you really -do- need to put the spammers completely out
> of business in order to make things work; I don't want my inbox
> flooded with zombie-stamped spam.  Instead, just treat the stamp as
> another piece of data that's input into the learning algorithm.  The
> filter will learn how much postage spammers are willing to pay, and
> filter mail accordingly.

this is probably a philosophical disagreement.  I absolutely of abhor 
false positives.  I look in the dumpster maybe once every couple of 
months if somebody tells me something was lost.  I look in my spam trap 
about once a week.  If somebody is going to send me a message with a 
stamp, I have no problem with it coming through directly.  If it's a 
spammer, I want to be able to mark it as spam and then permanently 
blacklisted IP address and tell all of my friends about it automatically.

to use a stamp or even a stamp size as a scoring factor actually works 
in the spammers favor.  By crafting a message the right way and just 
putting a little stamp, maybe 10 seconds worth, they would be able to 
almost guaranteed delivery.  While at the same time, you would still end 
up subjecting legitimate users to the risk of mischaracterization of 
their messages.  That is not a win.

> My guess is that at least at least 50% of all e-mail would have to
> start using stamps before the spammers even bothered to calculate
> their own.  The target market for spam is gullible and
> non-technically-minded people, not careful e-mail users with
> sophisticated anti-spam technology.  That means that HashCash users
> could start seeing significant benefit for several years before the
> spammers caught up.

this is another reason for direct delivery on stamps.  Your stamp is an 
introducer.  It guarantees delivery to the inbox.  This is a win.  This 
mean customers don't have to worry about their mail getting through.

Which raises an interesting demo for businesses.  With the Java stamp 
generator in a webpage, you could create a method of generating stands 
for ordinary e-mail when communicating with a business using proof of 
work stamp gateways.

With the stamp generator, it would be possible to create a mailto entry 
with a stamp.  I don't know if the mailto will let you create new 
headers but, even if it doesn't, sticking the stamp in the subject line 
might not be such a bad idea for delivery.

there are a variety of ways of presenting this information to the user 
but the important thing is they would introduce the concept of stamps 
and people could become accustomed to the concept.  The only downside is 
that the spam generation process would be in the foreground and 
therefore there may be some bad PR from that.


> 
> Once proof-of-work systems start to see serious adoption, and spammers
> respond with zombies, then we can start the move to more sophisticated
> hybrid systems.  It's good to know that bright people are thinking
> about such systems, and have possible designs in mind, but I don't
> think we need "The Solution(TM)" to start an initial rollout.

remember, transition costs are really expensive.  We want to do it good 
enough that we can survive some of the zombie attacks and that will give 
people more confidence in our technique than just a simple brute force 
bloody ignorance approach of naïve sender- pays.

Also remember that a hybrid system is not necessarily expensive.  A 
hybrid system on output is a series of predicates deciding whether to 
generate stamps or not.  If I was clever, I would figure out how to do 
plug-ins or dynamic add-ins for the predicates in Python and that way we 
could  roll out new predicates as we come up with them for twopenny blue 
or any other system using the same plug-in technique.  But no, I'm sorry 
to say that I am not that clever but I am willing to learn.


> 
> I do agree that hybrid proof-of-work systems are the best way to
> eliminate spam in the long term, simply because they have the most
> potential for tweaking and improvement.
> However, a hybrid proof-of-work system is a wonderful example of a
> Complex Adaptive System.  Detailed analysis and modeling of such
> systems is enormously difficult, especially if humans (spammers +
> users) are part of the loop.  It will be much easier to improve the
> system if there is actual data from HashCash users on the 'net to
> analyze.

as I said above, they're not necessarily expensive.  Plug-ins would make 
it easier to adapt.  Feedback loops are essential and yes those are 
complex adaptive systems.  But you know, what I have worked.  I have 
three years experience with the system in the field.  Granted that's 
only a few sites but they are seeing significant benefit.

I'm hoping to find someone who knows enough Perl that they could modify 
a rdd framework displaying mailfilter statistics.  I would love to have 
a grass that I can point people to saying "see, this is how the friends 
list works, this is how the spam filter works etc. etc." but I haven't 
found anyone yet.  And I have not enough time or energy to dive into 
that particular part.
> 
>> If you add on top of that the idea that a DNS record...
> 
> But this requires a change to the DNS service, which means much higher
> cost of deployment.  It's a great idea, once there is a large enough
> user base to make it worthwhile.

esj@camram606:~$ host -t txt harvee.org
harvee.org descriptive text "hcrv=0:hcsv=1:bits=26:vwin=5d"

here's an example of what I meant.  I don't remember what the fields 
were at least the first two I think they may have been something like 
camram version and stamp version if memory serves.  But this is the 
basic text record.  Now there may be other things we need to do because 
of collisions with text records used in other contexts so we might want 
to create a standard domain name form.  But, it's not complicated.  And 
it has the added political advantage that it further reduces 
"unnecessary" stamp generation.

Remember the primary emotional objection is that they don't want to 
spend their time generating stamps.  Doesn't matter how or why they just 
don't want to spend their time because they don't believe it will do any 
good.  So, when I counter that with a what if I minimize stamp 
generation, the susceptibility factor goes up but they can't wrap their 
head around how intermittent stamp generation can improve things.  Then 
I shake my head and mutter something about bad at math.

So, the political/emotional landscape says we must reduce stamp 
generation whenever possible.

> 
>> If you are skilled in making a Thunderbird plug-in, then by all means,
>> build a stamp generator and output in a filter that detects outgoing
>> stamps and not generate any additional stamps.
> 
> If I was familiar with the Thunderbird code base, I could probably
> write a plug-in in a couple days.  Unfortunately, I'm not -- which
> means I could easily spend a couple months deciphering APIs.  I'll
> take a brief look and see how hard the problem is.

consider a different solution.  What would it mean to create a proxy.  I 
believe I have the pieces you would need for an MTA independent 
Macintosh/Windows stamping proxy.  Inbound filtering via Pop three, 
that's much harder.  That's really really much harder.

>> so I think the real answer to your question is, we're exhausted.  We
>> don't have enough people doing real work to make demonstrably functional
>> code in this area.  I've done the best I can and I'm not going to make
>> any apologies for it.
> 
> I certainly wasn't asking for an apology!  I have nothing but respect
> for anybody who devotes time and energy to solving a real problem.  I
> reserve my contempt for naysayers who spend 5 minutes thinking up an
> objection, and then stand in the way of progress because they think
> that they know more than the actual researchers.  :-)  It seems to be
> a popular occupation... :-(

here's another idea for proving the concept.  I will donate my time and 
energy to set up a twopenny blue mail system if somebody else will 
donate their time and energy to set it up for a "free" e-mail service 
for people wanting to experiment with this kind of anti-spam 
environment.  I think we'll also need somebody to donate hosting.  I 
really don't want responsibility for this in my basement.  I don't have 
my autostart generator yet.

This would allow us to get started.  We would probably need a few other 
machines to generate stamps as a captive zombie net unless, we add the 
predicates which say if you don't advertise you have that capability, we 
don't generate stamps.

I also have this gut feeling that using SMTPAUTH authenticated 
connections, we could act as a remote filter for entire domains but 
setting up the accounts might be a bit problematic given the 
requirements for uniqueness.  Need to think about that one.

So, is anybody going to step up to the plate and make me regret 
volunteering my time?