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

> 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 was only rebating about cookies and http and the like.

IMHO that was a mess.

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

Nope, i mean sending a mail with copy to 3 or 4 people.

This is just impracticable.

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

If output queue is just an option, why don't just use a phone call or IM? :-P

For me is a must, mail without delay delivering is not mail. Is just
another thing.


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

Yeah, i'll send you a blackmail (which is spam, by definition) and
perfectly fill the Challenge offered by your MTA, and pay whatever it
costs.

That's an example of unavoidable spam.

If you want whole internet availability you must deal with spam. Simple as that.

Moreover the idea of paying for sending is against current Internet philosophy.

I will just quit using, developing or maintaining a service in that
paying is a MUST. Simple as that.

Not likely to happen, thank god.

Another example, i do have a lot of spam in my phisical mailbox, and
that traditionally had costs (stamps, the deliver guy, etc...). And
spam in your car front when parked. And all that had implied costs (a
lot more than electronic communications).

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

Maybe it's true, but spam and other mail problems will be disminished.

If you want a universal, free access internet mail, spam is unavoidable

>
> --Joachim
>