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

Joachim Kupke wrote:
> Spam is entirely avoidable (albeit the collateral damage would be 
> substantial) if you make senders pay for their messages. Ideally,
> by posting a bond that may be seized by the recipient if they
> classify the message as spam.

Making senders pay for their messages is exactly what CAPTCHAs do. The 
payment, however, is in a fixed-length human working time. Unlike a 
monetary 'postage' this translates well between different economical 
realities in the world. Also, a scheme that charges money has to give 
that money to someone; leading to a significant risk for fraud schemes 
being invented. Furthermore, stolen money is 'free', so spam may stil 
exist --- but being paid by unfortunate people with hacked computers 
(but perhaps that was the collateral damage you referred to?)

To reiterate, a postage system with money will have these problems:

1. The value of the "attention span" of someone living in a rich economy 
may be more than someone in a poor economy is prepared to pay.

2. Owners of hacked computers would have to pay for the activity of 
spammers.

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!

These problems seem avoidable by using CAPTCHAs.

> If, under this proposal, you end up sending messages in a 
> single-hop fashion (which, save for ISP-hosted mail servers, is how 
> email works 99% of the time right now), use HTTP, where even if you have 
> proxies or whatever sitting in between source and destination, there is 
> a way for the destination to return answers that are detectable as such 
> (as opposed to, "Hi.  I am the qmail-send program....").

You make a good point for using HTTP as the transport protocol. But it 
seems to me that one has to chose the lesser of two evils. Either:

Suggestion 1, use HTTP:
Good part: HTTP is built for single-hop communication, with proxies 
being available etc.
Bad part: Current MUAs speak SMTP, so one has to extend them to also 
speak HTTP (i.e. implement a full 'email-over-HTTP' protocol) (and also 
HTTPS for encrypted emails).

Or

Suggestion 2, use SMTP but in single-hop mode:
Good part: MUAs already speak SMTP, so less implementation needed.
Good part 2: SMTP already provides a well defined protocol suited for 
email transfer; e.g. error codes, extensions, acceptable delay times, 
etc. are defined by accepted standards.
Bad part: Single-hop SMTP is currently being blocked in many current 
networks. Such setups would need to install an SMTP proxy.

I don't get why you think '1' is obviously a superior solution.

[David Sanchez]
>> When i write a mail to, say, a workgroup of 30 people I don't want to 
>> resolve 30 chinese, japanese, swahili nor portuguese puzzles anyway.
[Joachim Kupke]
> Ah, mailing lists.  Nope, the mailing list would prompt you to solve the 
> puzzle.  Or pay the money or whatever.

Or, you rely on some semi-automatic scheme for white lists for your 
friends / work groups.

This leads back to the discussion about how to authenticate senders. 
However, 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.

[David Sanchez]
>> Think about this situation: [Critical email has to be sent but
>> remote server is down]
[Joachim Kupke]
> Either, that email is important enough for me to watch it getting
> sent out. [...] Or, as with this message, lives won't necessarily be
> lost if I fail to reply to qsecretary as soon as possible.

I fully agree with this view. For a *critical* email it makes *more* 
sense for me to get to know right away that it could not be delivered so 
that I can try other means of contact. For a non-critical email, *in the 
rare case the recipients email server is down* I can just as well press 
'send' again next time I open up my email program. (If the receiver is 
not happy about waiting for that email, he should keep his email server 
running, or setup a redundant server.)

Best regards,
Rickard