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

David Sanchez:

>1.- Since current SMTP protocol is not authenticated you can't assure 
>that the recipients is who sends the message. This can lead to mail 
>bombing to people who has nothing to do with original mail send. 

I guess the proposal was not to bounce messages but rather to keep 
state.  Think:

 - DNS lookup:  Does recipient support protocol?  E.g., when sending to 
   [email protected], first lookup A record for fancyprotocol.bar.com, then 
   fall back to looking up MX record for bar.com itself.
 - HTTP conversation with host fancyprotocol.bar.com, essentially 
   tunneling whatever challenge response scheme you may have in mind.

("Conversation" means that HTTP requests get properly tagged with 
session ids/cookies/whatever.)

>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, which is likely  to be discarded as spam 
>for my users, or simply don't understood (bounces in current 
>infraestructure is a good real world example)

A valid point, but you're optimizing prematurely.  People who speak only 
one (natural) language themselves will just configure their MUA to ask 
the equivalent of "please solve this puzzle" in their native language.  
If I send a Spanish message to a person who asks me to solve a puzzle 
stated in Chinese, that just makes the puzzle the more entertaining for 
a non-speaker of Chinese. ;-)

>2.- As a consecuence, a new world of DoS is open  :-(   (a spammer for 
>example can make a mail server to generate continues captcha mails, 
>which is resouce consuming)

Doesn't sound like a huge problem, though.  How is this different from 
captcha systems that try to avoid web spam?

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

True, but forcing the MUA to maintain the remote queue is a better 
choice, anyway.  Although it deviates from tradition, this would make it 
obvious to the user if/which messages are stuck.

The real problem with captchas is that it's too easy for spammers to 
forward the captcha to some site that advertises free porn and to thus 
let humans solve your puzzle semi-automatically.

In the long run, we may need challenge-response systems, but the kind of 
challenge (a captcha-style puzzle, a [small] instance of a 
computationally hard problem, or a request to post a bond, ...) would 
need to be entirely customizable.


--Joachim