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

David Sanchez:

>2006/11/10, Joachim Kupke <[email protected]>:
>>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.)
>
>Can you elaborate on that?

The idea, essentially, is to do away with mail queues and to embrace 
email communication that involves several communication roundtrips.

>BTW the first proposal spoke about SMTP only extension :-P
>
>Now you are talking about 3 differente protocols DNS, email and HTTP.

Conceptually-speaking---who cares?  You can pretty much use any of these 
protocols to piggyback arbitrary stuff.

The difference is how these protocols are used today.  In DNS, there is 
the notion of hierarchical authority (and caching); in SMTP, there is 
support for multi-hop forwarding of what happens to be known as email 
messages.  HTTP comes with good (i.e., widely-used) support for 
proxying.

It's no wonder QMTP support is advertised using DNS.  If something good 
comes out of Rickard's proposal, use DNS to advertise your support for 
it.  (However, an A record for a somewhat arbitrarily-named subdomain is 
easier for most people to configure than another, strangely-prioritized 
MX record.)  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....").

>Connection between http and email is very difficult anyway

You may be saying that connecting the web and email is difficult, 
although I don't see what exactly you may be alluding to.  Connecting 
HTTP and email is simple; spammers do this all the time when they 
exploit publicly-accessible HTTP proxies and send out what looks like a 
legitimate HTTP proxy request but is actually (after a few 
error-triggering commands) translated to (more-or-less) valid SMTP.

>I do not see this clearly, sorry
>
>> >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. ;-)
>
>mmmh i thought was the MTA who was sending the challenge not MUA!

Yep, sorry, I was envisioning a means of configuring the MTA's 
challenging behavior, probably by using some sort of a configuration 
dialog that you would pull up in your MUA, though.

>I don't get you anyway.
>
>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.

Ah, mailing lists.  Nope, the mailing list would prompt you to solve the 
puzzle.  Or pay the money or whatever.

>> >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?
>
>Simple, web spam is a passive system, they usually offer the challenge 
>in the same transaction you use to send the web form (that mighty fuzzy 
>characters image for example:
>https://www.nic.es/esnic/esn/verValidacionWhoisAction?dominio=nic.es
>).
>
>The proposal of captcha as we are doing here involves at least 3 mails 
>per transaction (the mail itself, the challenge and the response).

No; three messages but one email.  Here's the scenario:

You compose your message, and let's assume the recipient doesn't know 
you yet.  Your MUA figures out (by querying DNS) whether the recipient 
supports the protocol.  If so, it refrains from sending your message via 
SMTP, but rather, behind the scenes, it goes to a standardized web page 
(or some equivalent of that) that has a huge textarea where it deposits 
the message, clicks the "send" button and figures out how to resolve 
what comes next.  It's unclear whether there should be a bound on the 
number of challenge/response rounds.

>>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.
>
>Think about this situation:
>
>Friday 7:00 PM:
>
>You must send an e-mail to client before monday comes and his mail 
>server provider is in maintenance or has connectivity problems.
>
>Would you stay in office with your PC and your, say, Outlook opened 
>waiting for the mail to be delivered?
>
>A plain old 26 year old SMTP protocol MTA just would accept the message 
>and keep trying sending the mail. (your MTA relay don't sleep and has 
>no social life anyway :-P )

Neither does the PC that runs the MUA.  There are really two 
sub-situations, here.  Either, that email is important enough for me to 
watch it getting sent out.  (Given what email is like today, I might 
actually log into the MX and watch qmail-remote send my message, in such 
a case.)  Or, as with this message, lives won't necessarily be lost if I 
fail to reply to qsecretary as soon as possible.

In the former case, I might as well want to have qmail-remote's 
functionality integrated in my MUA.  In the latter case, if I'm not 
willing to leave my PC turned on (or online---think a mobile device), 
there may be a need for an output queue on a different machine, yes.

If you need an output queue, go get your own.  Don't force everyone 
(like SMTP does) to think in terms of there being an output queue all 
the time.

>>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.
>
>Challenge response is not a solution anyway

A solution to the problem of spam?  Or to something less ambitious?
Just BTW, systems capable of C/R open up a host of new applications, 
too; think: interactive proof systems.

>I'm seeing too much problems to be a wide response to the problem.
>
>Just patches and patches and patches.
>
>Maybe spam will be disminished (NOT avoided anyway) and you will lost a 
>lot of functionality of plain old smtp.

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.  Now, in order for the recipient to announce the 
minimal value of such a bond (how much their attention span is worth, in 
other words) and in order for both parties to agree on what constitutes 
a(n electronic) bond---a credit card number is a bad idea---you need 
quite a lot of C/R no matter what.  An email protocol, unlike SMTP, 
should support this.

>The solution of a lot of mail problems should pass adopting the IM2000 
>proposal of being the sender who stores the mail.

I think this reasoning has already been found to be flawed.  Hell, 
greylisting would be superior to IM2000 if it weren't for the need for 
senders' busy-waiting.


--Joachim