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

Joachim wrote on  29 Nov 2006 7:28 P.M. -0600:

> Seth Goodman wrote:

> > If you don't like this, then you need a nearly-free micro-payment
> > system.  This is precisely why hash-cash and all similar schemes are
> > still-born.  There is no existing reliable way to transfer small
> > amounts of money without taking a large percentage as a transfer
> > fee.
>
> I agree:  Messages flow more easily than money.
> Which does nothing to alter the fact that PayPal may be just too
> expensive. Nor to alter the fact that hash-cash, e.g., doesn't model
> a spammer's (or legitimate email sender's) economical reality nearly
> as well as money.

PayPal and credit card processors are too expensive for the frequent
small payments that are necessary in hash-cash and similar schemes.
These processors are also unsuitable since they are often based on
credit, not cash.  They must therefore support chargebacks to the
recipient if the card number is later reported as stolen.

That being said, there _may_ be a way for a PayPal or similar payment
processors to participate in a system like this, even with their high
fees.  Legitimate senders need to post bonds, but they seldom, if ever,
have their bonds claimed.  To make an escrow scheme possible when there
are significant transfer costs, escrow accounts would need to have an
actual cash balance and recipients would need to reserve their escrow
from a sender account until they received the incoming message and
agreed it was not spam.  Money deposited must clear the payment process
before it appears as a usable escrow balance.  A recipient (or a system
operating on behalf of a recipient) must be able to verify that the
escrow balance is adequate and then reserve their required escrow
amount.  The escrow balance will then decrease until the new recipient
either releases the escrow (message is not spam), claims the escrow
(message is spam) or a specified time period elapses with no action
(recipient fails to decide).

The payment processor takes a fee only when there is a transfer.  The
depositor pays a fee when they move funds into the escrow account.  The
recipient pays a fee when they claim an escrow amount they have
reserved, so they need to set their escrow requirement accordingly.  No
fees are assessed for reservation and subsequent release of part of an
escrow balance.  The cash balance in the escrow account would generates
revenue to pay for the cost of the reservation/release system.
Alternatively, there could be a very small fee for reservation/release.

Another interesting possibility is to use sender reputation instead of
money.  That is, the recipient could see the sender's statistics for
messages they offered new recipients.  To vote on a sender, you'd have
to give the system a copy of a message they recently sent you and the
system would need the ability to verify that message.  I haven't thought
this through at all, so it may not make any sense when there is no money
involved.


> [By subverting the security of electronic payments, spammers could
> happily continue their business.]
> > > Are you suggesting spammers would adapt by going on a credit card
> > > number (or whatever) theft spree?
> >
> > That is how they generally purchase ISP accounts today.  By the time
> > the credit card number is reported stolen, the spammer has finished
> > their business and they expect the account to be closed.
>
> The difference being, the spammer's victims aren't compensated
> (today). Which has to do with the fact that credit cards are
> inherently insecure, which results in high transaction costs.

The cost of credit card fraud is born largely by the merchants who
receive chargebacks, neither by the credit card processors and nor by
the people who's cards are stolen.  Fees in the credit card business
don't have a lot to do with actual costs.


> > That is the whole point.  Until you can reliably transfer small
> > amounts of money at very low cost, this kind of scheme is only of
> > theoretical interest.
>
> Yep, it only works with negligible transaction costs.  Until everyone
> figures out what kind of transaction is the least expensive, the
> Internet's email protocol should come with a customizable C/R
> mechanism.

You can do C/R today, and I have even seen it on free email accounts.
Despite this, C/R has very little acceptance among end users.  I suggest
that it is the discouraging aspect of the challenge that bothers people.
Even greylisting, which is a minimally intrusive form of C/R, has only
gained a minor following.


> > I am arguing against captcha's in particular, and C/R for email in
> > general.  The reason that C/R is not widely adopted, despite a lot
> > of noise originally made about the idea, is that end users most
> > often choose "none" as the "kind of C/R protocol they desire be
> > used".
>
> The last time I checked SMTP didn't have any C/R "built in"; so, how
> do you know?  You seem to be referring to the procedure of spamming
> people whose address appears in some FROM: line in received messages
> with some challenge.

You can challenge From:, Sender:, Resent-From:, Resent-Sender: or the
envelope return-path, but none of them are validated so you are likely
to abuse innocent third parties.  This is the same problem as an MTA
accepting all messages and later bouncing the ones that can't be
delivered: without a validated return-path address, you generally abuse
others.

The cases that I can think of where it is either safe or somewhat safe
to send a challenge are:

