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

Joachim Kupke wrote:
> R. Armiento wrote:
>> 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? 

You make it sound as if we implement one, we can as well implement both. 
Not so. CAPTACHAs can be implemented today just as a "protocol thing" 
(e.g. as discussed here, an extension to SMTP). Money systems require an 
interoperability between worldwide financial institutions which is not 
there yet.

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

That depends on the implementation. We have not yet discussed the 
CAPTCHA protocol, but I think it is fairly obvious that it must allow 
enough freedom to handle this.

>> I just cannot see how [cheap labor and forwarded CAPTCHAs] scales
>> to a point where current email-mass-marketing is even remotely
>> possible.

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

Spammers have also said that they can enlong my ***** quite a bit. That 
does not necessarily make it true. You just cannot argue "The economics 
will not work out" with "They said they will do it anyway".

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

Right, and CAPTCHAs and money schemes both do this. So can we agree that 
the "cheap labor" argument does not apply to either?

> [Comparing some features of CAPTCHAs and money systems:]
> 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.

I believe the resistance to switch is lower for CAPTCHA systems than for 
money systems. One argument is that apparently the resistance was not 
too high for it to work for web forms.

Regarding kids: Kids will just have to learn how to solve CAPTCHAs, 
similar as how they learn how to use other features of the MUA.

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

This is solved with email list semantics. If I want their "thank you 
notes and other messages" I should have white-listed them for this. 
Technically, their email software should just try to send emails 
automatically, and ignore all servers that ask for a CAPTCHA response.

Put more simply, I want "the solution to spam" to banish mass mailings 
without explicit prior consent. White lists are a good way to give such 
consent. I see no problem here.

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

What a horrible mess. Lets say I am the target of a number of focused 
advertising campaigns for e.g. mortages, so I have to raise my bond to 
50¢ to deter them. But then I stop getting emails from my belowed 
XXX-awreness foundation?!

> [Send an email to this address / recipient collects bond scams:]
> 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.

I enter my CC number on web pages a couple of times per year. However, I 
will click 'yes' on the send email dialog 20 times per day. In fact, if 
the $$$ is less than some well chosen max amount, my mailer will be 
setup not to show these dialogs, or it would drive me crazy. So, no, 
these "dialogs" are not the same.

>> I have thought about [to what extent CAPTCHA puzzles should be 
>> configurable]: but it seems dangerous to allow users
>> to configure this themselves. 

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

Yes, I do. For certain users. With enough freedom for end-users to 
design their own CAPTCHAs I can easily imagine having the following 
conversation over and over and over:
- No one can send me emails any longer since I activated that CAPTCHA 
thing to get rid of spam that you recommended!
- Lets see -- hey, you have created a CAPTCHA that requires the sender 
to enter the wrong answer!
- Oh... stupid thing... it should have told me.

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

If people aware of the issues with internationalization are the ones who 
design the CAPTCHA exchange, these issues will be addressed.

If end-users design their own CAPTCHAs they will tend to embed all kinds 
of language and cultural references in them without realizing. The guy 
with "What is my phone number?" perhaps thinks his CAPTCHA is great, 
because "people who do not know me can just look me up in the phone 
book". He might not realize that his phone book is not available where I 
live.

>> Do you mean you want the signatues to be *repudiable* or 
>> *non-repudiable*?
> 
> Repudiable. 

I have always thought that the hard part is to make any system 
non-repudiable. OpenPGP signatures are repudiable to some degree:
* Erase your private key and denounce all emails you sent with that key
* Claim that your private key was stolen by a third party.
* Claim that you wrote the email with a gun to your head.
* Claim that you accidentally left your terminal logged in, and someone 
must have sent an email while you were out.
etc. etc.

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

A CAPTCHA system could *maybe* be designed for this to work by making it 
indeterminable if a specific email got through based on solving a 
CAPTCHA or invoking the whitelist. However, lacking this is hardly a 
show-stopper.

If non-repudiable email is a showstopper for you, you could just chose 
to not invoke white lists and solve a CAPTCHA each time you send an email.

>> In the case of CAPTCHAs I'd argue that a *repudiable* system is
> ... pretty much undefined.  What is that?

Never mind the clumsy formulation: I agree with you that *if possible* 
it is good to avoid non-repudiable signatues being default for email.

> Anonymous electronic money exists.  Oh, it involves C/R, though.

Do you have a reference? I do not know of any existing solutions that 
let my purchase be anonymous both to the the buyer and all third parties 
(i.e. "the bank"). I do not want my bank to know to who I am sending emails.

Best regards,
Rickard