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

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?

BTW the first proposal spoke about SMTP only extension :-P

Now you are talking about 3 differente protocols DNS, email and HTTP.

Connection between http and email is very difficult anyway

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!

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.

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


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

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 )

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

Challenge response is not a solution anyway

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.

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

There is a lot of problems though, but IMHO Challenge-Response patch
to SMTP is just too complex to be effective (think about it, SPF in
the first time is way easier than what we are talking about here, but
look about implementation in real world out there! (how many domains
has SPF records published?)).

On the other hand, I really think SMTP will never be obsoleted per-se,
but will slowly get superseded by Instant Messenging, with offline
messages web storing, and that kind of stuff.

Just my 2 cents

>
> --Joachim
>