1) S/MIME signed messages:  when certificate has acceptable trust path,
it is safe to challenge the signed address.

2) PGP signed messages:  when key has adequate trust level, it is safe
to challenge the signed address.

3) DKIM signed messages:  when the domain publishes a key for the
specific sender, it is safe to challenge the signed address; when the
domain publishes a single key for all users (the normal case), it is
somewhat safe to challenge the signed sender address (you know it
originated from that domain, but the user is uncertain).

4) Domains that publish an SPF record:  if the message has not been
forwarded, it is somewhat safe to challenge the envelope return-path
address (you have good reason to believe it originated from that
domain); this means that only forwarders should challenge incoming
messages and not the systems they forward to; for the same reason that
spf so far has been unable to solve this problem (solutions have been
proposed, but not widely accepted), it would be a major problem for C/R
as well; the fundamental problem is that alias forwarding breaks most
forms of authentication, yet most mail systems insist on using alias
forwarding.

5) Reverse DNS on the connecting MTA IP has a domain that matches the
domain of a sender address, or forward DNS on the domain of a sender
address shows an MX with an IP that matches the connecting MTA IP:  it
is somewhat safe to challenge that sender address (you have good reason
to believe it originated from that domain).


> > > > C/R email systems require my direct participation.
> > >
> > > Why?  Your MUA would fill in the reponse for you.  Arguably not
> > > for a captcha, though. :-)
> >
> > My MUA can't know what challenges I'd like to accept.
>
> Configure:  "Automatically agree to post bond for amounts <= $ XXX."

OK, my MUA knows that I recently sent this correspondent a message, so
it should be safe to post a bond.


>
> > If I tell it to accept all, I have just defeated the C/R system and
> > will not benefit in any way.
>
> Right.  Unless you count making the likely experience of filing for
> bankruptcy as a benefit.
>
> > If I try to create a set of rules for which challenges to accept, I
> > create a whole new spam vector.
>
> Why?  Arguably, agreeing to automatically post small-enough bonds
> would
> be sufficient for most people.  But even if you create a "set of
> rules," how does that create a "spam vector"?  You would only be
> "spammed" with challenges from people you are trying to send messages
> to in the first place, and only at the very time you do.
>

> > If I try to create a set of rules for which challenges to accept, I
> > create a whole new spam vector.
>
> Why?  Arguably, agreeing to automatically post small-enough bonds
> would be sufficient for most people.  But even if you create a "set of
> rules," how does that create a "spam vector"?  You would only be
> "spammed" with challenges from people you are trying to send messages
> to in the first place, and only at the very time you do.

Except for joe-jobs, which happens to a lot of people and a lot of role
accounts.

The spam vector I had in mind, though, was the messages

>
> > > > > [Repudiability of authorship is a good thing.]
> > > > For most everything else besides an argument in front of a
> > > > Court, people's perceptions are more important than proofs.
> > >
> > > Precisely.  Imagine your casual email making headline news.  If I
> > > forward a non-signed email to a newspaper, they will yawn.
> >
> > Newspaper reporters are neither technologists, lawyers nor
> > mathematicians.  What you can say is that _should_ yawn, or that you
> > wish they _would_ yawn.  Regardless, they look at content first.  A
> > leaked memo is nothing but a printed document with no signature and
> > is easily forged, but likely to be believed despite that.
>
> We'll have to agree that we disagree.  You are basically saying that
> there is no use in electronic signatures as the number of people
> competent enough to verify them is negligibly small.  I take
> exception, but do go ahead and prove me wrong.  Forward a forged
> email to your
> local newspaper, with, say, $CELEBRITY confessing to $FELONY.
>
> [If a mailing list maintainer asserts Seth Goodman sent a message,
> that's at least as good as an electronic signature.  If not better.]
> > > Those headers and everything can be spoofed.
> >
> > Who cares?  Most email and memos that are leaked and become problems
> > for the original authors are secured neither with cryptography nor
> > written signatures.  In many cases, the only _proof_ of authorship
> > is someone else's assertion that they saw the memo and they
> > believed it came from the apparent author.  You are confusing
> > provability and theory in a perfect world with what people actually
> > believe and the very limited information on which they must base
> > decisions every day.
>
> I do agree that markets, e.g., react to rumors.  But rumors != facts.
>
> At any rate, if you don't see an advantage in electronic signatures,
> so
> be it.  How about something more elaborate, like an encrypted ballot
> (the validity of which the sender/voter would assert using a
> zero-knowledge proof)?
>
>
> --Joachim