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

On Sat, Nov 11, 2006 at 12:39:22AM +0100, David Sanchez wrote:
> The proposal of captcha as we are doing here involves at least 3 mails
> per transaction (the mail itself, the challenge and the response).

I think the proposal was to integrate captcha within the SMTP exchange
itself, so no extra mails are generated.

However, when you consider the normal E-mail arrangement:

  UA1 ----> relay1 -------------------> MX2 ----> UA2

then observe that the protocol as discussed:

(1) needs to run on a different port to SMTP (because it requires direct
    communication between UA1 and MX2, and many sites block this)
(2) involves a completely new set of SMTP primitives
(3) requires UA1 to perform its own MX lookups, direct mail delivery,
    per-message queueing and retry, none of which is currently needed
    because it offloads all that work to relay1

In other words, what you end up with is pretty much nothing like SMTP.

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

I don't think that makes much difference in this case.

The fundamental problem which arises is:

* I've got notification that someone wants to send me a message
  (whether that be an incoming SMTP connection, an IM2000 'notify',
  an inbound IM or whatever)

* How can I, or the message protocol itself, distinguish between a mail I
  want and spam?

This is an extremely hard problem, given that:

(a) not everyone agrees on what is or is not spam; and
(b) any widely-used tests for "spamminess" become known by the spammers,
    and they change their mail-sending habits to get around them

[The 'captcha' proposal tries to distinguish spam and non-spam by requiring
an intelligent response to each message, on the assumption that this doesn't
scale for spammers who want to send millions of messages. However spammers
can quite happily make captchas scale, by redirecting them to users who are
trying to get access to porn sites, for example, and they are already doing
this on a large scale]

Personally, with the vast amounts of spam I get, I'm thinking that I'd be
happy to move to a completely 'closed' E-mail system where only people I
know in advance can contact me directly. I might lose some intelligent and
interesting communication with strangers, but I wouldn't have to worry about
losing mails from friends because they are misclassified as spam. I can
still participate in public discussion via web BBSes.

So what I want is basically a combination of sender proving their identity,
plus a whitelist of senders personally known to me.

The problem is how to do identity proving. Possible solutions:

- your friends all use GPG or s/MIME signatures (unlikely to happen,
  unless all your friends are uber-nerds)

- IM2000 gives a pretty good identity assurance for free, but nobody uses it

- DomainKeys isn't much good, as any assurance it gives only works at the
  domain level, not the mailbox [unless ISPs are required to use SMTP AUTH
  for all mail submissions]

- I could set up a web-based BBS, and all my friends would have to create
  accounts on it to post private mail to me. This doesn't scale, because
  I'd need separate accounts on every BBS for every friend, and would have
  lots of BBSes to check for new mail.

- BBS postings could be validated via browser client certificates. This
  scales, but isn't very useful - e.g. if you're out in a cybercafe you
  are unlikely to have brought your client certificate with you, and even
  if you did, you wouldn't want to install it in a cybercafe PC.

- Mail (or BBS postings) could be submitted via some centralised
  identity-proving system like Passport, which in turn signs the mail.
  That, to me, sounds like a pretty good solution. You can have multiple
  identity brokers, like you have multiple CAs, and trust which ones you
  want. The difference is that your identity lives on a central server,
  and you activate it on demand (e.g. with username and password) to
  authenticate a particular session or message. Hence it can be used in
  roaming applications, and doesn't require you to get involved with key
  or certificate management at the client side.

[This approach would be very nice for public BBS participation too, as I
wouldn't have to register on each BBS individually]

Now, this last setup is in some ways quite similar to Instant Messanger
apps, except that if you want to communicate with everyone on IM then you
need your own accounts on every IM system. Also, I'd have to add friend
identities manually, to avoid the pop-up messages saying "XXX would like to
add you to their contacts, is that OK?", i.e. Spim.

Regards,

Brian.