Re: CAPTCHA over smtp (yet another spam solution to discuss)

Joachim Kupke wrote:
> R. Armiento wrote:
>> Unlike a monetary 'postage' [CAPTCHAs] translates well between different 
>> economical realities in the world.
> 
> Solving captchas, given that computers cannot do that, is a lot like
> currency. [...] They could just as well be made to pay money for their 
> business.

So, you basically conclude that "CAPTCHAs and money are equally good in 
preventing spam". But then why not standardize on CAPTCHAs instead of 
working out the difficult details needed to integrate email and money?

Web forms use CAPTCHAs rather than monetary charges for a number of good 
reasons. These reasons are relevant also when approaching email.

> There may be a barrier of entry, but it'd become commonplace to hire
> cheap labor to let humans solve the captchas for spammers.

This is the third time this argument pops up, and I *still* think it has 
no bearing on spam as we know it today. To quote myself from an earlier 
email:
="=
While sweatshops of cheap labor and "forwarded CAPTCHAs" are bad
enough to cause problems for e.g. "get a free web page" web forms, I
just cannot see how this scales to a point where current
email-mass-marketing is even remotely possible. Only my own spam trap
addresses would cost an hour of human labor per spam run. But
*targeted* commercial emailing could still work.
="=

> The collateral damage [with a monetary email system] lies in the fact
> that our new email protocol will be pretty hard to debug, people
> won't like to switch over, etc. Plus, I'd rather live in a world
> where I could introduce my kids to the Internet (ummm, text-based,
> I'd say), let them exchange emails, etc., all without money coming
> into play. But that's a tradeoff.

But these are tradeoffs that you don't have to do if going with CAPTCHAs 
instead of money, right?

> The other thing is, money is the one widely-agreed-upon resource that 
> would be versatile enough to let users customize email behavior in the 
> first place. 

I don't understand this argument; *human work* is an even more 
widely-agreed-upon resource than money.

> Charities might have a legitimate cause to send thousands 
> of emails (without being whitelisted on the recipients' side).  Should 
> they solve thousands of puzzles?  It's more likely they'll have a budget 
> (greater than $0; otherwise, they couldn't pay their Internet bill, 
> anyway), and that should be able to pay only so many unsolicited messages.

If I have given no consent to a charity to send me emails then, by my 
definitions, their emails are spam! This "problem" is just the system 
working as it should, as far as I can see. Can you come up with a better 
example?

>> 3. Scammers would immediately start posting all kinds of fraudulent 
>> attractive "mail offers" on web pages etc, to try to get as many 
>> emails as possible for which they could release the bonds. 
>> Flamebaiting would become a profession!
> 
> Well; I can probably access quite a few phony services on the web if I 
> were to give my credit card number away.  How is this different?

It is different, because "send an email to this address" has a much 
lower barrier than "enter your credit card number here". It is much 
easier to engineer scams that can fool a larger number of people when 
the scam is completed already when the their first email is sent.

> make sure you let users (i.e., recipients) decide how hard these 
> puzzles should be.  Now, if the puzzles become completely customizable, 
> I might just as well ask potential senders to give me just enough 
> information that I could use to be remunerated---if I wish to.

I have thought about this: but it seems dangerous to allow users to 
configure this themselves. Many clueless users will come up with 'too 
internal' CAPTCHAs which block emails from people they don't know (e.g. 
"What is my phone number?"). This leads again to a "closed email system" 
which is not my goal. Internationalization also becomes basically 
impossible with freely configurable CAPTHCAs.

> The real trouble begins if/when crappy software (on the recipient's 
> side; this is no instance of "spammers will just adust") accepts 
> messages but /still/ sends auto-generated stuff around (like 
> out-of-office replies, etc.).  Requiring a bond to be posted would be a 
> real impediment for any such nonsense. ;-)

But how will this be a problem for a CAPTCHA system? The out-of-office 
reply wont be accepted by my mail server without a CAPTCHA solution, and 
good luck with that when you are out of the office :)

> The important thing [for mail lists] is, the challenge is received in
> reaction to an attempt to send something. It must be the mailing 
> list manager that states the challenge to be responded to by the 
> casual poster to the list. If I subscribe to a mailing list but don't
> give the mailing list manager the means to bypass my spam filter (or
> equivalent thereof), my bad.

I completely agree.

>> for a CAPTCHA system I really think normal public key 
>> signatures are good enough. To create a new key is not "fatal", it 
>> just means you has to solve CAPTCHAs again until your new key gets 
>> added to your friends white lists.

> You may want to familiarize yourself with identity-based encryption.  
> But in any event, the real trouble about OpenPGP signatures is that they 
> are not repudiable.  Non-repudiability is a showstopper for any email 
> authentication system.

Eh? Do you mean you want the signatues to be *repudiable* or 
*non-repudiable*?

Crypto systems normally want non-repudiability (= people can not deny 
later that the key is theirs). However, I don't think this is needed for 
white lists. The key is used only to grant rights, "repuding" a key only 
looses you these rights.

In the case of CAPTCHAs I'd argue that a *repudiable* system is 
preferable. I think that is the only way non-spammy anonymous mailings + 
white lists can work together.

In fact, anonymous mailing is another thing that works "by default" with 
CAPTCHAs, but would be very, very, tricky to setup if money were involved.

Best regards,
Rickard