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

Joachim Kupke <[email protected]> Mon, 4 Dec 2006 14:02:58 -0800
Newsgroups gmane.mail.im2000
Message-ID <[email protected]>
Seth Goodman wrote:

[Using reputation schemes to fight spam will result in feedback spam.]
>If you must present the digest of an actual message you received and 
>the address it was sent to, as well as prove you are the recipient, 
>it's unlikely for you to get inappropriate ratings.  I'm not advocating 
>this particular scheme, just saying that reputation can be very useful.  
>It is likely a requirement to facilitate communication among people who 
>do not yet know each other.

Spammers would set up multiple accounts and simulate a history of hammy 
email communication among these.  Leading, inevitably, to bogus 
reputation scores.

Robust reputation schemes is a hot research topic.  See, e.g., 
http://www.stanford.edu/~ashishg/research.html

>I think it would be completely self-defeating if spammers could push 
>off the cost of their fraudulent escrow deposits onto legitimate 
>participants.  If most spammers did that, we'd be back to exactly the 
>situation we have now.

Let's assume everybody turns their filters off.
Let's assume everybody receives 1ยข per spam message (if claimed).
Somebody will have to pay for it.

You are saying:  Spammers could abuse credit cards to an extent 
necessary to spend this kind of money.

No numbers, but if you can squeeze that much money out of stolen credit 
cards, you probably won't have to "work" (be it as a spammer) anymore.

>I'm only arguing that for a payment system to work in this context, it 
>needs the attributes of cash.  A bond must be worth something.

Then give it the attributes of cash.  That has the upshot of decreasing 
transaction costs, probably to zero:  Whoever provides electronic cash 
will need to be paid up front, and they can (probably) live on the 
interest of what people deposit with them.

>Your points are valid, and qsecretary is indeed a PITA.  Using ordinary 
>email for C/R is a poor solution, and it is what most people think of 
>when you say C/R.

Care to suggest a better name?

>> This all tries to answer the question, how can we be sure to not spam 
>> an innocent victim by sending a challenge as a fresh email?
>
>If a system meant to curtail network abuse necessarily perpetrates 
>abuse on others, it has already failed.

ACK

[C/R-over-email relies on a verifiable sender address.]
>Depends on how you look at it.  I think it's unclear whether anonymous 
>email is necessary.  While desirable in a few cases, it could be 
>provided in those limited contexts.

You are already compromising.  But let's assume we don't want anonymous 
email.  People have often suggested OpenPGP signatures to authenticate 
email senders.  That clearly goes too far since the signature could be 
verified by anyone, not just the recipient.  Hence a zero-knowledge 
proof for authentication purposes.  Hence the need for C/R.  Id est, C/R 
must be implemented one level lower.

[Examples for where anonymity has been given up already]
>I am not saying full anonymity is bad, only that I'm not sure.

Regardless of the merits of your examples, an email system without 
anonymity (in the sense of today's email) would be less attractive, and 
at least some people would continue to use the potentially-anonymous 
email system.  Without gateways between the two (and there cannot be 
any:  how would you gateway an anonymous email to the non-anonymous 
world?), users of the new system would want to receive email from the 
old one, which, of course, will be spam 99% of the time.

["Real" C/R as opposed to C/R-over-SMTP]
>If you take SMTP off the table, you can certainly imagine more 
>functional systems.

That's the whole point, right?  To reinvent an email protocol that 
essentially differs from SMTP.  That does not have a chain of 
responsibility for mail delivery (aka "remote queue"), but that has a 
general-purpose mechanism for a sender to converse with an automated 
agent on the recipient's side.  The original proposal was to have a 
"captcha mechanism," where I propose a "general-purpose mechanism."

Out-of-office replies are a good example of a fairly simple instance of 
this generality, captchas are another instance, which is not quite as 
simple.  Personally, I think that sender-at-risk (through financial 
bonds) is the most promising thing you would want to do with such a 
general-purpose feedback system, but the important thing is:  There is 
no such thing as a "real" C/R email protocol today.

>Whether you require anonymity is very fundamental, as that changes the 
>problem significantly.

Can you elaborate?  (I'd mostly be worried about having to register 
things like role accounts with a central registrar or something.  But 
promoting free speech by having an anonymous email system is also fine 
with me. ;-)

[Repudiable signatures]
>As with all hearsay, two or three others present who report the same 
>version of the conversation as you do would make it hard for me to deny 
>it.  Depending on what it involves, the burden of proof can be fairly 
>low.

And that's precisely what I had in mind when I alluded to the naturality 
of speech/conversations.  Not being careful about who you share your 
thoughts with is one thing.  Not being able to express yourself without 
allowing your thoughts to come back and haunt you in the future is a 
completely different thing.

I do sign most, if not all, of my paper correspondence.  But imposing 
non-repudiable signatures for email authetication purposes is the 
equivalent of equipping bartenders with "always-on" dictaphones.

>> Repudiably signing statements in a chat room is to offline signatures 
>> what a personal meeting is to handwritten signatures.
>
>This could also be an ephemeral signature, where there is strong 
>validation by all parties at the session time, but not later.

Please clarify.  An "ephemeral signature" is one created using an 
ephemeral key, I suppose.  Which is a temporary key, meaning that there 
is a mutual agreement to destroy the key after its use.

>The SSL session is not a bad C/R model.

Presumably, you are talking about certificates.  Which are used to prove 
identity, but verifiers cannot use the collected information to 
impersonate provers.  Zero-knowledge proofs at work.

>If preventing others from verifying the sender identity is not a 
>requirement, then ephemeral keys (session keys) would also work.

Translation:  Rather than GPG-signing my email, I create a fresh GPG key 
pair (actually, a symmetric key would have been sufficient, but let's 
keep things simple) for every message I send out, sign an additional 
message M that contains this temporary (public) key, and the recipient 
assures that they will delete M.

Pretty underwhelming, isn't it?

>> If I need to sign messages to you (either in OpenPGP or in S/MIME 
>> format) just so you can deem yourself allowed to send a challenge 
>> over email to me, anyone can verify my signature.
>
>Is anonymity a general requirement?

This is not anonymity as far as the recipient is concerned.

[Forwarding signed/non-signed messages to a newspaper]
>The newspaper should treat it like all circumstantial evidence and 
>attempt to corroborate it.  If they fail to use a reasonable degree of 
>care and print something that does harm, they may be liable for the 
>damages.

Liability for damages notwithstanding, a journalist who sees a signed 
message (and verifies the signature successfully) and an unsigned one, 
both of similarly explosive nature, will prioritize these pieces of 
circumstantial evidence such that the former message receives 
significantly more attention.

[The authenticity of mailing list messages is rarely disputed.]
>> Should we all use postcards, hence?
>
>That depends on the content and your personal desire for privacy.  For 
>parking tickets you'd find one set of preferences, for eviction notices 
>you'd find another while some things are unsuitable for mail at all.

Consequence I:  A postcards-only world is bad.
Consequence II:  If, say, you were to insult someone on this ML, they 
will have a hard time proving, from the raw message from the ML only, 
that it's been authored by you.


--Joachim