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

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

Ok, let's figure out this captcha is inline between MUA and MTA aware
of this new procedure.

What happens with non compliant MUA and MTA?

Dealing with old MUA is not a trivial matter. What a MTA aware of this
new procedure will do whith old MUA-MTA messages ? accept e-mails?
send an english challenge? (which this kind of user will likely ignore
or simply destroy)

If you think this is a trivial matter, you must look at ipv6 mess.

Sorry, I don't get it. :-(

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

Ok, let's say any user out there has access to extern SMTPs (which is
in fact a BIG assumption, given that in a medium security aware
enterprise this will not be the case )

There's a lot of companies that make control of the messages sended
and received.

Moreover is a LEGAL OBLIGATION to store mail transaction between ISPs
in some countries, and with this you are re-routing message.

Moreover, if a user need an inmediate response, he will simply call or
send him a IM, not an e-mail that is a message to be read
asynchronously.

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

Ok, so then they will use IM, not an e-mail.

Think again of what i told you about Friday19PM problem :-P

> Best regards,
> Rickard
>
>