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

R. Armiento wrote:

>>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?

My original point was, this should be configurable for the user, i.e., 
for the recipient.  They should be given a choice---do I want to be 
(possibly) reimbursed if someone requests my attention, or do I want 
them to solve a puzzle?  However, the puzzle might easily become fairly 
complex.  Quite to the point where the recipient could make money out of 
it.

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

The difference is that web forms are easy to modify once spammers figure 
out how to bypass them.  Modifying the email protocol is more involved.

>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.

Spammers (no, I don't have the source handy) have already said they 
would resort to cheap labor if that becomes a necessity to let everyone 
learn about their, erm, products.

Bottom line:  You should inflict a certain cost on senders.  Their pain 
must be real for this to prevent spam.

>>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?

Debuggability: not much of a difference.
Resistance to switch: not much of a difference.
As to kids:  If the captcha says, "which of these dolls is the cutest so 
you would ask Santa Claus to bring it to you?"---not much of a 
difference.

Chances are, parents would set up closed-group email for their kids and 
their friends.

>>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.

I haven't yet been, say, to a restaurant that would have preferred if I 
did the dishes rather than paying the check.  Besides, solving captchas 
is more like a waste of a human's time than human work.  In other words:  
Yes, it may be costly to solve the puzzle, but it doesn't benefit anyone 
if you do.

>>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?

I don't see what's wrong with the example.  Once in a year, just before 
XXX-awareness day, the XXX-awareness foundation would like to send out 
1M "thank you for your ongoing donations" messages.  To people who did 
donate and are thus believed to be interested in what the XXX-awareness 
foundation did with the money.  True, some of them will get annoyed and 
seize bonds, which is supposed to compensate them for their annoyance.  
Most (since the bulk sender targetted the message properly, right?) 
won't be, will even consider donating even more to that organization 
they had almost forgotten about, and it's the XXX-awareness foundation's 
experience that overall, everybody is happy.

BTW, the XXX-awareness foundation cannot afford to spend, on average, 
more than 0.1¢ per message.  Since their experience is that ~2% of their 
audience will feel annoyed, they are willing to post 5¢' worth of bonds 
per message.  If, as a recipient, you impose a minimum of 50¢, you won't 
be contacted at any time.

>>>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.

It would be, "send an email to this address," which the victim would 
attempt to.  When they click "send," their MUA would repond, "this 
recipient requires that you pledge $$$ for anti-spam purposes."  With 
the equivalent of "please enter credit card number" following.

>>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.

In other words, you are assuming that you know better than email 
recipients how to protect them from spam?

>Internationalization also becomes basically impossible with freely 
>configurable CAPTHCAs.

Why?

>>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 :)

"Your inquiry has been received, and one of our customer specialists 
will get back with you soon."  Seems polite and therefore desirable.
(Although, for reasons I cannot fathom, these things rarely get the 
In-Reply-To: header right.)

>>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*?

Repudiable.  You don't have a dictaphone running all the time when 
speaking to people face-to-face, do you?

>Crypto systems normally want non-repudiability (= people can not deny 
>later that the key is theirs).

Not necessarily that the key is theirs, but that the signature is 
theirs.  You convince someone that you /could/ sign something, but you 
don't do it in such a way that anyone could prove that you actually did.

>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.

Allowing the recipient of a message to potentially use it as strong 
evidence (say, in court) against the sender is a bad idea as it impedes 
on natural communication.  Therefore, it must be possible for a sender 
to repudiate their signature they use to authenticate themselves against 
the recipient's whitelist.

>In the case of CAPTCHAs I'd argue that a *repudiable* system is

... pretty much undefined.  What is that?

>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.

Anonymous electronic money exists.

Oh, it involves C/R, though.


--Joachim