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

> Captcha has various problems, [...]

I think you misunderstood the original proposal. It was specifically 
designed to avoid the problems with traditional three email 
back-and-forth challenge-response used today for email CAPTCHAs.

The CAPTCHA data is to be communicated *inline* in the outgoing SMTP 
session when sending the email.

Hence, your points "1, 2" does not apply.

> 3.- i18n, for example, if one of my users sends a message to a user in
> an american domain for example, the american MTA will send him a
> captcha message in English

I agree that it is nontrivial to design an internationalized CAPTCHA 
protocol (to be inlined in the ESMTP protocol). However, remember that 
much of the instruction texts in the CAPTCHA dialog box can be provided 
by the MUA, and thus in the users language.

Hence, e.g. for CAPTCHAs of type "identify the characters in the 
picture", no internationalization is needed for all countries using the 
Latin Alphabet.

> 4.- as you stated in note [4] should not be assumed that a mail user
> has access to remote MTA. Moreover, if its accesible maybe it's
> temporary down or unreachable (that's why your relay MTA has remote
> queue in the first place ;-P )

Actually, the bounce messages returned when a recipient's email server 
is temporarily down tend to confuse users. An immediate response in a 
MUA dialog box with "could not send email, remote server is down." would 
probably be less confusing.

I believe the Internet has changed enough for this feature of original 
SMTP to no longer be very important. Users today seem to expect 
immediate results, or no results at all, anyway.

Best regards,
Rickard