CAPTCHA over smtp (yet another spam solution to discuss)

In case anyone is still listening to this sleeping (dead?) email list, I 
submit yet another "spam solution" for comments:

CAPTCHAs [1] are today a standard way to combat web form spam, and as 
such have been both fairly successful and accepted by users.

CAPTCHA-based email solutions also exist. For example, the IM2000 email 
list, to which I am posting this, uses such a system to avoid 
unsolicited email [2]. However, users seem to show a low tolerance to 
email CAPTCHA solutions. Methods used today, e.g. "respond to this 
email" or "click this link" seems to confuse users and raise valid 
security concerns. Furthermore, since email CAPTCHAs are not a part of 
sending the outgoing email, but instead arrive with a delay and in an 
otherwise content-free email, the procedure appear much more burdensome 
for the sender than is the case for e.g. regular web form CAPTCHAs.

Based on the above discussion, a CAPTCHA method that was integrated 
better with the email system should be easier for users to accept. One 
way of doing this would be to implement the procedure as a regular 
RFC1869 SMTP extension.

Below follows an outline for how such an extension could be designed and 
gradually introduced:

When a CAPTCHA-over-SMTP aware MUA [3] sends an email, the 'local mail 
relay' setting is ignored. The MUA instead resolves the recipient's SMTP 
server, contacts that server directly, and checks if it is 
CAPTCHA-over-SMTP aware [4]. If it is, the CAPTCHA extension is invoked 
and a CAPTCHA is communicated back to the MUA. This CAPTCHA is displayed 
in a standard MUA dialog box along with an explaining text, e.g. 
"[email protected] asks you to complete the following task to confirm that 
this is not an automatized mailing." The user may be allowed to select 
between different versions of the CAPTCHA, e.g. a picture based, a sound 
based or a text-based one.

The user's answer to the CAPTCHA is communicated back to the recipient's 
server, and if correct, the email message is accepted through an 
ordinary SMTP data transfer.

If the remote SMTP server is not CAPTCHA-over-SMTP aware, the MUA sends 
the email as usual (dropping connection with the receipients email 
server and using the configured outgoing email relay instead).

The administrator of the recipient's email server may freely decide how 
to handle emails sent over regular SMTP without the CAPTCHA test. For 
example, these emails can just be filtered more thoroughly than regular 
emails. However, an effective approach would be to gradually move over 
to respond to these emails with a "legacy email CAPTCHA"; i.e. to bounce 
back the email with a "respond to this email" or "go to this web page" 
request.

A further detail: Since some Internet service providers prevent outgoing 
email from their networks by blocking the SMTP tcp port (22), this 
protocol may need to assign another port number exclusively for 
CAPTCHA-over-SMTP traffic that compliant servers should listen to in 
addition to tcp port 22.

The following issues remain to be addressed:
* The design of a protocol for CAPTCHA communication. (I'm not familiar 
with any existing such protocol.)
* The CAPTCHA protocol must include a white-list feature so that 
repeated senders do not have to perform a CAPTCHA for each email.
* It should somehow be possible for a domain to announce that all its 
outgoing email will be sent from CAPTCHA-over-SMTP aware MUAs. An email 
claiming to originate from such a domain, received by a 
CAPTCHA-over-SMTP aware server, but over traditional SMTP, could then be 
identified as a forgery.

Comments are much welcome,
Best regards,
Rickard


Footnotes:
[1] CAPTCHA = Completely Automated Public Turing test to tell Computers 
and Humans Apart, see e.g. http://en.wikipedia.org/wiki/Captcha
[2] Dan Bernstein's 'qsecretary' require you to respond to an email 
before your email is accepted for any of his email lists.
[3] MUA = Mail User Agent, the email client; e.g. Mozilla thunderbird, 
Microsoft outlook, etc.
[4] Hence, the protocol assumes that a direct connection can be made 
between the MUA and the recipients email server. This is a weak point 
compared to traditional SMTP, but most modern Internet protocols make 
this assumption.